Manage multiple app config files during development
Asked Answered
A

7

12

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?

Algeria answered 6/10, 2008 at 20:29 Comment(0)
A
2

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.

Algeria answered 3/9, 2009 at 6:14 Comment(0)
C
7

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/

Crossjack answered 22/8, 2010 at 14:23 Comment(0)
T
3

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

Tendinous answered 6/10, 2008 at 20:30 Comment(3)
This works, although it's a lengthy work around for functionality that should really be in the IDE.Stinky
It also requires me to create two configurations (debug and release) for each customer. That smells like the wrong answer to me.Algeria
This works like a charm. Each location (QA/DEV1/Production) has their own config file. ZERO HASSLE. This just works. you are a genius!! I did this for app.config that works with a WCF service per client per location. Works like a charm. you are my hero!Esposito
G
3

Thinking about the mess of managing multiple configuration files I made this tool: http://envride.codeplex.com/

Its purpose its exactly to make it easier to manage multiple configuration files in an automated way. I would be very pleased if you would take a look at it.

Gopher answered 15/4, 2011 at 12:3 Comment(0)
A
2

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.

Algeria answered 3/9, 2009 at 6:14 Comment(0)
H
2

This thread is too old to represent current tools in VS.

  1. You can use an addon that acts similar to web.debug.config but for app.config.

https://marketplace.visualstudio.com/items?itemName=GolanAvraham.ConfigurationTransform

  1. And for the same app.config transformations without addon.

https://www.linkedin.com/pulse/multi-appconfig-visual-studio-2017-benjamin-davis/

Humic answered 28/9, 2018 at 6:40 Comment(0)
R
0

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

Radon answered 11/5, 2009 at 2:4 Comment(0)
F
0

After a little digging and work around I got my Test project working with multiple configurations,

  1. In the Configuration Manager, create the configurations you need
  2. Copy paste your app.config and add the name of the configuration, in my case is AHI, FIV, MGC, so my config files look like: App.AHI.config, App.MGC.config, App.FIV.Config. You can name it how ever you wanted, but keep the same convention
  3. Add a Post-Build event. In my case it would look like: xcopy $(ProjectDir)app.$(ConfigurationName).config $(TargetDir)$(TargetName).dll.config /y

here is my post, so you can read it with more details

Running a Test Project with Multiple Configurations

Flexed answered 18/2, 2016 at 22:10 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.