This project is read-only.

Usage Scenarios

The way in which you use ConfigGen is obviously up to you! Here are some suggestions. If you use it in different ways, please feel free to describe them here.

Check in all configs every time (recommended by dysondan).

One approach to using ConfigGen is to get you developers to run ConfigGen every time they make a configuration change and check them the generated output files. This means you always have the latest configuration files, for all machines and environments, in source control.The benefit of this is that you have a full change history of the actual deployed config, rather than just the settings and templates. It makes it a lot easier to diff what has been deployed in different versions. You can even go as far as to write tests to ensure that the checked in configs match the template and settings files.

New: Such a test might make use of the new --error-on-change command line option using these steps:-

  1. Run your commands to generate your config and check the output files it in to source control.
  2. Execute the same commands again but with the -ec or --error-on-change switch.
  3. This switch runs the same command as before, generating exactly the same files as before, but it returns an error and non-zero exit code if any files are changed. The expectation is that no files should have changed if your developers have done their jobs and inspected the output files and checked them into source control.
  4. Set up the --error-on-change version of your commands to execute in a continuous integration environment and you will get a very early broken build when the settings, templates and version controlled output don't match


For this usage scenario, you probably want to always build all configs, so you would probably run something like the following as a manual step from the command line, or maybe via a pre-checkin hook:

cfg.exe -s <path-to-settings-file> -t <path-to-template-file> -o <path-to-dir-under-source-control>

 

Build as required

You may feel it is not necessary to put the generated configuration files under source control, as long as you have the settings file and template file under source control. In this scenario, you may want to build just the local configuration file while developing and have a separate build step to perform generation of all the configuration files to be stored as build artefacts.

If so, you can use the following as a pre-build event in Visual Studio so that your configuration file is generated just before the project is compiled:

cfg.exe -s <path-to-settings-file> -t <path-to-template-file> -o <project-directory-containing-App.Config> -l



It may make sense to take your App.Config out of source control.

For your main build (e.g. on a build server) you would probably still want the full configuration build such as in the previous example.

Last edited Oct 21, 2013 at 11:19 AM by dysondan, version 3

Comments

No comments yet.