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”
For just over 12 months now we have been working hard to grow the xSharePoint DSC module to let SharePoint 2013 and 2016 administrators use PowerShell Desired State Configuration to manage their SharePoint deployments. We’ve come a long way in the last year, and now with the help of my core team we are making an important transition – we are renaming from “xSharePoint” to “SharePointDsc”. Continue reading “xSharePoint is now SharePointDsc – what you need to know!”
In some of my recent work with the xSharePoint resources we came up with a need to retrieve the current URL of an app catalog so that we could determine if the current settings were correct or not. The issue with this is that we found there is no out of the box cmdlet to retrieve the current app catalog URL for a specific web application, only to update the settings with Update-SPAppCatalogConfiguration. To facilitate getting the current URL we had to do a bit of digging to find where it was stored after this point, and as it turned out this was found in the properties of the app feature which is turned on within the web application object. Continue reading “Retrieving the URL of an app catalog site in SharePoint 2013”
For those who have come across my blog before you would have seen my recent post on how to unit test PowerShell scripts that call SharePoint cmdlets, which after I posted started a conversation between myself and Jakub Jareš (PowerShell MVP and Pester Owner) around the approach I had taken and some of the flaws in it. What ended up coming out of that was a much better approach to what I was doing, as well as a massive refactor of my entire test suite for the xSharePoint DSC resources – so I wanted to capture the approach here for anyone else who is interested. Continue reading “Better approaches to unit testing PowerShell scripts that call SharePoint cmdlets”
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”