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=188.8.131.52, Culture=neutral, PublicKeyToken=b77a5c561934e089" > <section name="TrompeLeCode.SampleApp.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=184.108.40.206, 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.configunless 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.
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:
- Configuration template (
App.configin the example above) <-- under version control
- File with default values for the tokens <-- under version control
- 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.
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: