Creating Debug and Release SharePoint Solution Packages
I’m lazy. It’s true. And I’m always looking for ways to be even lazier when developing software. I want my tools and build system to do as much heavy lifting and perform as many repetitive tasks as possible.
In addition to being lazy, I’m also human which means that I occasionally make mistakes. So I want to let my tools to provide guardrails while allowing me to minimize the amount of mouse and keyboard input.
To briefly sum it up, I want to minimize my workload and minimize mistakes.
This is the first of hopefully many entries on that topic. I’ll focus on SharePoint for now since that’s where I spend the greatest amount of time and there are many repetitive tasks.
This post demonstrates how to create Debug and Release SharePoint Solution Packages. There are several other enhancements I’ve made to enable my laziness, but I’ve left most of them out of here to stay focused on the topic. I’ll try to cover the other enhancements in future posts.
I learned how to build SharePoint solutions using this method from Ted Pattison. (See Creating a Solution Package in Windows SharePoint Services 3.0) I’ve stuck with it because it has always worked for me. The only problem is that the path to the Debug or Release assembly has been hard coded in the DDF. Furthermore, I also use Team Foundation Server for source control and I don’t want to check in/check out my DDF every time I have to make this change. But because I’m lazy and prone to making mistakes, I want to avoid any manual input and use Visual Studio’s Solution Configuration to build the Solution Package with the correct output assembly. (See Build Configurations). The idea is that if I want to create a WSP that contains the Debug assembly, I just set the correct solution configuration and build my project. Or if I want a WSP that contains the Release assembly, I just set the solution configuration to Release and build the project. All of this should only take 3 or 4 clicks of the mouse.
I automate the creation of my SharePoint solution package any time build. Thus, I have a custom MSBuild Target that calls MakeCab.exe when my Visual Studio 2008 project builds. I derived this from the work of Andrew Connell. (See Automating Solution Package Creation for Windows SharePoint Services by Using MSBuild)
My Targets file looks something like this:
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="BuildSharePointPackage" xmlns="https://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="BuildSharePointSolutionPackage">
<Exec Command="MakeCab.exe /D BuildType=$(ConfigurationName) /F Solution\cab.ddf" />
</Target>
...
...
</Project>
BuildSharePointSolutionPackage is a relatively simple Target. It just calls MakeCab with a few arguments. Variables are passed in with “/D” followed by a VariableName=Value format. BuildType is the name of a variable passed into MakeCab. Its value is set to $(ConfigurationName) which is an environment variable that Visual Studio 2008 replaces at build-time with “Debug” or “Release”.
/F Solution\cab.ddf tells MakeCab to where to find the DDF relative to the project directory.
Last point on the Targets file: If you’re paying close attention you might have noticed a slight difference between my targets file and Andrew Connell’s. I’m lazier than he is, so did not install the CabSDK or set a PropertyGroup to the path of MakeCab since it already ships with Windows Server 2003 and Windows Server 2008 and is in the path.
Now, let’s move on to the DDF. It looks like this:
;Sample DDF
.Set DiskDirectoryTemplate=CDROM
.Set UniqueFiles=”ON”
.Set DiskDirectory1=Package
.Set CabinetNameTemplate=Sample.wsp
Solution\manifest.xml manifest.xml
TEMPLATE\FEATURES\Sample\feature.xml Sample\feature.xml
TEMPLATE\REATURES\Sample\types.xml Sample\types.xml
bin\%BuildType%\Sample.dll Sample.dll
The last line of the DDF contains the %BuildType% variable to the path of the output assembly. When the BuildSharePointSolutionPackage target calls MakeCab and passes in the BuildType variable, the last line becomes:
bin\Debug\Sample.dll Sample.dll
OR
bin\Release\Sample.dll Sample.dll
With this infrastructure in place, simply select a Debug or Release configuration from Visual Studio 2008 and then kick off a build. The BuildSharePointSolutionPackage target will take care of everything else.
One final caveat: When passing custom variables to the MakeCab command line, you will not be able to use .OPTION EXPLICIT or .Define in your .DDF. I verified with a few guys from the product group.
So there you go. We set up our Visual Studio 2008 project to create Debug and Release builds of a SharePoint Solution Package.