Split web.config for Different Environments

• Download complete source code - 172.57 KB

Introduction

Splitting the web.config file for different environments is a brilliant thought, since it has many advantages in the level of reducing work, lack of confusion between different files in different environments, rare chance to mess up files between different environment and also in keeping credentials in a secure place. Microsoft has given the facility to do the same and I think a majority of people are not taking advantage of this facility when they setup different environments.

Advantages of Intelligent web.config Splitting

File Structure for Two Different Environments

Production

UAT and Staging

A Case Study

Here is an old environment:

1. We have lots of country sites, they have the same source code but separate domains (for some valid reasons) and separate deployment.
2. We have development, testing, and staging environments.
3. We do bug fixes, performance optimizations and new enhancements.
4. We have some contractors in the team and they know almost all credentials.
5. We have a separate deployment team for testing and staging environments.
6. We have to raise tickets to correct entry or anything in deployment.

We did in the following way before we thought about splitting web.config:

1. We use a NAnt script to copy binary files across all country sites.
2. There is some shared key which has to go to all sites, we do it by opening each country's site and manually updating (sometimes, we are able to do it with a NAnt script, but not always).
3. We do not care much about database passwords and other credentials.
4. Sometimes we mess up configuration files in different environments, and we raise another ticket to change it, and wait for that.

Here are the Real Advantages

1. We store all common keys (appSettings) in a common configuration file and share for all country sites.
2. All credentials like password are moved to another file which can only be accessed by system administrators.
3. We maintain separate specific files for different environments, so there is no confusion at all.
4. Some of the site specific appSettings, we store at site level, and shared appSettings keys are in a shared key file.

You may have many other advantages as well for your scenario.

Source Code Samples

Splitting Keys <appSettings> into two different files.

Web.config

<configuration>
  <connectionStrings configSource="admin.config" />

  <system.web>
    <compilation debug="true" targetFramework="4.0" />
  </system.web>
  
<appSettings file="key.config" >
    <add key="ChildKey1" value="ChildValue1"/>
    <add key="Childkey2" value="ChildValue2"/>
  </appSettings>

  <system.webServer>
    <modules runAllManagedModulesForAllRequests="true"/>
  </system.webServer>
</configuration>

Admin.config

<connectionStrings >
  <add name="BannerConnectionString" 
connectionString="Data Source=localhost;Initial Catalog=Banner;Integrated Security=True"
providerName="System.Data.SqlClient" />
</connectionStrings>

Key.config

<?xml version="1.0" encoding="utf-8"?>
<appSettings >
  <add key="ChildKey1" value="ChildValue1"/>
  <add key="ChildKey2" value="ChildValue2"/>
</appSettings>

Finally, very important:

How to Protect Split Configuration Files from the End User

It is very important that split files are hidden from the end user, and it can be done through the following two methods:

1. The administrator can restrict folder level access by keeping new configuration files in a separate folder.
2. We can restrict files by ASP.NET built-in access system in web.config.

   <location path="Key.Config">
     <system.web>
       <authorization>
         <deny users="*"/>
       </authorization>
     </system.web>
   </location>

Breaking up of web.config does not have much advantage if your environment is any of the following:

1. Small application with a few developers, and no environment other than development and production.
2. Your application does not care much about security of databases used in your application.
3. Your do not have separate administration or deployment teams to do production or UAT deployment.
4. Configuration files in different environments are always in sync for some reason.

Most People will Ignore This for the Following Reasons

1. Deployment will happen very rarely, and also it is a one-time job.
2. People don’t care about security until and unless some unauthorized person accesses the database.
3. Even if configuration files are messed up in different environments, they can be changed with little effort.

Conclusion

This is a simple idea, but I think it is nice to publicize it, and please let me know if anybody has better ideas, or any comments.

Happy reading!

History

• 21^st February, 2011: Initial post