sticklebackplastic.com

Working with multiple conflicting config files

Categories

• SingleUserBlog

One of the luxuries of working in a corporate environment is the uniformity (and I never thought I'd say that). You're in control of just about everything - you can ensure that all developers are using the same configuration. You can all use the same databases, the same web services, the same web sites.

Working on a distributed, open source project is entirely different. You're not in control of the environments being used. Different developers will have things set up differently. And all this is reflected in different web.config files.

There's just one teensy-weensy problem. The web.config file is under source control, which means there is only One True Copy. And if I change it to get my site working, I change it for everyone else, and break theirs.

Of course I'm talking about SingleUserBlog, and of course, this is a problem we've hit. We're all using a different config to each other, and I've already checked in a config file that won't work for everyone else.

So I've had a play around and I've come up with a solution. It's teetering dangerously close to over-engineered, but it also does the job nicely, and I learned a few things to the bargain.

Since SingleUserBlog uses Web Application Projects, it's an msbuild-based project. And the nice thing about msbuild-based projects is that you can edit the project file, add your own tasks in and Visual Studio will still quite happily run with it.

The idea is quite straightforward. Get rid of the web.config file. Create a default.config file that contains the default settings for the project - the one you'd be happy to release. Then, change the .csproj file to copy this file to web.config and use the ReplaceConfigSections task from the Web Deployment Projects add-in to replace any sections in the file with xml from external files.

The implementation is perhaps a little awkward, but it's not exactly horrible either. First, in the main .csproj file, import a MergeConfigFiles.targets file that does the heavy lifting. This new file needs to set up a UsingTask to include the ReplaceConfigSections task. It also needs to set up a few default properties, such as the name of the config files to copy ("default.config" to "web.config"). It then imports another .targets file, if it exists. This one is $(USERNAME)-MergeConfigFiles.targets. If it doesn't exist, the default.config file just gets copied, unchanged to web.config. If it does exist, it should be another msbuild project that simply sets up an ItemGroup containing ConfigReplacementFiles items. Each item points to a file that just contains xml that will replace a specific section in the web.config file. That section name is defined in the Section metadata item in the ConfigReplacementFiles item. The ItemGroup is fed into the ReplaceConfigSections task.

When a build is run, Visual Studio will copy across the default config file, then process this copy, replacing all the sections listed with the contents of all the files listed. If any of the files change, or if the default file changes, it gets rebuilt. It even deletes the web.config file on clean.

There are a couple of issues with this method, but I don't think any are showstoppers. It's perhaps not ideal to have to define this with an msbuild project file, but it's not difficult. Here's an example:

<Projectxmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <ItemGroup>
    <ConfigReplacementFilesInclude="compilation.config">
      <Section>system.web/compilation</Section>
    </ConfigReplacementFiles>
    <ConfigReplacementFilesInclude="authentication.config">
      <Section>system.web/authentication</Section>
    </ConfigReplacementFiles>
  </ItemGroup>
</Project>

Not exactly difficult. Another drawback is that if you change this .targets file, the changes are not reflected until the project is reloaded. Not ideal, but not major, either. Oh, and it will only work for web.config, too - the web deployment project task assumes that. Supporting app.config wouldn't be too tricky either, but would require a custom task.

One drawback that could actually cause problems is ensuring that your overrides don't override something new, or you only add new things to your overrides, but this is really just something you need to keep track of.

Another interesting drawback is that asp.net will automatically recreate the web.config file for you if it gets deleted. Somehow it knows to call the .csproj file and get it created correctly - well, mostly correctly. It did generate some things incorrectly while testing that, and it always did a full build after that anyway, so everything still worked correctly.

The only files that get into source control are default.config and the initial MergeConfigFiles.targets. The username based file doesn't get added, and neither do the local changes.

It might be easier to download an example and actually try it out. Let me know what you think.