Different app.config for ClickOnce application

Question

We have a ClickOnce deployed application deployed at 2 different places. Both need some different settings in the app.config (In addition the devel environment)

Right now the process of generating these installations is for someone to manually change these settings from visual studio and rebuild. This is ofcourse a pain.

Some suggested we make an additional project within our solution who pretty much only contains the app.settings and just run the main form in the other project.

How do people handle this ?

(I'm looking for concrete solutions/examples, "use an automated build system" might be the goal but it's not very concrete..)

Answer 1

I would move these settings out of app.config. We've had numerous issues with maintaining config setting values during ClickOnce updates and I don't trust it any more. I would move these settings into a lightweight database, such as SqlLite or SqlCe and distribute that with your application. Then maintaining the settings is just a matter of populating different values in the database.

Answer 2

I think there are two solutions:

• As you said, create a multiple-projects. The project basically represent the right app.config, the right deploment-configuration etc. Otherwise it just delegates the codeflow the 'real'-project.
• Another possibility is to create multiple app.config files. Like app-develop.config => Develop-Version, app-productive.config => Productive-Version, app-other-thing.config... Now you're add an additional task to the MSBuild-file (.csproj) which copies the right app-*.config to the app.config-file. We do something like this in with our log-configuration and it works fine.

Answer 3

I have blogged about our solution to this which works well.

Basically we have a separate file which contains all configurtion info for each environment (i.e. different deployment location), the build process uses this this info to set values in the config file/local database.

The solution doesn't interfere with developers day to day activities and works with ClickOnce deployments (ie the config file is updated before the manifests are signed).

Let me know what you think of the solution...good or bad :-)