I enjoy Mike Gunderloy's The Daily Grind. He gives me a quick overview of what's new in the .NET tools and library market, and throws in the occasional, concise review. This morning I was catching up on his posts and followed a link to an article he wrote titled Working Smarter With ASP.NET 2.0
One section of that article, Managing the Environment, describes the method and code his group uses to choose appSettings specific to the development environment (e.g., Production vs. Development). For example, if file "_prod" exists then it looks for an appSetting with key equal to "[your key name here]_PROD".
IMO, it *is* a bloody ugly hack. But I've been through the same thing just with different code.
What I decided months ago is that I hated putting anything non-production into web.config. I still need appSettings specific to my development environment. But I don't want them to go into web.config. Why? Because if you use version control then you will run into some irritations.
- If you tweak your development-specific appSettings then version control tells you the file has changed. You feel guilty and unsure, so you do a file comparison to see if you really did change something that should be checked in.
- When you do need to make a change that does need to go into production, you have to check out the official version from version control. If you have been mucking with your development-specific settings, you've just wiped them out. Of course, you could copy/paste them back in when you're done.
So I wanted to get rid of the extra steps. The best option I found was to make use of the file attribute on the appSettings element. For example:
<appSettings file="DeveloperAppSettings.config">
... production appsettings here ...
</appSettings>
This tells ASP.NET to look in file DeveloperAppSettings.config for an appSetting, before it grabs the appSettings from web.config. Following is an example of DeveloperAppSettings.config:
<
appSettings>
<add key="ServerName" value="YeOldeDevelopmentServer"/>
<add key="DatabaseName" value="Dev"/>
</appSettings>
So as a developer, I can force my web app to use my development server and database. Without touching web.config. If my version control tool allows it, I can have it ignore the existence of file DeveloperAppSettings.config.
However, this doesn't solve the case where you have version control plus multiple development environments (e.g., dev, qa, staging). For this case, you have to once more rely upon a bloody ugly hack.
--
Sean Winstead
Tags: ASP.NET