Manage multiple app config files during development

Question

I'm building an application that is used by several different customers. Each customer has a fair amount of custom business logic, which I have cleverly refactored out into an assembly that gets loaded at runtime. The name of that assembly, along with a number of other customer-specific settings, are stored in the application's configuration file.

Right now, here's what I have to do in order to debug the application for customer foo:

1. Go to the filesystem in my project directory and delete app.config
2. Copy app.config.foo to app.config.foo - Copy.
3. Rename app.config.foo - Copy as app.config.
4. Tell Windows that yes, I want to change the file's extension.
5. Switch back to Visual Studio.
6. Open the Settings.settings item in my project.
7. Click "Yes" 13 or 14 times as VS asks me if I want to use the new settings that have been changed in app.config.
8. Close Settings.settings.

Okay! Now I'm ready to debug!

It seems to me that the rigamarole of opening Settings.settings is, or ought to be, unnecessary: I don't need the default values in Settings.cs to be regenerated, because I don't use them. But it's the only way I know of to make VS aware of the fact that the app.config file has changed, so that the build will copy it to the output directory.

There's got to be an easier way of doing this. What is it?

Answer 1

You can refer this post for some good practices : Managing Multiple Configuration File Environments with Pre-Build Events

Answer 2

While I have not worked on this scenario, the default app.config can have a pointer to an external config (which can be customer specific)

In your app.config, you can have customerSettings="path to customerXConfig.config".

Does that help?

Answer 3

You may opt to define multiple Visual Studio solution configurations, one for each customer, and have customised MSBuild targets for your Windows app project.

I have documented the steps of how I handled this here. Multiple app.config files for deploying to different environments

Answer 4

A couple of people suggested using multiple VS configurations, which I think would have worked, except that it would require me to rebuild the solution every time I switched between configurations.

What I did instead seemed a little stupid while I was doing it, but I've been using it for nearly a year now and it works extremely smoothly. In my project directly, I create a separate app.config.XXX file for each customer. The actual app.config file is used solely to generate Settings.cs - it has all of the correct setting names and their default values. It doesn't get copied to the build directories, ever.

Then I wrote a little program that lets me select a customer, and that simply goes through the directories for each project and, if I selected customer XXX, copies app.config.XXX to bin\debug\myprogram.exe.config and bin\release\myprogram.exe.config. As long as this program knows where the root of the solution is (I have to be a little careful whenever I branch the code), it works like a charm.

Answer 5

You can also let Visual Studio automate Robert`s approach by:

1. Define a Build Configuration for each client
2. In the post build event, simply xcopy app.config.xxx to your bin folder. Where XXX is the name of a Build Config accessible in VS. Something like: xcopy app.config.$(ConfigurationName) $(OutDir)/app.config

VS will drop a distinct build for your clients in separate folders, aolong with the proper config file. bin/Client1/ bin/Client2/