SharePoint Automated Deployment Using MSBuild

  • Article

MOSS Automated Build & Deploy with MSBuild

 

Here are the steps to create an MSBuild script to:

1. Label Visual Source Safe project with a new version

2. Get latest source code to a build server

3. Compile source code

4. Look for .DDF files

5. Build WSPs based on DDF files

6. Deploy WSP to MOSS Farm

 

Pre-Requisites:
MOSS 2007
Visual Source Safe (optional) – ignore Visual SourceSafe targets
.NET 2.0 Framework (for MSBuild.EXE)
SDC Tasks DLLs - https://www.codeplex.com/sdctasks
MakeCabSDK (for creating WSP files) – Unpack in C:\makecab - https://support.microsoft.com/kb/310618
MSBuild Editor (I prefer Notepad)

(click on images to open in new window)

I am going to assume that we are skilled in creating custom components for SharePoint, including features and also configuring DDF files.

If not, check out one of Ted Pattison or Andrew Connell’s postings on Developing Features/WSPs.
https://tedpattison.net/downloads.aspx
https://www.andrewconnell.com/blog/

Ok, first let me sympathize that this can be a rough subject for a lot of developers. I've tried to not jump too fast and break down the steps to creating these scripts. Bare with my lengthy post.

First let’s create the xml file we will use to track our version numbers. It is pretty straight forward. The file is used to label the project(s) in Source Safe, then increment after each build. Name the file version.xml.

Next, let’s create our MSBuild file. It’s a basic text document with a .msbuild extension. I named mine test.msbuild.

Next, let’s add PropertyGroup items. These properties will act like variables for our script to reference. We will use some of these variables in this script and use some in another script.

Now, let’s add ItemGroup properties. These properties will act like collection variable for our script. We can use the variables in ItemGroup to execute commands against each item in the collection. In this example, I am including all folders and sub-folders looking for all .proj files (.csproj and .vbproj) and also excluding any sub-folders named WSSDemo. (Sorry Ted, you were slowing my script down). :) I also did the same for our DDF files.

Next, we need to add references to some DLLs that contain tasks for us to perform operations such as Visual Source Safe interaction and XML manipulation. Add the following lines of code to your msbuild file.

The remaining steps will be adding the targets or custom actions to perform during the script execution. First let’s update our XML file with a new revision number.

Next, let’s label our Visual SourceSafe project with the version number in our XML file. Then let’s get latest of all of the projects under our “ProjectName” project in Visual SourceSafe.

With the source code pulled locally, we can now execute an MSBuild target to compile all of the projects included in the ItemGroup.

Finally, be sure that the DefaultTargets attribute of the Project element is set to the Last target in your document. Additionally, confirm that for each Target element we created, it depends on the correct one previously.

At this point, we could be done - if all we wanted to do was compile. But, let’s take it a step further and create a second msbuild script for the SharePoint solution (WSP) creation process.

Same as above, create a text file with a .msbuild extension. I named mine wsp.msbuild. I reused the same top section of test.msbuild including the PropertyGroup and ItemGroup variables.

Now, we need to add three targets. One for adding the solution to the SharePoint farm, one for deploying the solution, and another for upgrading. The upgradeSolution target is needed so that for each time after the first, you run this script, your code will be updated in the farm. Otherwise, you would need to do a retractSolution, deleteSolution, addSolution, deploySolution – each time. That’s a lot of timers to create.

Again, make sure that the DefaultTargets attribute is set to the last target in your script and that all targets listed have dependencies set up appropriately.

Lastly, we need to create a batch file to call our two MSBuild scripts. A simple deploy.bat file will do:

C:\windows\microsoft.net\Framework\v2.0.50727\MSBuild c:\build\test.msbuild
C:\windows\microsoft.net\Framework\v2.0.50727\MSBuild c:\build\wsp.msbuild
pause

You're all set.  You can use the deploy.bat file to kick off your scripts, or if you're really good...run them from TFS, CruiseControl, or Visual Studio.

SourceFiles:

Download:  test.msbuild  |   wsp.msbuild

(this blog comes with no warranties - use at own risk)