ClickOnce, Nant and Multiple Configurations

So. My first post that's NOT about troubleshooting unit testing. 'bout time, huh :) This post is about deploying applications using ClickOnce. On my current project we used to deploy the application to a network share using the 'publish' functionality in Visual Studio. It works, but there are several problems with this approach. A better idea is to deploy the application from the build server. I wont delve into the arguments, as they'are all out there. This meant extending our current build script somewhat.

We deploy a test version of the application fairly often. Obviously, it needs to be configured differently than the production version. The first differences that came to mind in our scenario was connection strings, web service URLs and the title of the main window (to make clear whether the program is the test or production version). Also, a requirement for the deployments was that users could install both the production and test version of the program side by side on the same machine. Because of that there was a few more subtle things that needed to be handled. I struggled a bit few these when creating the build script, so I write this post alot for my own reference.

Nant + ClickOnce + msbuild

Each build is scripted using Nant and produces two deployable releases of the software (inspired by these posts by Kyle). The following Nant task can be used to invoke the msbuild 'publish' target for the project in question. The 'PublishDir' property is used to control where the resulting files should be put.

	<msbuild project="${project.file}"> <arg value="/t:publish" /> <arg value="/p:PublishDir=${current.release.dir}\" /> </msbuild>

I actually provide a few more properties to msbuild, but I'll get back to that.

Multiple Configurations

I mentioned that the two versions need different configurations. The stuff that's in app.config are easily changed using Nant's xmlpoke task, but there's an important point here. Changes to any file in the clickonce deployment must be performed BEFORE the manifests are signed, or else the installation will fail. I found two options at this point. Either store a single copy of all the relevant files on disk until it's time for deployment and perform app.config changes and manifest generations on the fly using mage.exe. Or the second option, which I chose (dont't ask why), which is to generate and store two clickonce packages, both by using msbuild, but with different app.configs.

Side by side installation

The more subtle issues that i struggled with appeared when trying to install the two versions side by side on the same machine. Turns out, that the assembly names of the two versions must differ. If my application has an entry point assembly called MyApplication.exe, I had to name the test version something else. If I didn't, ClickOnce would overwrite the production version when I installed the one for test. You can tell msbuild what you want the output assembly to be called by providing a value for the 'AssemblyName' property like this:

	<msbuild project="${project.file}"> <arg value="/t:publish" /> <arg value="/p:PublishDir=${current.release.dir}\;AssemblyName=${assemblyname}" /> </msbuild>

That only works if the application lives in a solution by itself, because now all the projects in the solution will get the same assembly name. I got around that issue by putting a conditional PropertyGroup inside the MyApplication.csproj file:

	<PropertyGroup Condition=" '$(AssemblyNameOverride)' != '' "> <AssemblyName>$(AssemblyNameOverride)</AssemblyName> </PropertyGroup>

Combined with providing the AssemblyNameOverride property to msbuild instead of AssemblyName like before, only the correct assembly changes name:

	<msbuild project="${project.file}"> <arg value="/t:publish" /> <arg value="/p:PublishDir=${current.release.dir}\;AssemblyNameOverride=${assemblyname}" /> </msbuild>

Now the two versions can be installed side by side without overwriting each other, except that they still overwrite each other's start menu shortcuts. To avoid that I provide the ProductName property as well. I also use the PublishUrl property to tell where to look for updates. The final msbuild task looks like this:

	<msbuild project="${project.file}"> <arg value="/t:publish" /> <arg value="/p:AssemblyNameOverride=${assemblyname};PublishUrl=${clickonce.url};PublishDir=${current.release.dir}\;Configuration=Release;ApplicationVersion=${CCNetLabel};UpdateRequired=true;ProductName=${clickonce.productName}" /> </msbuild>

Conclusion

It's better to deploy stuff from the build server than from developer workstations. You can use Nant (or other build tools) to generate builds for different environments, but when using ClickOnce a few steps need to be taken. I hope this post saves someone some time, as I spent quite a while figuring this stuff out :)

UPDATE: You can download a simple example here. You need to set up some shared folder on your computer to try it out (I haven't found a way to clickonce deploy to a local folder).