Developer-Specific Configurations in .NET Projects

August 4, 2012

In my last post I presented TokenReplacer, now I'll explain the main use case that motivated its development: support for developer-specific configurations.

Consider the following scenario: you are working in a project that requires the development of a windows service that processes files dropped into a specific folder. The folder path is configured as an application setting in App.config. There are several developers working in the said service, each one running its own instance. Code is under the control of a version control system (VCS).

In a first approach App.config would look like this:

<configuration>
    <configSections>
        <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
            <section name="TrompeLeCode.SampleApp.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
        </sectionGroup>
    </configSections>
    <applicationSettings>
        <TrompeLeCode.SampleApp.Properties.Settings>
            <setting name="Inbox" serializeAs="String">
                <value>\\servername\sharename\</value>
            </setting>
        </TrompeLeCode.SampleApp.Properties.Settings>
    </applicationSettings>
</configuration>

As you can see, the folder being monitored is a network share and its path is hardcoded in the file. Developers need to create files inside that folder in order to test and debug the code they produce.

There is an obvious problem with this approach: test files created by one developer may be caught by the service from a different developer making the test and debug processes somewhat cumbersome.

The easiest solution for my made-up example would be to define a local folder in App.config and force all developers to create a folder in that path, but lets assume that's not possible. An alternative solution would be for all developers to change App.config without ever committing it into the VCS. I've seen this far from ideal solution used several times with its annoyances:

  • Developers have to remember not to commit App.config unless they are making "real changes";
  • Real changes have to be merged into the locally changed file, which may be not so easy if there are lots of developer-specific configurations being maintained.

Solution

The ideal solution to this problem, at least from my point of view, is to allow developers to override application settings using files that are not managed by the VCS. My proposed solution consists in making App.config (or any configuration file, for that matter) a template with tokens that can be replaced by meaningful values during the build process.

The solution requires 3 files:

  1. Configuration template (App.config in the example above) <-- under version control
  2. File with default values for the tokens <-- under version control
  3. Optional file with developer specific values <-- local file

The first 2 files are under version control, the last file is local to each developer machine.

During the build phase the configuration template is copied to the output folder as is, i.e. without any token replacement; an after-build event performs the tokens replacement using the developer specific configurations, falling back to default values when no developer specific values are provided.

TokenReplacer was developed to support my implementation of this solution.

Alternatives

TokenReplacer is one of the solutions to the problem I explained but it is not the only one. Here are some alternatives you may want to explore: