In my previous article I wrote about extending the Visual Studio SharePoint development tools. Now it’s time for the first extension: Imtech Run PowerShell Script Deployment Step.
Deploying solutions using the Visual Studio SharePoint development tools
The new Visual Studio SharePoint development tools help you not only with creating solutions but also with deploying them to your SharePoint server. If you are new to the tools there is a whole section on MSDN dedicated to Packaging and Deploying SharePoint Solutions using the new tools.
The coolest thing about the Deployment Configurations is that they are fully customizable: not only you can define your own configurations, but you can also create custom Deployment Steps.
Executing PowerShell scripts in the Deployment process
Out of the box the Visual Studio SharePoint development tools ship with a number of Deployment Steps. These steps cover the most common tasks like recycling Application Pool, deploying Solutions and activating Features.
One of the new things in SharePoint 2010 is support for Windows PowerShell. You can use PowerShell to manage your SharePoint Farm but it can be also extremely useful also during the development process. Unfortunately, in the current release of the development tools, there is no support for executing PowerShell scripts as a part of the Deployment process.
Introducing: Imtech Run PowerShell Script Deployment Step
Imtech Run PowerShell Script Deployment Step is a custom extension for the Visual Studio SharePoint development tools. After installation it adds a new Deployment Step called Run PowerShell Script:
In your Deployment Configuration you can select either one or multiple PowerShell Scripts to be executed during the deployment. Just pick a Run PowerShell Script task for every script that you want to execute.
After you confirmed the Deployment Configuration, when you select the project in the Solution Explorer, you will see two new properties in the Properties Window: one for every PowerShell script you selected in the Deployment Configuration:
Using these properties you can define which PowerShell scripts should be run for every task.
Important
The PowerShell script path that you enter in the Properties Window is not bound to a specific PowerShell Deployment Task. The number of the task that you see in the Properties Window simply says: “The first/second/third PowerShell script is…”. In order to change the order of the PowerShell scripts you have to change the value of the specific properties.
Finally when you choose Deploy from the Project menu, the Deployment Configuration will be executed and the PowerShell scripts, that you specified in the Properties Window will be run:
Installing the Imtech Run PowerShell Script Deployment Step
Imtech Run PowerShell Script Deployment Step is available as a Visual Studio Extension. You can either download it from the Visual Studio Gallery or from your Visual Studio choose Tools > Extension Manager, and search for Imtech Run PowerShell Script Deployment Step:
November 21st, 2009 at 2:03 am
That's awesome use of extending Visual Studio mate!
November 21st, 2009 at 10:08 am
@Jeremy: Thanks! More about to come
March 25th, 2010 at 4:11 pm
[...] 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 [...]
July 13th, 2010 at 4:05 pm
Hi Waldek, did you try to call a PS1 script file containing SharePoint cmdlets? When I use your extension with a PS1 that includes:
Add-PSSnapin "Microsoft.SharePoint.PowerShell"
I get the error:
Add-PSSnapin : No snap-ins have been registered for Windows PowerShell version
2.
Should I load SharePoint cmdlets some other way?
July 13th, 2010 at 5:57 pm
@Enric: Are you running Visual Studio as administrator?
July 14th, 2010 at 8:48 am
Yes, I am running VS with "Run as administrator". And the same script works fine being executed from CMD (powershell .\xxxx.ps1).
July 16th, 2010 at 2:26 pm
@Enric: I've checked it for you and it turns out that this has to do with the fact, that Visual Studio is a 32-bit process, which cannot load the SharePoint PowerShell SnapIn which is 64-bit. As this Deployment Step is now a part of the CKS:DEV toolkit, I would like to ask you to file it as a bug in the Issue Tracker (http://cksdev.codeplex.com/workitem/list/basic) and we will try to get a solution for it as soon as possible.
July 16th, 2010 at 3:08 pm
@Enric: Just wanted to let you know that the issue has been fixed in CKS:DEV (http://cksdev.codeplex.com/SourceControl/changeset/changes/49691).
July 19th, 2010 at 7:27 am
Perfect! I'm downloading it right now.
Thank you Waldek, great job!
July 19th, 2010 at 8:35 am
@Enric: you're welcome
July 19th, 2010 at 12:49 pm
Just one thing, Waldek: after executing the PS1 script, the Process object returns ExitCode = 0 even if a command has failed, so the generated StandardError text is lost (in fact, I could only see it debugging the code).
if (cmd.ExitCode != 0)
{
logger.WriteLine(cmd.StandardError.ReadToEnd(), LogCategory.Error);
}
Do you think that the Standard Error could be always logged, regardless of the ExitCode?
July 19th, 2010 at 6:12 pm
@Enric: sure. I would appreciate it if you could add it to the Issue Tracker @ http://cksdev.codeplex.com so that we can note that, discuss with the team and if there is no blocks for it, include it in the next release.
Thanks again for your feedback,
Waldek
July 20th, 2010 at 8:01 am
You've got it!
http://cksdev.codeplex.com/workitem/5214