Grasshopper

algorithmic modeling for Rhino

Hallo All,

this has been discussed before however I couldn't find a valid conclusion before.

As part of my job I generate userObjects and Clusters which I hand out to others for use.

Unfortunatly these userObjects / Clusters contain vb/c# scripts with additional dll's loaded. Every time I hand them over the path has to be replaced by hand directly with the vb-script compoenent. This is sometimes not realy possible since a) I am not there and b) the userobjects are passed to a large number of people and c) clusters / user objects are password protected so people can't change it themselfs.

What is the best practice regarding this?

Is there any way to load dll's with a relative path or any way so that the dll's are found by the operating system or any other way which makes this step unneccesary. 

BEst

Richard

Views: 786

Replies to This Discussion

it is my understanding that, if it can't find a DLL reference from its absolute path, Grasshopper looks upwards and downwards from the location where your GH file is saved for loading dlls. The dialog that resolves conflicts is triggered at the time the script component calls its "Read" method, deserializing from the file itself - so no amount of clever run-time scripting can get in there and fix its references prior to the dialog popping up. 

Do you have any option of keeping the dlls in question on a consistently mapped server location (or push them all to a consistent location on all users' machines)? that seems like the only possibility to me. 

Hallo Andrew,

do not realy have the possiblity to keep them on a mapped server. Do you know if I can replace the reference path through a script? The idea is:

Having a autoupdate Script:

1. Search for the dll in question in a few locations.

2. Search through the clusters and change path to the dll in questions for all script elements.

Any idea ow to start it?

Hallo All,

I found a post of david manchening that assemblies could be loaded with assembly resolve event handler, however not so sure how this will work within VB.net script component.

I can managa to load an assembly with:

Dim MyAssembly As [Assembly]

'Load the assembly from the specified path.
MyAssembly = [Assembly].LoadFrom("C:\MathNet.Numerics.dll")

The idea is o look for the assembly in the userObjectFolder, which is know by grasshopper but for some reasen it is not searched for assemblies when switching between users on another computer.

and it also show up when looking at the loaded assemblies of the app domain:

Dim currentDomain As AppDomain = AppDomain.CurrentDomain

Dim assems As [Assembly]() = currentDomain.GetAssemblies()

'List the assemblies in the current application domain.
print("List of assemblies loaded in current appdomain:")
Dim assem As [Assembly]
For Each assem In assems
   print(assem.ToString())
   If Not assem.isDynamic Then
     print(assem.Location)
  End If
Next

but still the VB.net script component can access the classes of the assembly.

Any Help apreciated.

RSS

About

Translate

Search

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service