[Ironpython-users] Changing AssemblyVersion in 2.7.5 Beta 2

[Jeff Hardy]

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