Split Web config for different environment

download complete source code

Introduction

Splitting web config file (Complete source code) 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 environment, rare chance to messed up files between different environment and also in keeping credentials in a secure place. Microsoft has given the facility to do same and I think majority of peoples  are not taking advantages of this facility when they setup different environments.

Advantages of Intelligent web config splitting

File structure for two different environment

Production

UAT and Staging

A case study

Here is an Old Environment

1. we have lots of country sites, it has same source code but separate domain(because of some valid reasons) and separate deployment.
2. We have development , testing, and Staging environment.
3. We do bug fixes , performance optimization and new enhancements.
4. We have some contractors in team and they will be knowing almost all credentials.
5. We have separate deployment team for testing and staging environment.
6. We have to raise ticket to correct entry or anything in deployment.
like many….

We do in following way before we thought about splitting web config

1. We do Nant script copy binary files across all country sites.
2. There will be some shared key which has to go to all sites, we do by opening each country sites and manually update. (sometime we are able to do by Nant script but not always).
3. we did not care much about DB passwords and other credentials.
4. sometime we messed up config file in different environment and we will raise another ticket to change and wait for that.

Cool…Here is the Real Advantages

1. We store all common keys (appsettings) in a common config file and shared for all country sites.
2. All credentials like Password we moved to another file which can only accessed by system Admins.
3. We maintained separate specific files for different environment so no confusion at all.
4. Some of the site specific appsetting we store at Site level and other share app setting keys are in share key file.
and finally you will have many other advantages for you scenario……..

Source code Samples – download complete source code

Splitting Keys (<appSettings>) into two different files

Web.config

<configuration> 
<connectionStrings configSource="admin.config"> </connectionStrings>
<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 splitted config files from end user

It is very important that splitted has to be hidden from end user and it can be done through following two methods

1. Admin can restrict folder level access by keeping new config files in a seprate 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 of web config does not make much advantage if your environment is any of following

1. small application having few developers and it does not have any environment other than development and production
2. Your application does not much care about security of database using in your application
3. Your do not have separate admin or deployment team to do production or UAT deployment
4. Config files in different environment are always in sync
like many reasons ………………..

Most of the peoples will ignore this because of few of following reasons (even me also did)

1. deployment will happen very rarely and also it is a one time job.
2. peoples are doesn’t care about security until and unless  some unauthorized person access database.
3. Even if configuration files messed up in different environment, it can be changed not a big thing

Conclusion

This is a simple idea but I think it is nice to have and please let me know if anybody have better idea or any comments. Happy reading…