.NET Configuration (app.config/web.config/settings.settings)

Question

I have a .NET application which has different configuration files for Debug and Release builds. E.g. the debug app.config file points to a development SQL Server which has debugging enabled and the release target points to the live SQL Server. There are also other settings, some of which are different in debug/release.

I currently use two separate configuration files (debug.app.config and release.app.config). I have a build event on the project which says if this is a release build then copy release.app.config to app.config, else copy debug.app.config to app.config.

The problem is that the application seems to get its settings from the settings.settings file, so I have to open settings.settings in Visual Studio which then prompts me that the settings have changed so I accept the changes, save settings.settings and have to rebuild to make it use the correct settings.

Is there a better/recommended/preferred method for achieving a similar effect? Or equally, have I approached this completely wrong and is there a better approach?

Solution 1

Any configuration that might differ across environments should be stored at the machine level, not the application level. (More info on configuration levels.)

These are the kinds of configuration elements that I typically store at the machine level:

• Application settings
• Connection strings
• retail=true
• Smtp settings
• Health monitoring
• Hosting environment
• Machine key

When each environment (developer, integration, test, stage, live) has its own unique settings in the c:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG directory, then you can promote your application code between environments without any post-build modifications.

And obviously, the contents of the machine-level CONFIG directory get version-controlled in a different repository or a different folder structure from your app. You can make your .config files more source-control friendly through intelligent use of configSource.

I've been doing this for 7 years, on over 200 ASP.NET applications at 25+ different companies. (Not trying to brag, just want to let you know that I've never seen a situation where this approach doesn't work.)

Solution 2

This might help some people dealing with Settings.settings and App.config: Watch out for GenerateDefaultValueInCode attribute in the Properties pane while editing any of the values in the Settings.settings grid in Visual Studio (Visual Studio 2008 in my case).

If you set GenerateDefaultValueInCode to True (True is the default here!), the default value is compiled into the EXE (or DLL), you can find it embedded in the file when you open it in a plain text editor.

I was working on a console application and if I had defaulted in the EXE, the application always ignored the configuration file placed in the same directory! Quite a nightmare and no information about this on the whole Internet.

Solution 3

There is a related question here:

Improving Your Build Process

Config files come with a way to override the settings:

<appSettings file="Local.config">

Instead of checking in two files (or more), you only check in the default config file, and then on each target machine, you put a Local.config, with just the appSettings section that has the overrides for that particular machine.

If you are using config sections, the equivalent is:

configSource="Local.config"

Of course, it's a good idea to make backup copies of all the Local.config files from other machines and check them in somewhere, but not as a part of the actual solutions. Each developer puts an "ignore" on the Local.config file so it doesn't get checked in, which would overwrite everyone else's file.

(You don't actually have to call it "Local.config", that's just what I use)

Solution 4

From what I am reading, it sounds like you are using Visual Studio for your build process. Have you thought about using MSBuild and Nant instead?

Nant's xml syntax is a little weird but once you understand it, doing what you mentioned becomes pretty trivial.

<target name="build">
    <property name="config.type" value="Release" />

    <msbuild project="${filename}" target="Build" verbose="true" failonerror="true">
        <property name="Configuration" value="${config.type}" />
    </msbuild>

    <if test="${config.type == 'Debug'}">
        <copy file=${debug.app.config}" tofile="${app.config}" />
    </if>

    <if test="${config.type == 'Release'}">
        <copy file=${release.app.config}" tofile="${app.config}" />
    </if>

</target>

Solution 5

To me it seems that you can benefit from the Visual Studio 2005 Web Deployment Projects.

With that, you can tell it to update/modify sections of your web.config file depending on the build configuration.

Take a look at this blog entry from Scott Gu for a quick overview/sample.

View more solutions

Comments

[Vinoth Narayan]

I wanna to disable the debug in windows from, I have tried by unchecking all the check box in debug settings, but still I could debug the bin release exe.. Anyone help me on this..

[annakata]

Actually I think that's pretty damned elegant, since I like to keep the various versions of config visible within a solution, even if they aren't live.

[RationalGeek]

What about a situation where you don't control the web server and therefore can't change machine-level config? Examples include a 3rd-party web server or a web server shared amongst multiple departments in an enterprise.

[Portman]

Wouldn't work. But in the era of virtual machines, Amazon EC2, and $400 servers from Dell, does anybody really do anything serious on shared machines? Not trying to be callous at all -- I really think that if you're working on a shared web server you should reevaluate.

[MPritchard]

Most corporates I've worked at with internal sites host multiple applications on one server - there a reevaluation would have to be done at a corporate level

[Portman]

Multiple applications on one server are fine so long as the apps are all in the same "environment". I.e., you wouldn't want the LIVE instance of App1 on the same server as the DEV instance of App2. For example, your SMTP settings would be shared across all of your applications. In production, you point to a real mail server; in development, you point to a file on disk.

[Mike K]

This is precisely what happened to me over this past weekend. I pulled out a lot of hair trying to figure out why my app seemed to be ignoring my app.config file! It is supposed to connect to a web service and the service url is in my app.config. Unbeknownst to me, when I created the web reference, it also created a Settings.Settings file AND hardcoded the default value into the code. Even when I finally figured out (and removed) the settings file, that default value stayed in the hardcode and got embedded in the exe. VERY FRUSTRATING!! Thanks to this post, now I can get rid of that "feature"

[Mike K]

This is a very intriguing solution. Would love to look over an example of this in action.

[Miguel Madero]

I know that this will work, but this still goes against what I would recommend when trying to automate the deployment. I think that settings are application specific, they need to be version controlled along with the application and evolve together with it. Relying on Machine configuration just shifts, an in my opinion makes it harder. I like to keep together things that change together and deploy them together. If I add a new setting for Dev I likely need an equivalent one for prod.

[Sabuncu]

+1 This answer is the critical one: If you want your setting to go into the app.config file, set its GenerateDefaultValueInCode attribute to False (the default is True).

[kmonsoor]

as of today, except the "SMTP settings" all the linked are "dead" now. An update would be great.