Problem with python ProtoGeometry clr reference


#1

Dynamo 0.8.0.950 and Revit 2015 Update Release 7

Is there a setting or similar which controls the default location that Dynamo tries to load DLL/assemblies from?

If I drag a brand new Pythonscript node into the graph (even if I don’t add any further code), then it fails with the following error message:

IOError: System.IO.IOException: Could not add reference to assembly ProtoGeometry
at IronPython.Runtime.ClrModule.AddReference(CodeContext context, String name)

The offending code is: clr.AddReference(‘ProtoGeometry’)

If I change the ProtoGeometry reference to RevitAPI then it works fine. I figure this is because the RevitAPI reference is already loaded into the .net runtime.

Using ProcessMonitor I can see the Revit.exe is trying to load ProtoGeometry from a couple of GAC locations in C:\Windows\ but it’s not looking in the Dynamo installation folder.

Any thoughts on why? Affecting my machine and at least one colleague.
I check antivirus logs, and can’t see any evidence of dll’;s being blocked.

regards

 


#2

Should also add, it works if I provide the full path to the ProtoGeometry DLL, but that means changing the default code for each new Pythonscript node.

clr.AddReferenceToFileAndPath(r"C:\Program Files\Dynamo 0.8\ProtoGeometry.dll")

 


#3

Hello, I don’t believe there is a external setting for this.

Do you have Revit and Dynamo in standard install locations?

Do you see the same problem with DynamoSandbox?

Do you see the same problem with the daily builds?


#4

Michael,

Sorry, I missed your reply, the email notification didn’t reach me.

Yes, Dynamo is in the standard location, see my code snippet above.

Revit is in C:\Program Files\Autodesk\Revit 2015\

I haven’t tried the sandbox or the nightly builds yet.

 

I assume you are setting the paths that are used to resolve assemblies? What are they set to? (Guess I should just open the code…)


#5

Getting the same problem with the latest nightly build. I can see the Dynamo and Revit folders are on the PATH variable

Dynamo – Build 0.8.2.1756

SYSTEM:Environment Path: <other entries removed for brevity> C:\Program Files\Autodesk\Revit 2015;C:\Program Files\Dynamo 0.8


#6

I have been unable to reproduce this behavior on my end. I will look into it further, just to check, are you on windows 7 or 8 /8.1


#7

 

 

Can you try importing sys, and look at what paths are added to the sys.path on the python interpreters startup on your machine?
Screen Shot 2015-06-26 at 2.10.12 PM


#8

As requested, see below for results. We’re on Windows 7.

I tried also importing os.path to get the absolute path of ‘.’ but that didn’t want to play nicely

Dynamo


#9

that’s interesting, so python should add the directory from where the interpreter is being run to the list of sys path (since PYTHONPATH is null because the script is being run interactively thats what the “.” is ), but it’s not. I’ll look into that further. Is your C: drive actually on your local machine? A sym link? A virtual machine ?

in my case, the directory is ProgramFiles\ Dynamo .08 …


#10

are you running dynamo from a shortcut or opening it through visual studio?


#11

Michael,

It’s Dynamo running inside Revit 2015, started from Revit 2015 shortcut, then the Add-ins tab in Revit

C:\ drive is on my machine, which is a normal physical machine (same for the others affected in my office)

It seems to be correctly adding the Revit and Dynamo folders to the windows PATH variable

I found I can’t import the os module either. I do have some other Python installs on the pATH variable, but I’m not sure the others at work do.


#12

importing OS module requires that you add the install location of the python libs to the sys.path variable, it’s like that for all users.

When the python interpreter starts it looks where the script is being run from, since the python node is creating a script in memory we get the “.” null location, this causes python to set search paths to the current directory, which should be ProgramFiles/Dynamo .08/

In your case no other paths are being added.

Can you try from DynamoSandbox, which is installed inside the Dynamo .08 folder in program files ?

Can you also try starting Revit without a shortcut but directly from the start menu or revit exe ?


#13

just to clarify, the PATH variable and sys.path are separate I believe. When the iron python interpreter is running and you call clr.addreference it searches only inside sys.path unless you specify a path


#14

Michael,

Sorry for the delay.

The Dynamo Sandbox seems to work OK, but Revit 2015 still not happy.

 

Paths_in_sandbox

 

 

 

 

 

 

 

I disabled all my addin (except Dynamo) and went back to a very basic, non-customised Revit.ini. I was launching straight from Revit.exe, and going into a new project with no template.

But I still get the same result :frowning:

Anything else we can check?

 

 


#15

Michael,

we may have found the culprit, but want to clarify.

When running on the sandbox we don’t get the clr.AddReference error, and sys.path contained entries pointing at the Dynamo installation folder as shown in my last post.

when running in Revit we’ve identified the cause of the clr.addReference error, put the sys.path variable is still just ‘.’

is the expected value of sys.path when running in Revit just ‘.’. ?


#16

Hi Steven,

I also get . when checking sys.path on revit


#17

Thanks.

Turns out there was an AssembyResolve handler in another plugin that wasn’t dealing so well with assemblies being referenced from IronPython (which doesn’t seem to pass the Culture, Version, etc). Tip 1 here: http://www.codeproject.com/Articles/310675/AppDomain-AssemblyResolve-Event-Tips