GHPY plugins and IronPython installations

Grasshopper Developer
, ,
1

I know there’s been an issue with IronPython compatibilities between independent installations and Rhino’s, and I’m wondering what best practices might be for dealing with it in the long term, on both the developer’s and user’s side.

Previous posts have directed to this troubleshooting page, but it isn’t clear how the fix should be interpreted for Rhino 6 or how to resolve conflicts for compiled .ghpy files in particular.

There’s a plugin we’ve been testing that throws a breakpoint error even if the independent IronPython is updated to 2.7.8 to match the Rhino version, and it isn’t clear under what circumstances (with any version of an independent installation) the plugin will load. Some fixes for a similar issue were discussed were discussed in this thread, but there doesn’t seem to be a general solution. Are there any rules we can follow to make this work consistently, or is it always a case-by-case matter depending on versions and contingencies?

Lastly, are there any future prospects for a broader way to address this? As people may have IronPython installed for a variety of reasons for other software (with Revit/Dynamo for sure), and it would be great to be able to distribute ghpy plugins in a reliable way.

Thanks,

2

Hi @fjurious

yes, @stevebaer and I have been looking into this, see RH-45773. We do not have a definitive answer yet. Here are some key points:

  • problems only manifest themselves if IronPython is installed into the GAC. Users are free to install any IronPython if they perform an xcopy install or an MSI installation without the GAC - Global Assembly Cache. A GAC installation essentially means “only use this version on this machine”. An application that uses a shared assembly that varies with time but requires it to be placed in the GAC is essentially broken.

  • we are looking into ways of reverting the GAC loading principle so that the right version is loaded into Rhino, but this may or may not succeed.

  • to be sure that everything works, users of any Rhino version, at present, should not have an Independent IronPython installation in the GAC that is different than the one shipped with Rhino. Depending on the different version pairs, no Python script will run, some limited functionality will be working, or some functions in the os module, as well as module and stack introspection will not work. The last problem also breaks GHPY loading. This is essentially a measure of the ‘evolutionary distance’ between the two versions.

  • I heard several of our users be able to make Revit/Dynamo work with the steps explained on this page.

On our side, I can say that we will still look into solving this.

1 Like
3

Guilio,
Thanks for your response! It’s good to have a summary of the important points. And I’ll pay attention to the bug tracker as well.

5

No, unfortunately it simply cannot. AppDomain.AssemblyResolve only gets fired if the assembly is not found. GAC assemblies are always found. See here: “Occurs when the resolution of an assembly fails.”

Thanks,

Giulio

–
Giulio Piacentino
for Robert McNeel & Associates
giulio@mcneel.com

7

Is it possible that Rhino uses a special version of IronPython with a different StrongName?

Or, is it possible to use Assembly.LoadFrom before a GAC load is triggered.

8

We investigated both these possibilities but did not find a final solution to it, yet. There are probably some additional considerations to keep in mind and cases to test.