Practical ASP.NET

Managing Web.Config Settings During Deployment

Moving from a test to a production environment can be tricky. Here's where the Web Deployment Projects add-on comes in handy.

You're probably using the web.config file to hold the connection strings for your Web site. But that makes it difficult to move from your test to your production environment, especially if you're deploying to a Web farm. The solution is to start using Web Deployment Projects.

I hold the connection strings for my databases in the connectionString element of my web.config file. In the test system, those configuration strings point to the test database, but when I move the application to the production system, I need those connection strings to point to my production database.

To make life more interesting, I also encrypt the connection strings in the web.config file rather than store them in plain text. For the encryption, the process uses the machine key for the server the Web site is installed on. But this means that if I encrypt the strings on my test machine, then the strings can't be decrypted on the production machine. Even more interestingly, some of my clients install their applications on Web farms. So, even if I deploy the application with the connection strings correctly encrypted for one production computer, those connection strings won't be encrypted correctly for any other server.

While I could, I assume, ask my clients to use the same machine key for all the servers in a Web farm, I use a different, two-part solution for this problem: Web Deployment Projects and deferring encryption until after the site is deployed.

Replacing and Encrypting Connection Strings
Web Deployment Projects are an add-on available for both Visual Studio 2005 and 2008 that addresses the special implementation issues of deploying ASP.NET projects. I'm not going to describe all the features of Web Deployment Projects, but the support for managing the web.config file was the primary reason that I started using Web Deployment Projects.

Web Deployment Projects allow you to enter a set of name/value pairs where the name refers to a section of the Web.config file and the value refers to a file containing replacement text for the section. For instance, this example replaces the connectionStrings element with the contents of a file holding production connection strings:

connectionStrings=ProductionConnectionStrings.config;

Since Web Deployment Projects provide a reliable way to swap in production-specific settings in my Web.config file during deployment, my next step is to ensure that the configuration strings aren't encrypted until the application is installed on the production machine.

If my client doesn't use a Web farm, the problem is simple: I can just swap in a file with connectionStrings containing the keys as encrypted on the production machine. However, a more robust solution (and one that works on Web farms) is to compile the connectionString section after the site is installed on the production machine. I handle that by putting the encryption code in the Load event of some page that I can be assured will be accessed early in the life of the site. Good choices are the site's login page or the site's Master Page.

In the encryption code, I check a tag in the appSetting section of the site's Web.config file to see if the site is in production or debug mode. The tag that I use looks like this:

<appSettings>
  <add key="Production" value="False" />
 </appSettings>

If the code finds that the Production appSetting is set to True, it opens the Web.config file, finds the connectionStrings section and encrypts it. As this example shows, I also set an Application variable indicating that I've encrypted the section and check that along with the appSettings entry so that I only do this once.

There's one last thing to do: In my Web Deployment project, I also replace the appSettings section of my Web.config file with a file that sets my "Production" appSetting tag to True to trigger encryption on the production site.

About the Author

Peter Vogel is a system architect and principal in PH&V Information Services. PH&V provides full-stack consulting from UX design through object modeling to database design. Peter tweets about his VSM columns with the hashtag #vogelarticles. His blog posts on user experience design can be found at http://blog.learningtree.com/tag/ui/.

comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube