tags:

views:

141

answers:

6

In my organization we have multiple environments (Dev, QA, Stage, Prod, Disaster Recovery) and I would like my app/web.config files to contain no environment specific details in URIs, connections strings, etc. My preferred approach would be to perform run-time substitution, e.g. Instead of this:

<endpoint address="http://MyDevWebServer/SomeService" binding="basicHttpBinding"...

I'd prefer to have something like this:

<endpoint address="http://{Env:WebServerName}/SomeService" binding="basicHttpBinding"...

This is simple for config settings read from classes I have control over (just provide a wrapper that performs substitutes {Env:WebServerName} with the actual server name for that environment) but I also want this substitution to take place when settings are being read from classes I have no control over (e.g. WCF, NHibernate etc.). Does anyone know of a way of injecting this kind of substitution logic. I'm assuming an AOP approach might be possible but don't personally have much experience with AOP frameworks.

+1  A: 

You should be able to do this by deriving a custom class from ApplicationSettingsBase which provides this substitution.

I recommend reading up on the Application Settings Architecture. It describes the process for making your own settings architecture, including setting your own handler, which can read from any source, or do other work in the process.

Reed Copsey
+1  A: 

One approach is to use the ConfigSource for a configuration section (appSettings, connectionStrings, etc.). See http://msdn.microsoft.com/en-us/library/system.configuration.sectioninformation.configsource.aspx for more information on it. That way the web/app.config can contain the core information, and the unique environment settings can be set in the file for that environment.

Agent_9191
+1  A: 

We have a post-build nant script which uses XPath to identify and replace environment specific values, depending upon which environment we are targeting. All config values are for development environment by default. This adds a short delay to the build process, but has proved to be a very robust solution in practice - ie no messed up or crossed environment settings.

Chris Ballard
A: 

We moved our setting to the database and haven't had to deal with this since, see here.

JBrooks
A: 

I competely agree that this kind of substitution would be desirable, and requested this feature on Microsoft Connect.

Not much interest from Microsoft though :(

Joe
A: 

While you're trying to find a way to do a run-time substitution, I'd suggest that a build-time substitution would be a better solution in this case. For example, we're using nant task xmlpoke to substitute config values during the build. You can also try web.config section replacement in web deployment projects or XmlMassUpdate task from MSBuild Community Tasks (example).

AlexD