The SI SharePoint Blog

The SharePoint developer tools in Visual Studio 2010 allow you to deploy the solution you’re working on directly to a SharePoint site.  The deployment steps are both configurable and extensible: You can choose which deployment steps you want to perform (add solution, activate features, etc.), and it is also possible to define your own custom deployment steps in a Visual Studio extension.

The configuration options are fairly limited.  For instance, you can choose to “activate features” as part of the deployment.  But what if you have multiple features in your solution, and you normally only want to activate some of them?  You could move the rest into their own solution, but that’s an ugly way to solve this.  What then?

There are some guides on the web about how to make your own custom deployment steps, which can then do things like only activate some features instead of all of them.  Here’s a series of posts by Eric Shupps – part one, two, three.  This is interesting, but it’s a lot of components to make for what could really be just a simple deployment script.  And then if you want to change the deployment step later, you’ll have to update the extension you’ve made on all the Visual Studio installations in your team.

What I prefer instead is to extend the deployment steps with PowerShell scripts.  You can of course run PowerShell scripts whenever you like outside of Visual Studio, but running them as part of the Visual Studio deployment steps is much more convenient.  You build, the scripts run, and there you are.  Here’s how to do it.

Launching a PowerShell script during deployment

The first thing you’ll want to do is create a new deployment configuration in the SharePoint tab in the project properties, and configure it to do nothing except run the post-deployment command line.

Next, create a PowerShell script file and put it in your project.  You could also put it somewhere else, since it isn’t strictly a part of the solution, but it’s more convenient that way.

Finally, add something like this to your Post-deployment Command Line:

%windir%\sysnative\windowspowershell\v1.0\powershell -file “$(ProjectDir)\Scripts\Deploy-Solution.ps1″ -configuration “$(ConfigurationName)” -url “$(SharePointSiteUrl)” -package “$(TargetDir)$(TargetName).wsp”

The sysnative part at the beginning is necessary in order to launch PowerShell as a 64-bit process.  Visual Studio 2010 is 32-bit, and when you start PowerShell (or any other system command) from a 32-bit process, it automatically launches the 32-bit version of that tool.  This will fail, because SharePoint 2010 is 64-bit only.

On a 64-bit Windows machine, the 32-bit versions of system tools are located in c:\windows\SysWOW64, and the 64-bit versions in c:\windows\system32, (which is confusing enough in itself), but even if you explicitly refer to an application in system32, you’ll get the 32-bit version from SysWOW64 instead, because of magic.  %windir%\sysnative overrides that magic.  The sysnative folder only exists when you’re running in a 32-bit process, so don’t go looking for it on the disk, but it will be there when Visual Studio runs the post-deployment command line.

Btw: There is also a Visual Studio extension from Imtech that allows you to run a PowerShell script as a deployment step.  This is a good idea, and would accomplish the same thing, but I couldn’t get it to work on Visual Studio 2010 RC, so it probably needs some more work.

Supporting multiple configurations

What’s all those input parameters?  You don’t need to have them there, but they illustrate how you can integrate your script with the build variables from Visual Studio, which opens up some really exciting possibilities.

$(ConfigurationName) is the name of the active configuration, such as Debug or Release.  $(SharePointSiteUrl) is the URL you’ve selected in the properties of the SharePoint project.  And $(TargetDir)$(TargetName).wsp is the name of the solution package file.

Some of these variables are the same as those you see in the pre- and post-build event editor.  SharePointSiteUrl is an extra variable that is available for SharePoint projects.  There are more, and they’re listed here.

In order to read these parameters in your script, add this line at the top:

Param($configuration, $url, $package)

Here’s the fun part: Your script can now test on the active configuration, and change the deployment accordingly.  For instance, you could have one configuration that retracts and installs the solution, another that upgrades an existing solution, and one that just adds your assemblies directly to the GAC, (in order to save time when all you’ve done is change code).

You’ll also want to add the SharePoint snapin:

$snapin = get-pssnapin | where { $_.Name -eq “Microsoft.SharePoint.PowerShell” }

if($snapin -eq $null)  {

Add-PsSnapin Microsoft.SharePoint.PowerShell

}

By testing on whether the snapin is already loaded, you can also run this script from the SharePoint management shell.

This is a good starting point for taking full control of your Visual Studio deployment.  No need to create Visual Studio extensions, just do everything in PowerShell.

(Update: Also read this entry about avoiding assembly cache problems during deployment.)