What's the best way to create ClickOnce deployments

Question

Our team develops distributed winform apps. We use ClickOnce for deployment and are very pleased with it.

However, we've found the pain point with ClickOnce is in creating the deployments. We have the standard dev/test/production environments and need to be able to create deployments for each of these that install and update separate from one another. Also, we want control over what assemblies get deployed. Just because an assembly was compiled doesn't mean we want it deployed.

The obvious first choice for creating deployments is Visual Studio. However, VS really doesn't address the issues stated. The next in line is the SDK tool, Mage. Mage works OK but creating deployments is rather tedious and we don't want every developer having our code signing certificate and password.

What we ended up doing was rolling our own deployment app that uses the command line version of Mage to create the ClickOnce manifest files.

I'm satisfied with our current solution but is seems like there would be an industry-wide, accepted approach to this problem. Is there?

Answer 1

I would look at using msbuild. It has built in tasks for handling clickonce deployments. I included some references which will help you get started, if you want to go down this path. It is what I use and I have found it to fit my needs. With a good build process using msbuild, you should be able to accomplish squashing the pains you have felt.

Here is detailed post on how ClickOnce manifest generation works with MsBuild.

Answer 2

I've used nAnt to run the overall build strategy, but pass parameters into MSBuild to compile and create the deployment package.

Basically, nAnt calls into MSBuild for each environment you need to deploy to, and generates a separate deployment output for each. You end up with a folder and all ClickOnce files you need for every environment, which you can just copy out to the server.

This is how we handled multiple production environments as well -- we had separate instances of our application for the US, Canada, and Europe, so each build would end up creating nine deployments, three each for dev, qa, and prod.