Here is the setup:
We have a common library that I've developed that is used by all developers on any new applications or more than trivial changes to old applications. When we make a change, we up the minor version number (2.0 to 2.1) if the API is not broken, but if we break the API then we up the major version number (2.1 to 3.0). There is an installer package built for every new version and it is deployed to the servers and made available to developers to install when needed. The installer puts the assemblies in the GAC on the servers, and modifies the machine.config to include some configuration information.
The most recent version (4.0) uses the System.Configuration namespace pretty heavily (custom config sections and config section groups), but there's a problem I didn't think of, and I'm not quite sure how to solve: when upgrading versions, we have version clashes with the configuration sections.
For example, in the machine.config file it puts in the config section information for specifying the application name. It looks something like this:
<section name="application" type="CommonLibrary.Configuration.ApplicationSection,
CommonLibrary, Version=4.0.0.0, Culture=neutral, PublicKeyToken=sometokenhere" />
So now that we have version 4.1, this section definition breaks because the application is using the version 4.1 dll and the machine config is telling it to load version 4.0 dll.
What is the best way to deal with this issue? You have to keep in mind that the possibility of fixing a critical issue and using publisher policy files to redirect older versions to newer minor versions is there, so a solution would have to account for that (unless we decided not to allow for that and only do in place fixes for critical issues)
Thoughts? Opinions? Advice?