Generate WSP and coy to another location on post build event in Visual Studio 2010

April 19, 2012

When working on all SharePoint 2010 projects deployments are generally done via PowerShell scripts. I usually have a set PowerShell script which I copy and alter updating items such as the site URL, solution name and feature ID and I save this in a deployment folder under where the solution file is located. I then create a solution folder in Visual Studio called ‘Deployment files’ and add my PowerShell scripts to this. This way the deployment files are part of the solution and should be added into our code repository as well.

In my PowerShell scripts I don’t hard coded the WSP location I find the current directory from which the script is getting executed and then append the WSP name, see below. This means the WSP has to be in the same folder as the scripts which isn’t generally an issue but it means I have to package the project in Visual Studio and then copy the WSP from the build folder to my scripts folder. While this only takes a few minutes you need to do it each time which can get a bit repetitive.

Find Solution Location
  1. $scriptpath = $MyInvocation.MyCommand.Path
  2. $dir = Split-Path $scriptpath
  3. $solutionName=”WSPNAME.wsp”
  4. $solutionPath = $dir + “\” + $solutionName


I decided to look into using post build commands to see if I could generate the WSP then copy it to the folder where my scripts are located. Since I have done it several times I first looked at copying the WSP file to another location. This can be done by

  1. Right click on the project and select properties


  1. Next select the Build Events option on the RHS
  2. In the post-build event command line window enter the script below

copy $(TargetDir)$(TargetName).wsp $(SolutionDir)DeploymentFiles

    1. The TargetDir should be the full path to the build folder where the WSP will be created
    2. The TargetName should be the same name as the project so in my case if the project name was TestProject I would be looking for a file called TestProject.wsp
    3. The SolutionDir should be the full path to the folder where the solution file is located.
    4. \DeploymentFiles is simply the name of the folder located under the main solution folder where I keep my PowerShell scripts

3. Save the file and build the project

If it has worked you should get a message in the Output screen indicating the file has been copied.

This was fine except this simply copies the WSP from the bin folder to my deployment scripts folder but what I need is to ensure I am getting the latest version of the WSP so I need to generate the WSP before copying the file. As this was not something I had done before I done some research and it seems the only way to do this is to edit the project file.

I opened my project file in Notepad++, might be worth taking a backup of this first, and found the section at the end, see below, and added the suggested XML, see below.

Section After which I need to add my addition XML
<Import Project=”$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\SharePointTools\Microsoft.VisualStudio.SharePoint.targets” />

Required XML

What I found was as I had already added my post build event to copy the WSP there was already a section in the project file called “PropertyGroup”, see below.


At this point I wasn’t sure if I was supposed to add a new PropertyGroup element or add my BuildDependsOn section to the existing property group. I looked around on Google but there wasn’t much details on this so added the section to generate the WSP as another PropertyGroup element but I added this before my copy build event in case the order was important. When I opened Visual Studio, or if you already had it opened you will need to reload the project, and build it I found it did copy the file and it did build the WSP it did them in the wrong order. It first copied the WSP then it built a new version of the WSP.

Obviously this isn’t much use as I would always end up with an old version of the WSP. I tried adding the post build code which moves the file into the same property group, see below, but I still ended up with the same outcome where the file was moved first then a new version created.

XML with generate new WSP and move file in one property group in project file

I spent some time researching this issue on Google and found an article on how to generate a WSP in post build command and noticed that I had “<BuildDependsOn>” in my version but in the article above it was “<PostBuildEventDependsOn>”. As soon as I changed this, see new project XML below, things executed in the correct order and it first built my WSP then copied it.

Final version of project file XML

<PropertyGroup>  <PostBuildEventDependsOn>$(PostBuildEventDependsOn);CreatePackage</PostBuildEventDependsOn>
<PostBuildEvent>copy “$(TargetDir)$(TargetName).wsp” “$(SolutionDir)DeploymentFiles”</PostBuildEvent>

I hope this will help others as it took me a while to get this right. As always please be careful with making changes to the project file as this can cause issues.

PowerShell script for updating workflows

December 22, 2011

The other day when working on a project I needed to update some existing Visual Studio workflows. I had a Visual Studio project which contained a variety of workflows which were used across several SharePoint sites. While keeping all the workflows in one solution works it is not ideal for deployment as you can’t auto associate the workflows as part of the deployment.

I decided to try and automate the deployment so started thinking what my options were. Being a developer my first thought was code in a feature receiver on activated and deactivated, however I decided that this would be another opportunity to practice some PowerShell. This gave me the flexibility of changing the script if need be without having to alter code.

Before starting to write the script I went through in my head what it need to do and came up with the following:

  1. Get the list to which the workflow should be deployed
  2. Check to see if the workflow was already deployed
    1. If it was already deployed check to see if there were any running instances
      1. If there were running instances set the workflow to not allow any new instances but allow existing ones to finish.
      2. If not remove the workflow and go to step 3
    2. If not move on to step 3
  3. Associate the new version of the workflow to the list


With these steps in mind I started to create my script. I will cover each of the above and go through the script required to achieve the goal.

Point 1

First I wanted to get the list the workflow was associated with. This is very easy and can be accomplished by getting the web object then using that to get the list object much the same way you would if you were writing C#

Get Workflow List
  1. Write-Host 'Get web'
  2. $hrWeb = Get-SPWeb $siteURL
  4. Write-Host 'Get Lists'
  5. $list = $hrWeb.Lists[$listName]
  6. $taskList = $hrWeb.Lists[$taskListName]
  7. $workflowHistoryList = $hrWeb.Lists[$historyListName]


Point 2

With the list the next task was to see if the workflow is currently deployed to the list. This presented a problem as my plan was to automatically deploy the workflow with a name and the date of the deployment i.e. “Workflow 22/12/2011’. This caused problems as I wouldn’t know the last deployment date so I had to use a like comparison on the name. I wasn’t comfortable just using a like comparison as I felt this wasn’t always going to get me what I wanted so I added an additional check to validate the name of the workflow but also if it was of the correct base workflow type.

Try and find workflow
  1. Write-Host 'Get base template'
  2. $basetemplate = $hrWeb.WorkflowTemplates.GetTemplateByName($workflowTemplateName,$culture);
  3. Write-Host $basetemplate.Id
  5. #set up variable to hold workflow instance if we find it
  6. $existingWorkflow = $null
  8. Write-Host 'Get workflow association'
  9. #loop through all associations on list
  10. foreach($tempWorkflowAssociation in $list.WorkflowAssociations)
  11. {
  12. #check if the base template id matches the base template of the current WF associaton
  13. #in additon check the name of the current WF association against the one we are interested in
  14. if($tempWorkflowAssociation.BaseTemplate.Id -eq $basetemplate.Id -and $tempWorkflowAssociation.Name -like $workflowName +"*" )
  15. {
  16. $existingWorkflow = $tempWorkflowAssociation
  17. break
  18. }
  19. }
  20. #check we have a workflow
  21. if($existingWorkflow -ne $null)
  22. {


Point 2.1

As you can see the last line in the previous snippet makes sure we have a workflow returned so at this point we know there is a version of the workflow we are interested in currently deployed to the list. Now I need to know if there are any running instances for this.

Check running instances
  1. Write-Host 'Got workflow associated with list'
  2. if($existingWorkflow.RunningInstances -ge 0)
  3. {


Point 2.1.1

If there are running instances these must continue working until they are complete but not allow any new instances of this workflow to be initiated. This can be done by setting the ‘No new instances’ option through the workflow settings in the UI or by the following command.

No new instances
  1. Write-Host 'There are running instances so set to allow no new running instances'
  2. $existingWorkflow.set_Enabled($false)
  3. $list.UpdateWorkflowAssociation($existingWorkflow)


Point 2.1.2

If there are no running instances then we want to remove the current version. This can be done by the command below

Remove workflow
  1. Write-Host 'No running instances so remove'
  2. $list.RemoveWorkflowAssociation($existingWorkflow)


Point 3

We are now in a position where we can try and associate the new version of the workflow to the list. As I mentioned above when attaching the new workflow I am adding it with the name and the date so I first build up the name then create an new workflow association object the add it to the list.

Associate new workflow
  1. Write-Host 'Create workflow association details'
  2. $date = Get-Date
  3. $workflowName = $workflowName + " " + $date.ToShortDateString()
  4. $newWorkflow=[Microsoft.SharePoint.Workflow.SPWorkflowAssociation]::CreateListAssociation($basetemplate, $workflowName,$taskList,$workflowHistoryList)  
  6. $newWorkflow.AllowManual = $allowManualStart
  7. $newWorkflow.AutoStartChange = $autoStartChange
  8. $newWorkflow.AutoStartCreate = $autoStartCreate
  10. Write-Host 'Add workflow to list'
  11. $list.AddWorkflowAssociation($newWorkflow)

At this point the new version of the workflow should be attached to the list. I started creating this with some hardcoded values but then extracted it out into a reusable function. The full function is below.

Fully assocaition function
  1. function AssocaiteWorkflow([string]$siteURL, [string]$listName, [string]$taskListName, [string]$historyListName,
  2.     [string]$workflowTemplateName, [string]$workflowName, [bool]$allowManualStart, [bool]$autoStartChange, [bool]$autoStartCreate)
  3. {
  5. Write-Host 'Start WF assocaition for ' $workflowName ' on list ' $listName ' and site ' $siteURL
  7. #get culture
  8. $culture= Get-Culture
  10. Write-Host 'Get web'
  11. $hrWeb = Get-SPWeb $siteURL
  13. Write-Host 'Get Lists'
  14. $list = $hrWeb.Lists[$listName]
  15. $taskList = $hrWeb.Lists[$taskListName]
  16. $workflowHistoryList = $hrWeb.Lists[$historyListName]
  18. Write-Host 'Get base template'
  19. $basetemplate = $hrWeb.WorkflowTemplates.GetTemplateByName($workflowTemplateName,$culture);
  20. Write-Host $basetemplate.Id
  22. #set up variable to hold workflow instance if we find it
  23. $existingWorkflow = $null
  25. Write-Host 'Get workflow association'
  26. #loop through all associations on list
  27. foreach($tempWorkflowAssociation in $list.WorkflowAssociations)
  28. {
  29. #check if the base template id matches the base template of the current WF associaton
  30. #in additon check the name of the current WF association against the one we are interested in
  31. if($tempWorkflowAssociation.BaseTemplate.Id -eq $basetemplate.Id -and $tempWorkflowAssociation.Name -like $workflowName +"*" )
  32. {
  33. $existingWorkflow = $tempWorkflowAssociation
  34. break
  35. }
  36. }
  37. #check we have a workflow
  38. if($existingWorkflow -ne $null)
  39. {
  40. Write-Host 'Got workflow associated with list'
  41. if($existingWorkflow.RunningInstances -ge 0)
  42. {
  43. Write-Host 'There are running instances so set to allow no new running instances'
  44. $existingWorkflow.set_Enabled($false)
  45. $list.UpdateWorkflowAssociation($existingWorkflow)
  46. }
  47. else
  48. {
  49. Write-Host 'No running instances so remove'
  50. $list.RemoveWorkflowAssociation($existingWorkflow)
  51. }
  52. }
  53. else
  54. {
  55. Write-Host 'No workflow associated with list'
  56. }
  58. Write-Host 'Create workflow association details'
  59. $date = Get-Date
  60. $workflowName = $workflowName + " " + $date.ToShortDateString()
  61. $newWorkflow=[Microsoft.SharePoint.Workflow.SPWorkflowAssociation]::CreateListAssociation($basetemplate, $workflowName,$taskList,$workflowHistoryList)  
  63. $newWorkflow.AllowManual = $allowManualStart
  64. $newWorkflow.AutoStartChange = $autoStartChange
  65. $newWorkflow.AutoStartCreate = $autoStartCreate
  67. Write-Host 'Add workflow to list'
  68. $list.AddWorkflowAssociation($newWorkflow)
  69. }


You can then call this in the standard way i.e.

Call function
  1. AssocaiteWorkflow "http://sharepoint&quot; "Test List Name" "Tasks List Name" "Workflow History List Name" "Visual Studio Workflow Name" "Workflow Instance Name" $true $true $true


As with all PowerShell scripts while they are very useful please always test them on a development environment before running them on live. As always I can’t be responsible for any issues that arise so if you use this you do so at your own risk.

%d bloggers like this: