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.
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:-
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>
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.