Develop Reference

Manage configuration per environment

How can I instruct app.config to use different reference per environment?
For example: I have a configuration folder that contains 3 folders - Dev, QA and Prod
- Configuration
- Dev
* AppSettings.config
- QA
* AppSettings.config
- Prod
* AppSettings.config
My app.config have this reference
<appSettings configSource="Configuration\Dev\AppSettings.config" />
I would like to have something like
<appSettings configSource="Configuration\[$ENV]\AppSettings.config" />
$ENV config should be defined in appSettings or if not possible other external source.
Also what is the best practice to manage that? (without using fancy Chef server or configuration server).
**I'm also trying to avoid post script manipulation.**

You need to use XML configuration file trasforms (see this MSDN article).
Since default configuration transforms are implemented for Web.config, you need to use a Visual Studio extension to get this feature to any configuration file. Slow Cheetah is a good one.

Another solution can be using environment variables:
Using environment variables for .config file in .NET
Then bootstrap the application to change the app.config at runtime
http://www.codeproject.com/Articles/12589/Modifying-Configuration-Settings-at-Runtime

Easiest way to make web.config transforms for deployment?

Anyone have a preferred method for making web.config transforms? I am curious as to what others have done for this. I hate having to continuously update the web.config every time I update or republish.

A few years ago Scott Hanselman gave a solution using pre-build events and batch files:
http://www.hanselman.com/blog/ManagingMultipleConfigurationFileEnvironmentsWithPreBuildEvents.aspx
Basically you maintain a separate different configuration for each build and run the batch script pre-build to copy over the Web.Config. The obvious disadvantage is that if you have thirty different build configurations you need thirty different configs, but I find it's nice for projects where you only have two or three configs (like hobby projects, or tools you'll only ever be publishing to internal servers). Plus, it's nice knowing that if you want to you can take extra control of the build process if you want to.

The easiest way to use VS built in support:
You have versions of web.config, for your build versions, (by default Debug and Release)
In the release version you can define transforms what are applied during build. The effective web.config will be the result.

Look into the nuget package for slow cheetah: https://www.nuget.org/packages/SlowCheetah/ This does what you are looking for quite nicely. Be aware that it is for publish transformations only, switching to a different config for local debugging will have no affect.

Create a build configuration for each server you want to deploy to
Example
-Dev Server "copy from debug"-
-Prod Server Debug "copy from debug"-
-Prod Server Release "copy from release"-
Then right click your web.config and select "add config transforms"
You will get new transforms for each configuration you added above.
Now configure your web config transforms for each environment.
Now when you publish you can just select the configuration "Dev, Prod Debug, or Prod Release" and out it goes, no need to update them after that.
Now, the base web.config should always be configured for your local environment, so if you set up in IIS locally it will use web.config without any transforms. Your transforms should transform your local settings in the base web.config to w/e they need to be.

How I prevent to get latest or check-in a specific file automatically in Team Foundation Server?

I work on a team that works on a project. I change my project web config file to set a specific connection string but when I check-in or get latest version of project it changes to others connection strings. I have same problem in WCF Service references. appconfig and xsd files of service references always corrupted when I check-in or get latest version of program from tfs and I have to delete service references and add it again! How can I get rid of this?

We had the same issue on our project (with connection strings), and found a good solution: http://msdn.microsoft.com/en-us/library/ms254494(v=vs.110).aspx
By adding a connections.config file for each developer with his own connection string, we just needed to say that this file must not be a part of Source Control. Then in the web.config connectionString section, you just refer to the connections.config file.
Just be aware that you need to either transform your web.config or add the connections.config when publishing the site.
I know you can do the same about the appSettings section in the web.config.
How you do it with WCF, I don't know - but it sounds strange to me that your are not using the same WCF refence.

There are many solutions.
The team uses the same configuration (e.g. everyone uses localhost references)
You separate user from application settings (do not apply to all kind of settings nor projects)
Use transforms and solution configuration to map have per-environment setting
Use configSource to move config section in separate files that are not under version control
I do not think there is a perfect solution, but maybe you apply a mix of these. I strongly suggest to apply them in the stated order.

NLog Config files for different environments in Nuget Package

I am using the Nuget Packager extension to create a Nuget Package to include my Logger project and Nlog. I have this working correctly but had a question about how do i use the correct config file for multiple environments (Dev/QA/Prod)?
Do I have multiple config files, one for each environment in the package? but how does the correct one get applied in QA for example, since different environments might have different listeners or targets? Whats the best way to accomplish this, an example to show how to do this would be great since i am new to Nuget and Nlog.Thanks for your help!

Nlog supports different locations of its config file. One of the location is the main configuration file of application. For more information please see Nlog documentation
Then we can use config transformations option. Visual studio supports this by default for web firendly projects (ASP.NET MVC, WCF etc.). If you application is of different type you can use an extension called SlowCheetah(NuGet Link). More information can be found at this page.
Config transformation deped on build configurations in visual studio. In web project you can see that web.config has two transformations: web.Debug.config and web.Release.config.
Hope it helps

Using separate MSI build for config files for each environment

For one client, I have to deliver a build they use in QA and production. The checksum of the build file has to match - it cannot change at all between QA and production. The configuration for each environment is different, so I have a build that contains just the code and then a separate build for each environment that contains just the environment specific config files. The config file builds puts the files in the same location regardless of environment, so the code can always load c:\myapp\myconfig.xml which will contain the settings for that environment. Most articles I read about this (such as Scott Hanselman's) involve different builds for each environment, but this won't work because the checksum values will be different. Should I deploy these config files some other way, or do I have a viable solution? The one problem with my current solution is it requires multiple config files that are nearly identical but not quite. One change therefore has to be added to multiple files, which is something I would like to avoid, but I don't know how to do it except at build time or with an external script that copies the proper file.

Not sure if your setup is more complicated, but we have a similar problem and we added a custom actions class that updates the config files based on the environment (which the user selects during installation), then you add this custom actions project to your setup project. That way you use one setup exe no matter what environment you're installing to.
Let me know if you're interested and I can post some samples or more info on how we accomplished it.
Here are some more details:
Add a new dialog to your Setup project to request the environment from the user (we use a 4 radio button dialog with the 4 environments we have: dev, qa, staging and production)
Configure the values of the 4 radio buttons and the property that this value will be setting i.e. "environment" (to latter be used by the CustomActions class)
Add a dll project to your solution with a single class (CustomActions)
in the CustomAction class, you read the property we configured in step two as:
if(!this.Context.Parameters.ContainsKey("environment"))
{
string error = "'environment' argument is null. Please configure config file manually";
//...handle your error, etc.
return;
}
string env = this.Context.Parameters["environment"];
now your env variable contains the value we assigned to each radio button in step. You then can use a switch statement to decide what environment the user selected. and update your config file appropriately with:
Configuration config = ConfigurationManager.OpenExeConfiguration(this.servicePath);
//for example, to change your connection strings you'd use:
config.ConnectionStrings.ConnectionStrings["oracle"] = "dev conn string here";
Back in your setup project, add the output of the CustomActions project to your CustomActions editor (View menu -> Editor -> Custom Actions)
Finally, configure the CustomActionData property of your setup project to pass the environment and other variables to the CustomAction class (mine looks something like this:
/serviceFolder="[TARGETDIR]\" /serviceExe="blahblah.exe" /serviceName="MyServiceName" /environment="[ENVIRONMENT]"
Hope that makes sense and applies to your solution!

Assuming:
1) XML config files
2) Total number of changes between builds are few (even if copied to many config files)
I would have the installer handle updating the config files at install time
For instance we use WiX v3 for our installer and update several config files with values during install using the XmlFile element
<util:XmlFile Action="setValue" File="[DIRECTORIES.WEBSERVICES]web.config" ElementPath="//configuration/system.web/compilation" Name="debug" Value="false" Permanent="yes" />