Why do we have different environments? And why do different environments need different configurations? This question need not be answered if you see what those different environments are:
Production/Live, UAT/Staging/Operations/Like-Live, Quality Assurance and Development. One cannot have the same SQL Server in production and Development environment.
Now, about the problem in context. Different teams have different approach to manage web.config entries in different environments. Some edit the file manually after deployment, some edit configurations as part of the installation using some custom actions, some have design approach to have config values stored away from web.config with only the identifiers available in the config file.
In any scenario, all teams have all details of different environments upfront. Given that, would it not be a nice thing to have a one time activity that will ensure configuration changes are automatically applied to different environments as part of deployment? . VS2010 provides you exactly that.
Read about Web.Config Transformation here: http://msdn.microsoft.com/en-us/gg454290
An example:
If you have a connection string in your web.config as follows
<?xml version="1.0"?><configuration><connectionStrings><add name="MyConnStr" connectionString="Data Source=DevIP;Initial Catalog=SampleDB;User ID=sa;Password=sample;" providerName="System.Data.SqlClient" /></connectionStrings>
You can transform the connection string to production settings by adding a web.production.config with content as
<?xml version="1.0"?><configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform"><connectionStrings><add name="MyConnStr" connectionString="Data Source=ProductionIP;Initial Catalog=SampleDB;Integrated Security=True" providerName="System.Data.SqlClient" xdt:Transform="Replace" xdt:Locator="Match(name)"/></connectionStrings>
Replace Transform means the entire node will be replaced in the web.config with entries specified here. Web has information aplenty on this; explore and enjoy learning.
PS: "Do google to learn more" sounds fine, why not "Do bing to learn more"??
Production/Live, UAT/Staging/Operations/Like-Live, Quality Assurance and Development. One cannot have the same SQL Server in production and Development environment.
Now, about the problem in context. Different teams have different approach to manage web.config entries in different environments. Some edit the file manually after deployment, some edit configurations as part of the installation using some custom actions, some have design approach to have config values stored away from web.config with only the identifiers available in the config file.
In any scenario, all teams have all details of different environments upfront. Given that, would it not be a nice thing to have a one time activity that will ensure configuration changes are automatically applied to different environments as part of deployment? . VS2010 provides you exactly that.
Read about Web.Config Transformation here: http://msdn.microsoft.com/en-us/gg454290
An example:
If you have a connection string in your web.config as follows
<?xml version="1.0"?><configuration><connectionStrings><add name="MyConnStr" connectionString="Data Source=DevIP;Initial Catalog=SampleDB;User ID=sa;Password=sample;" providerName="System.Data.SqlClient" /></connectionStrings>
You can transform the connection string to production settings by adding a web.production.config with content as
<?xml version="1.0"?><configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform"><connectionStrings><add name="MyConnStr" connectionString="Data Source=ProductionIP;Initial Catalog=SampleDB;Integrated Security=True" providerName="System.Data.SqlClient" xdt:Transform="Replace" xdt:Locator="Match(name)"/></connectionStrings>
Replace Transform means the entire node will be replaced in the web.config with entries specified here. Web has information aplenty on this; explore and enjoy learning.
PS: "Do google to learn more" sounds fine, why not "Do bing to learn more"??
No comments:
Post a Comment