Anyone that has talked to me recently about how I write PowerShell scripts will know that Visual Studio Code is my new one and only! You can write PowerShell scripts in there and hit F5 to have a similar debugging experience to what you would get in PowerShell ISE – but did you know that you can extend that to make it easier to debug and test different scenarios from within VS Code? If the answer to that is no, then read on! Continue reading “Using the launch.json file in VS code for improved PowerShell debugging”
Most people that I talk to about my experiences writing PowerShell scripts these days will know that Visual Studio Code is my absolute preference for editor these days. It’s a great tool with lots of little tricks to help you improve your productivity – and recently I came across another one to help when I work on SharePoint related scripts for SharePointDsc, and this is how I add intellisense for SharePoint PowerShell cmdlets when I’m authoring scripts on my laptop (which doesn’t have SharePoint installed on it). Continue reading “Adding additional intellisense to VS Code when editing PowerShell scripts”
PowerShellGet is a new module that is installed as part of PowerShell 5 (in Windows Management Framework 5.0) which allows you to easily connect to remote repositories to install PowerShell modules from. When you install WMF5 you’ll get a repository configured to point to the PowerShell Gallery, where you can download the release versions of all of the PowerShell teams DSC resources. However if you want to use the preview (in development but not yet released) builds, you have the option to connect to a secondary repository where the dev builds are created and install those directly to your machine. Continue reading “Consuming preview builds of xSharePoint through PowerShellGet”
Update: If you’re reading this then be sure to have a read of the comments too – some good insight and points from nohwnd on the Pester team that are also worth considering if you are interested in this stuff.
Update 2: I’ve posted a new post related to this which shows an improved way to test SP cmdlets
As we see PowerShell scripts get more and more complex (lets face it scripting guys, you’re basically writing code – we’ve turned you in to developers without you realising it! :P) people are discovering the need for things that help us maintain complex code bases, such as unit testing. Pester is a great tool for being able to write unit tests for PowerShell scripts, and will even integrate in to Visual Studio so you can run tests as you are writing your scripts. The way Pester lets us perform some pretty complex scenarios is through the ability to mock specific functions in a script, specifying what parameters to watch for in the input and what we will return from our mock – but for these mocks to work Pester needs to be able to see the original cmdlet or function you are mocking, which gets more complex in a SharePoint environment. Continue reading “How to unit test PowerShell scripts that call cmdlets from the SharePoint snap-in”
The new SharePoint app model provides a great framework for creating rich SharePoint solutions that run remote to the SharePoint server itself, but this move has brought in to play a new element of performance concerns that the traditional SharePoint developer has not really needed to give a great deal of thought to. In the world of server side code we could just run next to the database server along with SharePoint and the only real consideration was around querying only what we needed so we didn’t have a big impact on the SQL server – but now when we are running in a remote model, we need to give consideration to the potential impacts on performance of our applications. Continue reading “Approaches to optimising SharePoint client side communication”