Grasshopper Script Components Compile Folder

Replies to This Discussion

Permalink Reply by David Rutten on October 3, 2013 at 2:48pm

If you add those references to the components, they should get loaded automatically.

If that's not happening, you should probably handle the AssemblyResolve event and load your dlls at that moment.

Script component put the compiled dll and pdb files into the Temp folder, but I think copying files there that need to be loaded is a bad idea.

--

David Rutten

david@mcneel.com

Tirol, Austria

Permalink Reply by Mostapha Sadeghipour Roudsari on October 3, 2013 at 3:06pm

I tried to add the libraries but it gives me the error that Referenced Assembly failed to load.

"... The module was expected to contain an assembly manifest."

Even in Visual Studio I only add the main .dll to references and then I have to copy the rest to the debug/release folder. This is based on their Get Started tutorial!

I agree this is not a good idea but can you help me to get this thing running for now?

I'm also talking with them to see if they can simplify the dependencies. It is ~120 MB and so annoying to copy them every single time.

Thanks,

Mostapha

Permalink Reply by David Rutten on October 4, 2013 at 2:46am

Are these DLLs .NET assemblies or unmanaged libraries?

--

David Rutten

david@mcneel.com

Tirol, Austria

Permalink Reply by Mostapha Sadeghipour Roudsari on October 4, 2013 at 7:26am

The C# libraries are automatically generated by SWIG from C++ code. As far as I understand they are unmanaged and that's why I need to copy them to the folder.

They also mentioned that "C# bindings are 32 bit only." I assume it shouldn't cause any problem for using them in Grasshopper scripting components. Right?

Here you can read more: https://openstudio.nrel.gov/getting-started/getting-started-c#

Thanks,

Mostapha

Permalink Reply by Giulio Piacentino on October 4, 2013 at 8:44am

Hi Mostapha

this seems an interesting topic. Did you manage to make this work? If these are managed bindings, it should be possible to reference these both in C# and in (Iron)Python components.

Would you actually be allowed to post (one of) these assemblies here?

Thanks,

Giulio

--

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

Permalink Reply by Mostapha Sadeghipour Roudsari on October 4, 2013 at 9:39am

Hi Giulio,

No luck yet. I'm not sure if they are really managed libs or not. I assume the problem is the references to the libraries are not explicit references and that causes all these issues.

OpenStudio is free and open source, and their license is the best ever for sharing :). I copied the libraries folder with their example files here so you can copy them to a local folder: (https://dl.dropboxusercontent.com/u/16228160/OpenStudioCSharpLibs.zip)

I also attached a sample gh script. I tried both in GHPython and C# and it gives me the same error.

My next thought is to try an alternative way where I reference the libraries using system registries and not the real dlls. I'm not sure if it would help at all. Will keep you posted about the result.

Let me know if you get it to work! :)

Thanks,

Mostapha

Attachments:

• GH2OPS.gh, 4 KB

Permalink Reply by Mostapha Sadeghipour Roudsari on October 7, 2013 at 3:53pm

Giulio,

I get it to work using the C# component. I needed the 64bit bindings (Thanks David!) and I needed to copy all the libraries to the temp folder where Grasshopper compiles the code.

It still doesn't work inside the GHPython component though. It still give me the same error as before. Why do you think it happens? Does GHPython component compiles the code in a different folder? Or is it something because of the difference between how IronPython calls the libraries versus how C# does it?

I can upload the libraries and the script if you want to give it a try.

Thanks for your help,

Mostapha

PS: Here is a video that shows it works using the C# component:

Permalink Reply by Giulio Piacentino on October 8, 2013 at 3:01am

Yes, can you give me instructions on what you are doing in C#? In theory, if you get that to work in C#, it should work in IronPython, too.

It seems the issue is about file resolution. I can try help our here. There must be a better way than having to copy the files to the temp folder... let's see if we can circumvent that.

Giulio

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

Permalink Reply by Mostapha Sadeghipour Roudsari on October 8, 2013 at 10:07am

Thanks Giulio, Will send you a message with a link to the libraries.

- Mostapha

Permalink Reply by Giulio Piacentino on October 14, 2013 at 2:56am

Just in case someone else looks into this later on, one possible solution was referencing the path where the .dlls are located, with code similar to this:

 

import clr
clr.AddReferenceToFileAndPath(libFolder+"\\openStudio.dll")

import sys
if libFolder not in sys.path: sys.path.append(libFolder)

import OpenStudio as ops

# do other stuff...

 

 

Giulio

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

Permalink Reply by David Rutten on October 4, 2013 at 9:48am

They also mentioned that "C# bindings are 32 bit only." I assume it shouldn't cause any problem for using them in Grasshopper scripting components. Right?

Is Grasshopper running on 64-bit Rhino? If yes, then you cannot use 32-bit dlls.

--

David Rutten

david@mcneel.com

Tirol, Austria

Permalink Reply by Mostapha Sadeghipour Roudsari on October 4, 2013 at 9:53am

Ouch... Yes, it does. That's another problem then! I might be able to compile them for 64 bits from the source code. I'm not sure but I can try it at least.

• ‹ Previous
• 1
• 2
• Next ›
• Page