There's a request on CodePlex[1] to change the AssemblyVersion for 2.7.5 instead of keeping it the same (it's been 2.7.0.40 since the first 2.7 release). The pull request is at [2] and I want to get some feedback before pushing the changes to see how it affects people.
For those who weren't aware (and I envy you), AssemblyVersion - along with the assembly name, culture, and signature (the "4 part name") - is one of the things .NET uses to decide which assembly to load. If an assembly is unsigned/not-strong-named, .NET only uses the assembly name; if it is signed/strong-named, it requires the entire 4 part name to match. IronPython 2.7 assemblies are strong-named because it is required to put them in the GAC and in certain other contexts. By keeping the version same, IronPython releases are drop-in replacements for each other, but this applies backwards as well as forwards (i.e. an app built against 2.7.4 can end up running against 2.7.3). Add in that IronPython installs to the GAC by default and that .NET will always prefer the GAC over non-GAC assemblies and it's a mess. If an app bundles IronPython 2.7.4 (and depends on that version) but the user has 2.7.3 installed, the app will load the 2.7.3 assemblies from the GAC. The workaround is to do a custom build with a different strong-name key, but that's unnecessary work for the common case. In a world with NuGet, it makes less and less sense to have it installed in the GAC *at all* except in rare cases (such as SharePoint or SQL Server that require it). In 2.7.5, the version will change to 2.7.5.0. The new installer will include a publisher policy file in the GAC that binds the new version to anything trying to load 2.7.0.40 (i.e. 2.7.4 and earlier). This is actually no different than it would be if the version number stayed the same, it's just more obvious what is happening. The reason for the change comes to anything built against 2.7.5 - it will no longer accidentally load an older version of IronPython (you may still get a newer one, if there ever is a 2.7.6; I'm still sorting out what policy files allow). Had I known about publisher policy back in 2011 I doubt I would have stuck with the same version the whole time. I don't see a scenario where this causes more problems; it leaves one case the same and improves the other. However, if you see something I missed, *please* let me know. If not I'll push the changes and spin 2.7.5B2 this weekend so that people can test the installer. - Jeff P.S. I was on the fence before, but not after sorting this out: IronPython 3 will not be strong-named and will not go into the GAC. I'll provide a script for anyone who *needs* that, but the default will be for anyone embedding it to distribute it (via NuGet, most likely) and for installations to not potentially mess up everything else on the system. [1] https://ironpython.codeplex.com/workitem/35119 [2] https://github.com/IronLanguages/main/pull/202 _______________________________________________ Ironpython-users mailing list Ironpython-users@python.org https://mail.python.org/mailman/listinfo/ironpython-users
