Embedded and installed IronPython - dll versions confusion

Question

I have application that has embedded IronPython and uses it to execute scripts that users write. When only my application is installed everything works as expected. I have embedded IronPython 2.7.4 dlls (my exe and IronPython dlls are in same folder after installation).

However, on some client machines there is IronPython 2.7.2 installed. It installs its dlls into GAC and my application ends up using them, instead of dlls that I shipped with application and application. This causes my application to fail, since I use property that is not available in 2.7.2.

Problem is that .NET sees these assemblies as having the same version (2.7.0.40) for some reason. As you can see in image below / file versions are different: enter image description here

Right one is the one I ship with my application and left one is one that comes with IronPython 2.7.2. I do not register anything to GAC, but this it what is registered in GAC (IronPython installation added it):

C:\ $ gacutil /l | findstr IronPython
  IronPython, Version=2.7.0.40, Culture=neutral, PublicKeyToken=7f709c5b713576e1, processorArchitecture=MSIL
  IronPython.Modules, Version=2.7.0.40, Culture=neutral, PublicKeyToken=7f709c5b713576e1, processorArchitecture=MSIL

As you can see, they are registerd for version 2.7.0.40.

My question is - how can I force my application to use 2.7.4.1000 version of IronPython assemblies and not 2.7.2.1001 that is registered in GAC? Why is .NET ignoring third component of version number and can it be changed?

Edit:

If it is important, with IronPython 2.7.2 installed, my program fails with following error:

Unhandled Exception: System.MissingMethodException: Method not found: 'Boolean IronPython.Hosting.PythonConsoleOptions.get_BasicConsole()'.

Future versions of IronPython (3.0) will also include unsigned assemblies to include with applications that will avoid this issue. — Jeff Hardy, Jan 13 '14 at 13:45
Thans for the comment, I am looking forward to IronPython 3.0. — del-boy, Jan 13 '14 at 20:29

score 3 · Accepted Answer · edited May 23 '17 at 11:58

The problem is, that both IronPython 2.7.2 and IronPython 2.7.4 have the same assembly version number, which is, as you reported, 2.7.0.40.

So, given that, your issue is that apparently, there is a version of the IronPython.dll assembly in the GAC, and a local version, with the same version number. According to that answer, there is no way to load your local version instead of the GAC version.

Given that situation, I can think of two possibilities:

Recompile (or postprocess and re-sign) the IronPython.dll assembly with a new version number, and use an assembly redirection so that requests to the regular IronPython.dll assembly are redirected to your local assembly;

When starting your application, check the IronPython version and, if you detect an inappropriate version of IronPython, ask your consumers to update their installations to IronPython 2.7.4. E.g.:

string ironPythonFileVersion = ((AssemblyFileVersionAttribute)typeof(IronPython).Assembly.GetCustomAttributes(typeof(AssemblyFileVersionAttribute), false)[0]).Version;
if (ironPythonFileVersion == "2.7.2.1001") {
    // IronPython 2.7.2 was loaded. Deal as appropriate.
}

Forcing clients to upgrade IronPython is not an options, but other suggestion solved my problem. I have used ILMerge to change assembly version of IronPython to 2.9.9.9. I do not beleive that it will reach that version number in v2 branch, so I should be safe. When targeting that version there is no problem when older versions of IronPython are installed. — del-boy, Dec 30 '13 at 12:29
It turned out that 2.9.9.9 is not working for me, since PyCharm is checking assembly version and it does not know how to handle pyhton 2.9. Changing version to 2.7.32768.32768 did it (just in case if anyone else need it). — del-boy, Jan 13 '14 at 20:28

score 0 · Answer 2 · answered Dec 29 '13 at 18:14

0

I'd suggest looking into Redirecting Assembly Versions. You'd do something like this in your app.config:

<dependentAssembly>
   <assemblyIdentity name="IronPython"
     publicKeyToken="TOKEN"
     culture="en-us" />
   <!-- Assembly versions can be redirected in app, 
     publisher policy, or machine configuration files. -->
   <bindingRedirect oldVersion="2.7.2.1001" newVersion="2.7.4.1000" />
   <publisherPolicy apply="no" />
</dependentAssembly>

The key here is to add the publisherPolicy element. It appears that IronPython has a publisher policy that is causing your problem, so you should try overriding it.

answered Dec 29 '13 at 18:14

Sven Grosen

5,616
3
30
52

1

This solution will not work, because the `2.7.2.1001` and `2.7.4.1000` version numbers are version numbers specified with the `AssemblyFileVersion` attribute, not the `AssemblyVersion` attribute. – Jean Hominal Dec 29 '13 at 19:19
@JeanHominal You are right, I missed that detail on my initial reading. – Sven Grosen Dec 30 '13 at 14:35

Embedded and installed IronPython - dll versions confusion

2 Answers2