Build approach for creating ClickOnce packages for multiple environments - wpf

Question

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

Answer 1

We had a similar scenario, with a WPF ClickOnce application used in multiple environments, where the only thing in app.config is a connectionstring.
To get around the fact that you can not change the configuration file within the clickonce package without having a build process building one package for each client/environment we came up with a solution that lets you place an app.config file in the server deployment folder and let the application access that at runtime.
To do that, we created a static class that initializes in app.xaml.cs OnStartup event.
public static class DbConnectionString
{
public static string ConnectionString { get; private set; }
public static string ActivationPath { get; private set; }
public static void Init()
{
string dbContext = "myDbContext";
string configFile = "App.config";
ConnectionString = "";
ActivationPath = "";
ActivationArguments actArg = AppDomain.CurrentDomain.SetupInformation.ActivationArguments;
if (actArg != null)
{
if (actArg.ActivationData != null)
{
try
{
var actData = actArg.ActivationData[0];
var activationPath = Path.GetDirectoryName(new Uri(actData).LocalPath);
var map = new System.Configuration.ExeConfigurationFileMap();
map.ExeConfigFilename = Path.Combine(activationPath, configFile);
var config = ConfigurationManager.OpenMappedExeConfiguration(map, ConfigurationUserLevel.None);
var connectionStringSection = config.ConnectionStrings;
ConnectionString = connectionStringSection.ConnectionStrings[dbContext].ConnectionString;
ActivationPath = activationPath;
}
catch (Exception)
{
ConnectionString = "";
ActivationPath = "";
}
}
}
}
}
In the Project settings under Publish/Options/Manifests tick the "Allow URL parameters to be passed to application"
I then use the ConnectionString property of the static class where I need a connection string. It will not be set unless you deploy the app as online only, so we default to the app.config within the package for dev/testing.
It is a bit convoluted, but works well, and you only have to publish your app once and provide an app.config for each installation that does not change between builds.
It also sets the property ActivationPath which is the path to the clickonce server install directory.

Answer 2

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.