Machineconfig versus webconfig Ive Gordon Weaklie
Machine.config versus webconfig.
I've [Gordon Weakliem has] developed some pretty strong opinions on managing configurations, and I've got the scars (and a #12 ranking on Google ;-) ) to prove it. Someone forwarded me this article by Jonathan Goodyear or ASP Today asking what I thought about storing app settings in machine.config versus web.config. Off the top of my head, it sounded like a bad idea, but I'm willing to listen. So I've read the article, and I still think it's a bad idea. Jonathan's reason for discouraging use of web.config were:
- "this approach would require you to change your web.config settings every time you migrated your web application to a different environment"
- "Second, it is not a good idea for the development team to know what the QA and production database connection information is, so storing it in the web.config file doesn't make a whole lot of sense from a security perspective"
<snip>
The real headache with configuration comes with managing the configuration. You need to be sure that as the application changes, the configuration stays up to date, and you need to coordinate use of the <appSettings> section among developers, so that they don't both use the same setting for divergent purposes. [Gordon Weakliem's Radio Weblog]
I have a couple of thoughts on this...specifically as a retort to the two reasons Jonathan Goodyear had for not using Web.config. First, yes you have to change some kind of configuration everytime you change environments, but that's easily fixed in a few different ways.
One thing we do is to have the config file during development include multiple configuration sections each named for the stage of dev the system's in and a VERY simple configurationHandler class to manage it. Kind of an <appSettings environment="test | dev | production"/> kind of thing. Of course, if Jonathan doesn't want some of the QA secrets known by the Dev team, this is less useful considering that until you strip the dev values at the time of production the config file represents the union of all possible keys.
An alternate way I use to update Config files is via a tool a wrote called ConfigPusher that takes an .config-style XML file that contains the UNION of all keys you'd need in all .config (web.config or otherwise) files - useful for a single logical application like ours that consists of multiple physical Web Apps and Web Services. You call ConfigPusher from the command line and it updates only the keys that are present in each of the *.config files from the working directory down. (The master file that represents the union updates only those keys in each config file that intersects with the larger set) You have multiple configs for debug, test, production and you can update the whole bunch in one swell foop without much trouble. Each team can have there own configs. Sure, you're updating Web.config every time you change envionrments, but if this ConfigPusher stage is part of the automated build, so what? Plus, I don't have to ever look at another config file in notepad again. (And of course you don't put database connection into in for the production box, it goes in a secure secret location, ssh!)
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
COM was love