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

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.