Global Assembly Cache & Versioning [modified]
-
Lets say I have an application called Widgets.exe which references, via the GAC, CommonLibrary.dll. This application and its commonlibrary is then deployed to 1000's of devices. Fast forward a few months and a small bug is found inside commonlibrary. This bug can be fixed without making any changes to Widgets.exe. The relevant developer diligently applies the necessary fixes to CommonLibrary.dll and as a matter of course increases the version number of the library. This is then redeployed, however as Widgets.exe has not changed this is not redeployed. The problem now is that although the public method interfaces on the CommonLibrary have not changed Widgets.exe is expecting to find version 1.0.0.0 of CommonLibrary in the GAC, however this has now been replaced with v1.1.0.0 (which contains the bug fix). So at runtime a not found exception is thrown by the application. Now I perfectly understand this and can see why this occurs etc etc. However the problem I have relates to this and how to manage it in the real world. In the real world, Widgets.exe is actually a very large application framework with many executables, assemblies and common libraries. I am trying to find a way to avoid having to redeploy, uninstall, reinstall the application in its entirity should a minor change be made to one of the common libraries. At the moment to get around this we dont actually use .NET versioning as it should be. At compile time everything in the entire project is compiled to v1.1.0.0 and then we add a revision number to the AssemblyDescription property in AssemblyInfo.cs. This then means we can redeploy single libraries without breaking the dependency/reference chain. The version number would only be increase should a fundamental change be made. While the ghetto style solution works, it doesnt sit very comfortably with me. So the question is can anybody suggest an alternative/better solution to this issue? -- modified at 12:39 Tuesday 31st July, 2007
-
Lets say I have an application called Widgets.exe which references, via the GAC, CommonLibrary.dll. This application and its commonlibrary is then deployed to 1000's of devices. Fast forward a few months and a small bug is found inside commonlibrary. This bug can be fixed without making any changes to Widgets.exe. The relevant developer diligently applies the necessary fixes to CommonLibrary.dll and as a matter of course increases the version number of the library. This is then redeployed, however as Widgets.exe has not changed this is not redeployed. The problem now is that although the public method interfaces on the CommonLibrary have not changed Widgets.exe is expecting to find version 1.0.0.0 of CommonLibrary in the GAC, however this has now been replaced with v1.1.0.0 (which contains the bug fix). So at runtime a not found exception is thrown by the application. Now I perfectly understand this and can see why this occurs etc etc. However the problem I have relates to this and how to manage it in the real world. In the real world, Widgets.exe is actually a very large application framework with many executables, assemblies and common libraries. I am trying to find a way to avoid having to redeploy, uninstall, reinstall the application in its entirity should a minor change be made to one of the common libraries. At the moment to get around this we dont actually use .NET versioning as it should be. At compile time everything in the entire project is compiled to v1.1.0.0 and then we add a revision number to the AssemblyDescription property in AssemblyInfo.cs. This then means we can redeploy single libraries without breaking the dependency/reference chain. The version number would only be increase should a fundamental change be made. While the ghetto style solution works, it doesnt sit very comfortably with me. So the question is can anybody suggest an alternative/better solution to this issue? -- modified at 12:39 Tuesday 31st July, 2007
A trick I use is to change the file version not the assembly version. This will prevent older versions of my app from going down with a patch. Of course if you develop an entire new version of the CommonLibrary and your application it's best to update the assembly version as well. This will help with the problem of having an old assembly with the new application.
WM. What about weapons of mass-construction? "What? Its an Apple MacBook Pro. They are sexy!" - Paul Watson My blog