Discussing the ins and outs of developing for SharePoint and the Microsoft platform

I’m doing some work with a client at the moment to set up a new TFS environment, and as part of that provide a way to have their new build server spit out WSP files for them. I have already gotten all of their developers (except one, he knows who he is :-P) on to WSP Builder as a standard way of generating WSP files for deployment, what I wanted to do now was to let them keep using WSP builder as their team build tool as well.

For those who have searched my blog before you will have seen that I have had some luck with this previously when I talked about How to get TFS to automate your WSP builds with WSPBuilder. There were a few little things about this that bugged me though which drove me to tidy it up a bit more this time around. Here is what the new post build script for a project looks like:

IF ("$(IsDesktopBuild)"=="") GOTO LocalBuild

:TfsBuild

MD "$(ProjectDir)bin\$(ConfigurationName)"
COPY "$(TargetDir)*.dll" "$(ProjectDir)bin\$(ConfigurationName)"
CD $(ProjectDir)
"C:\Program Files\WSPTools\WSPBuilderExtensions\WSPBuilder.exe"
MD "$(TargetDir)WSPs"
MOVE "$(ProjectDir)*.wsp" "$(TargetDir)WSPs"

GOTO Finish

:LocalBuild
"C:\Program Files\WSPTools\WSPBuilderExtensions\WSPBuilder.exe"

:Finish

If you compare it to the old script I was using there are a few important differences:

1. The first line used to depend on you doing a local debug build to determine the difference between the local and team builds, which meant if you did a local release build you would have problems. The new script uses the “$(IsDesktopBuild)” property. This will be empty on a local build, and will return ‘false’ on the team build, so we can use that to determine the difference
2. This will work with both a debug or a release build on the server with no trouble at all as it now uses the $(ConfigurationName) variable where it refers to those folders
3. I removed the need to add WSPBuilder ot the PATH environment variable on the build and dev machines – this was just being lazy on my behalf because I didn’t want to put the full path into the script
4. When we call WSPBuilder in the new script we don’t add any parameters to it. The reason for this is that we use a CD statement to change the working directory before we call WSPBuilder. The benefit of this is that if the project is using a WSPBuilder.exe.config file (See my post “Configuring WSPBuilder settings per Visual Studio project” for details on this) this will make the build server use the settings from this config file, which is in my opinion, just awesome
5. This script does not rely on you setting “Copy to output directory” on any files in your project, it will automatically move the DLL’s into the source code directory on the TFS build server, run WSP Builder against that direcotry, and then move the compiled WSP back to the output folder.
6. This one has less moving and no deleting of files, so will execute quicker on the build server
7. There is no need for a pre-build action in this case
8. The WSP files are included in a sub directory of the output, and all the DLL’s used in them are still included in the output

You can also remove the line after :LocalBuild to stop the postbuild from automatically running WSP Builder on a local build. I like having it there so I thought I would put it in here too. Also you might find you will want to customise the line that uses the COPY statement to copy DLL’s to the project directory to copy only DLL’s that start with your namespace, that way any referenced DLL’s that don’t necessarily belong in the library won’t be in there (so change “$(TargetDir)*.dll” to “$(TargetDir)MyPrefix.*.dll”).

So now the process to get WSP Builder to be used in a team build environment is this:

1. Install WSPBuilder on the build server
2. Add the above script to the post build action of any projects that should output a WSP file
3. Set up a regular team build (remembering that you might need to still add the AdditionalReferencePath attribute to teh default TFSBuildproj file)

That’s it, which makes it much easier to set up than my first attempt at this. If you are using WSPBuilder and TFS then you should definately look at giving this a go.