This project has moved and is read-only. For the latest updates, please go here.


GAC deployment problems with 4.5 versioning


I understand the main idea behind version changes in 4.5 but i would like to point out new issue that it raises in combination with GAC deployment. In our environment we have a multiple applications deployed on our server pool where each application could use different JSON.NET release. We deploy all 3rd party dependencies into GAC to avoid having a copy in each application all around the server. Now with version 4.5 all JSON.NET releases will be an identical assembly from GAC point of view.
1) You can not tell which release is in GAC without a manual close examination. Automated tools using "gacutil /l Newtonsoft.Json" will tell you just the assembly version for all releases. Someone has to manually open assembly directory in windows folder, find the Newtonsoft.Json, open its properties and read file version. That has to be done on every server in the pool just to confirm that correct release is deployed.
2) Usual GAC deployment of newer releases does not work. Command "gacutil /i Newtonsoft.Json" on release 2 will say that assembly is already installed if release 1 is present. You have to add and /f flag to force overwrite existing assembly to get new release deployed.
3) Multiple releases of version 4.5 can not co-exist in GAC. While there "should not" be any breaking changes, all applications must undergo proper testing and "get ready" for new release of a dependency. Before our applications could be simply switched over to a new version one by one because they could locate appropriate release in GAC. Now they are all forced to a new release at the same time.
4) Staging of application upgrades becomes harder. We pre-deploy all GAC dependencies ahead of actual application release date to reduce our maintenance window. We can no longer do that with JSON.NET because it overwrites the current JSON.NET and all current applications start using new version immediately. This is not intended since they were never tested with it.
Please consider returning to the previous versioning system.
Closed Apr 13, 2012 at 12:10 AM by JamesNK
No matter what option I choose no one will be completely happy and strong naming plus a continually changing version number plus NuGet was causing issues for everyone, see - the source is included so if version numbers are important you could update it yourself and build with your own key.