Don’t Disrespect the Web.Config – Transformations

No matter how large of a project you are building nor how many lines of code you maintain, the most important file in your whole solution is likely the web.config file. It potentially contains connection strings, API keys, passwords, etc. If any of this information is incorrect you will likely see many problems in your application. Likewise, if a hacker were able to examine this file, it could mean disaster for your network. It is for these reasons that the web.config file must be treated with the utmost respect.

There are 3 things every public website should be doing with their web.config

  1. Use web.config transforms to keep track of development versus production settings
  2. Encrypt important configuration sections for security
  3. ELMAH – Error Logging Modules and Handlers

Each of the above topics will be covered in a separate post. As for today, we’ll discuss #1. Visual Studio 2010 introduced web.config transforms, which make it dead simple to maintain configuration information for multiple deployment environments.

The scenario:

Imagine the not-so-rare network setup of a website that is deployed on a production server, a test server, and is run locally by developers. In the old days, it was difficult to keep track of all the different environment-specific configuration options. Maybe you set the web.config correctly once for each environment and just never overrode it during a new publish. Maybe you created your own configuration text files that were dynamically linked into the application. Either way you had to spend extra time to solve this seemingly simple problem.

Thank goodness for modern IDEs.

Now it’s extremely easy to setup multiple configuration files in your Visual Studio solution, with these additional benefits:

  • Easy integration into source control
  • Each separate web.config file is tied to a Visual Studio build configuration
  • Easier integration into automated builds and deployments

Since the web.config transformation technology has been around for about 2 years now, I’ll try and introduce a new spin on it by demoing this with the Visual Studio 11 Beta.

How to set it up:

  1. Open your project in Visual Studio 11 Beta. Note: new projects in Visual Studio 2010 and 11 already have multiple config transformation files.
  2. Open the Build menu and navigate to the Build Configuration manager.
  3. Click the Active solution configuration drop down list and select New.
  4. Enter information for your test environmentbuild configurations
  5. Right click on the web.config file and select Add Config Transform. Note: If this option is not available, see this link.web.config transforms
  6. You will now see a web.config for each environment you support (Debug representing the developer’s local environment, Test representing Test, and Release representing production).

    config transform

  7. Next, we introduce the environment specific settings for your web.config files
    1. My web.config files typically have environment-specific information in the appSettings and ConnectionString sections:

    <appSettings>
            <add key=apiKey value=“83ABC029538FED091ACDD”/>
    </appSettings>
    <connectionStrings>

    <add name=DBConnectionString connectionString=Data Source=DBServer;Initial Catalog=DatabaseName;Persist Security Info=True;User ID=userName;Password=password providerName=System.Data.SqlClient/>

    </connectionStrings>

    1. Since the above is configured for my development environment, I usually leave my web.Debug.config blank
    2. In the Web.Test.config and the Web.Release.config I replace my appSettings and connectionStrings sections with environment specific values (see this website for detailed information on syntax)

    <configuration xmlns:xdt=http://schemas.microsoft.com/XML-Document-Transform>

    <appSettings xdt:Transform=Replace>
            <add key=apiKey value=B153439AB3DE8FF9CA9D0/>

    </appSettings>
    <connectionStrings xdt:Transform=Replace>

    <add
    name=DBConnectionString
    connectionString=Data Source=ProdDBServer;Initial Catalog=ProdDatabaseName;Persist Security Info=True;User ID=userName;Password=password
    providerName=System.Data.SqlClient/>

        </connectionStrings>

  8. Now just choose the build configuration and publish a project. It will automatically merge the correct web.config values based on the selected build configuration.

    asp.net publish

 

Beautiful. Your app has been deployed with the appropriate environment-specific web.config settings. In the next post, we will discuss how to encrypt secure information that is stored in the web.config file.

Advertisements

About Stu
I am a software developer living in Cincinnati, OH. I primarily focus on .NET and Microsoft technologies and have bounced around quite a bit in my short career between multiple cities in the Midwest (including Cleveland, Columbus, Cincinnati, and St. Louis). I would like to learn more about programming, technology, marketing, and how to run a business. -Nathan Stuller

2 Responses to Don’t Disrespect the Web.Config – Transformations

  1. Pingback: Don’t Disrespect the Web.Config – Encryption « Midwest Developer Insights

  2. Pingback: Don’t Disrespect the Web.Config – ELMAH « Midwest Developer Insights

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s