Streamlining build and deploy for sharepoint workflows

It may come as a surprise to regular readers (or people that know me) that I'm posting about SharePoint. It came as a surprise to me too.

SharePoint was definitely a technology that was on my list of things I'm not doing at the moment.

However, SharePoint is something of a juggernaut in the Enterprise IT space right now and I couldn't help but get sucked in by the slipstream. And so, I found myself helping out on a proof of concept using the Workflow integration features of SharePoint.

Anybody trying to create a custom workflow in sharepoint using Visual Studio 2005 will inevitably start with the SharePoint Sequential Workflow Template provided with the SDK. It comes with a very handy (nay, life-saving) batch file that helps you deploy your new feature to a SharePoint instance as part of the post-build event.

By default, the deployment feature of the file is disabled because the postbuild event ends with the keyword NODEPLOY:

If you want the project to deploy (and you almost certainly do) you need to change this to end with the DEPLOY keyword, as follows:

call "$(ProjectDir)\DeploymentFiles\PostBuildActions.bat" "$(ConfigurationName)" "$(ProjectDir)" "$(ProjectName)" "$(TargetDir)" "$(TargetName)" DEPLOY

The script will now, very kindly, do the following after every build:

1. un-GAC and re-GAC the dll
2. copy the appropriate files into a sharepoint directory ready to be 'featurised'
3. optionally verify your infopath forms (you have to manually add an entry for each form)
4. de-activiate, uninstall, re-install and re-activate your sharepoint feature
5. restart IIS

As you can imagine, all this takes a while and (despite being very useful) it severely hampered our productivity. We realised that we didn't need to do a full re-deployment everytime. This was only necessary if we'd changed some of the deployment settings, i.e. in the feature.xml, workflow.xml or one of the InfoPath forms.

Most of the time we should be fine to just re-gac the dll and recycle the application pool (much quicker than restarting IIS).

So I started digging into the PostBuildActions.bat file to see exactly how it ticked. As fortune would have it, the developers of this script also realised that a full redeployment was probably overkill, so they created a QUICK switch that drops most of the steps. Just specify this directly after the DEPLOY keyword...

call "$(ProjectDir)\DeploymentFiles\PostBuildActions.bat" "$(ConfigurationName)" "$(ProjectDir)" "$(ProjectName)" "$(TargetDir)" "$(TargetName)" DEPLOY QUICK

Now the script will only:

1. un-GAC and re-GAC the dll
2. restart IIS

Much better! But we're still stuck with that very slow IIS restart when recycling the application pool would be sufficient.

Fortunately, it's easy to recycle an application pool in script. Now all we have to do is to replace this....

ECHO Doing an iisreset...
ECHO.

CALL iisreset

with this...

ECHO recycling appdomain
ECHO.

call cscript c:\windows\system32\iisapp.vbs /a "SharePoint - 80" /r

Where "SharePoint - 80" is the name of the appplication pool as it appears in IIS Manager (shown above).