[Ironpython-users] Changing AssemblyVersion in 2.7.5 Beta 2

[Markus Schaber]

Hi, Jeff,

Let me add some thoughts out of my view (I'm managing the IronPython script interpreter hosted within the CODESYS IDE):

Von: 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.

I'm generally strongly in favour of this idea.

> 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.

We exactly had this kind of problems, including a mix between a different IronPython and DLR libraries (parts of them were downgraded), which lead to very naughty debugging sessions.

Luckily, most of this happened in our in-house usage and tests, so no real customer / end-user was harmed.

> The workaround is to do a custom build with a different strong-name key, but
> that's unnecessary work for the common case.

That's exactly what we're doing now.

> 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).

NuGet is not really appropriate for our own build system and workflows (which are established between us and our OEMs since years before NuGet appeared). :-(

(OT: Just to prevent questions: Our Home-Grown "Automation Platform" framework predates MEF, MAF, NuGet and several other, now wide-spread technologies by years, and it is not easy to replace them as we need to strongly respect backwards compatibility for our OEMs which modify and adapt our product. :-)


> 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'm not sure whether those publisher policy is a good thing. We need to make sure that the whole dependency tree (IronPython, IronPython.Modules and the various DLR assemblies) always are guaranteed to match.

Another bunch of problems might arise when we run upgraded IronPython libraries against an older standard library - we ship the (Iron)Python standard library in our own directory (currently 2.7.4), and I'm not sure whether there might be problems when those python files run against a newer (2.7.5, 2.7.6?) version of the IronPython interpreter.

Is there any way a hosting application can influence the publisher policy programmatically?

> 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.

For me, upgrading the Assembly Version is a strict improvement against the previous system. It will most probably eliminate the only reason why we build IronPython on our own right now.

As explained, I'm not yet sure about the side-effects of the publisher policy, but even with them, the situation is not worse than before, and we can still ship our own builds if necessary. :-)


> - 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.

Until recently, our build system and component manager had no way to deal with "external" depencencies which are not signed, and deployed to the GAC. We recently implemented an extension which allows us to deal with external dependencies which are not in the GAC, signed or unsigned.


> [1] https://ironpython.codeplex.com/workitem/35119
> [2] https://github.com/IronLanguages/main/pull/202

Best regards

Markus Schaber

CODESYS(r) a trademark of 3S-Smart Software Solutions GmbH

Inspiring Automation Solutions

3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50

E-Mail: m.schaber at codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com
CODESYS forum: http://forum.codesys.com

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915