Here is my scenario:
I have a WPF application which I am delivering via ClickOnce. The application has multiple environments for multiple clients (currently 9 but expecting to double that in the near future).
The process I currently use is (basically):
- Token replace parts of the app.config
- Token replace parts of the WiX file used in the generation of the MSI installer (including the signing certificate and thumbprint)
- Build the solution
- Create a Client/Environment specific installer
- Repeat for each client/environment combination
This has the benefit of meaning that to install the application it is a simple case of running the required installer. However, the downside is that if (when) I need to create a new environment, I have to re-run the whole build process with a new set of configuration parameters.
How can I make this all better?
My latest thought is that I split out my build process to just create the binaries. Then have a separate packaging process that that pulled in the appropriate binaries, patched configs, (re)signed manifests using MAGE etc.
This will have the continued benefit of “build once, deploy multiple times”, whilst ensuring that if new environments were required they could be repackaged without rebuilding the binaries.
Does this sound like a sensible approach?
Does anyone have any guidance for such a scenario?
Thanks
That sounds like a step in the right direction, and is similar to what I’ve been doing for a WPF application for a couple of years, and it has worked well.
We build the solution with Team City and then have multiple after build steps which handle the ClickOnce publishing, one step for each configuration. Each configuration involves kicking off an MSBuild file which uses Mage.exe. It copies the solution output files to a temporary directory and then performs numerous replacements on files such as the App.config and runs various custom MSBuild tasks.
The MSBuild project file contains base settings and environment overrides for things like the ClickOnce download URL. We also have to do some hacky replacements on the generated manifest itself (and then re-sign it) for things like marking particular files as data, or not.