Yes, believe it or not, we still use WSPBuilder for a number of our older projects.I recently came across a bit of an oddity, though, regarding the ‘Buildmode‘ parameter.

When you use WSPBuilder to package a solution it automatically tries to find the output assembly to include in the package. However, it might find multiple copies of the assembly – particularly as you might have both debug and release builds.

The Buildmode parameter alleges that it lets you choose which assembly to pick and package.

-BuildMode [Default|Debug|Release] (Default is ‘Default’) BuildMode is to determine where to read the DLL’s from. In ‘Default’ mode the WSPBuilder will auto detect where to find the DLL’s. It will use ‘binDebug’ or ‘binrelease’ directory depending on the current directory. In ‘Debug’ mode the WSPBuilder will find the DLL’s from the ‘bindebug’ folder and in ‘Release’ mode the ‘binrelease’ folder are used. However the GAC and 80bin folder are always included as normal.

Sounds good to me. Therefore the following commands should package the debug built assembly, and then the release built assembly. Note that they’re output to different directories.

%WSPBUILDERPATH% -solutionpath "..SomeSolution" -buildmode "Debug" -projectpath "..SomeSolution" -outputpath "Debug"
%WSPBUILDERPATH% -solutionpath "..SomeSolution" -buildmode "Release" -projectpath "..SomeSolution" -outputpath "Release"

Okay, that looks fine. Except I found that when I deployed my debug and release WSPs they were different. The WSP packaged using ‘Debug’ did not put my assembly in the Global Assembly Cache – where it needed to be. The ‘Release’ package put the assembly into the GAC as expected.

Looking at the manifest, that seemed to have been what WSPBuilder put into the solutions. Debug was WebApplication scoped.

So, it was putting the assembly into the web application’s BIN directory. And the manifest did also contain a Code Access Security (CAS) policy – but my assembly needs to go in the GAC.

Annoying. The solution was to remove the buildmode parameter from my script. Instead I use a batch file to:

• Delete all the built assemblies
• Build the debug assembly
• Package the debug assembly, then delete it
• Build the release assembly
• Package the release assembly, then delete it

That way, there’s only ever 1 assembly to package. Sadly, I can only conclude that the BuildMode parameter doesn’t work correctly, though it’s strange that a Debug build should change the assembly’s deployment scope.