My Rhino plugin seems to be loading an older version of a .Net DLL that was part of another plugin installation.
I only get this error on a PC where this older plugin is installed.
I get a System.MissingMethodException at runtime. (during compilation the method is there)
I have the current version in the same folder as the rhp file.
I used reflection to see the assembly path. It shows the path in the same folder as the rhp. Still i get a method not found exception.
When starting the WPF app standalone instead of hosted in Rhino 5 it works fine.
Hi Goswin,
Can you post some code that demonstrates how you are loading the assembly?
Can I assume you are not doing something like this?
Assembly SampleAssembly;
SampleAssembly = Assembly.LoadFrom("c:\\Sample.Assembly.dll");
– Dale
Hi Dale,
I just reference FSharp.Compiler.Service via Nuget. The dll gets copied into the output directory on building. (same folder as the rhp)
I am not sure how to use assem = Assembly.LoadFile(path). I tried this line but the wrong assembly seems to be loaded already. Do I have to use the methods on assem via reflection ?
Rhino only allows a single assembly of a given name to be loaded in the process. When the .NET framework tells Rhino that is needs to find an assembly, Rhino walks through the list of directories where every plug-in is installed and attempts to find the DLL in that location. I’m guessing Rhino is looking in the older plug-in directory and loading the fsharp DLL from there.
I don’t currently have a good fix for this.
Thanks Steve,
Can I get access to the list of directories that Rhino is walking ? For better debugging.
When I check the assembly location via reflection on one of its classes it oddly shows the correct one in the same folder as the rhp. But still the expected method is not found.
Rhino.Runtime.HostUtils.GetAssemblySearchPaths should give you the list
Thanks Steve,
I removed some old plugins. Now I do not see another dll of the same name in GetAssemblySearchPaths. I also used FusionLogging and did not see any other unwanted FSharp Compiler Assemblies. Still I get a method not found Exception . So the reason for this must be something else. On my Win 10 laptop everything is OK. Does RH5 on Win 7 restrict .Net plugins in any way? Is Net 4.5 supported ?
Caveat: I work in Rhino WIP.
I have a Grasshopper plug-in written in F#. That works just fine. I’ll have to try a v6 plug-in with the F# compiler services too. Is there anything specific you are doing? Or is it already enough to just instantiate a service?
Nathan, Is there a way in VS to build my plugin vor rh5 and rh6 simultaneously ?
Your V5 plug-in should load into V6 as long as all of the RhinoCommon functions you call still exist in V6
Maybe test with this python script to see where the fsharp assembly is coming from…
import System
assemblies = System.AppDomain.CurrentDomain.GetAssemblies()
for assembly in assemblies:
try:
if assembly.FullName.ToUpper().Contains("FSHARP"):
print assembly.Location
except:
pass
With some manually fiddling around in your csproj file you should be able to get configurations that support both. As Steve says the v5 RhinoCommon plug-in should load into v6 without problems, though.
This is the error I get when I load it in RH6:
@nathanletwory I am building an FSharp scripting editor for Rhino. So I need the FSharp.Compiler.Service.dll
@stevebaer running your script does only show the desired FSharp dlls. not old ones. I tested it on another win7 PC in the office wit Rhino5. it worked fine there. So my suspicion is that the MissingMethodException is caused by something else.
I tried in V6 a simple (empty) plug-in that instantiates an FSharpChecker.
FSharpOption<int> ps = new FSharpOption<int>(10);
FSharpOption<bool> b = new FSharpOption<bool>(false);
FSharpChecker checker = FSharpChecker.Create(ps, b, b, null);
That works just fine.
Is it possible for you to boil down to a test plug-in that does the minimal steps to reproduce the error?
/Nathan
Hey Steve,
I have the same issue with 3 plugins created by my office that share the same library (.dll). I would like to make sure the most recent version of the library is loaded, but the problem of this thread still persists. Has there been any development regarding this loading process? Is there any solution besides making three copies of the same library with a slightly different name?
I will keep searching for different threads regarding this problem.
Any helps is appreciated!
Please explain a little more about what the issue is that you are seeing. This thread is four years old and involves libraries installed by nuget, so I’m not entirely sure what you are experiencing is the same issue.
Aah you might be right Steve, I’ll try to explain it thoroughly.
At my office, we created 3 plug-ins that are ‘installed’ at the following location C:\Users\rolf_\AppData\Roaming\McNeel\Rhinoceros\7.0\Plug-ins
All three plug-ins use the same Library.dll assembly that we developed which contains common methods and classes. All 3 plug-ins are updated frequently but NOT always at the same time. Sometimes including new additions in our library.dll. Note: We try to maintain old methods and classes in the library for compatibility purposes. Note: the user sometimes uses an old version of the first plugin, a slightly newer one of the second, and the newest version of the third plugin because of backward compatibility reasons, bugs, etc.
As you mentioned in this thread, Rhino only allows a single assembly of a given name to be loaded in the process. We noticed that depending on which plugin is installed first determines which version of the library.dll is loaded. Most likely this is what you meant with ‘Rhino walks through the list of directories where every plug-in is installed’ Preferably we would like the most recent version of the library.dll to always be loaded, which is not always the first one to be installed. Perhaps we could force the plugin in (with the newest library) to be loaded first if we know how plugin loading order is exactly determined. Any help is welcome!
What if you eliminated the Library.dll completely and had all three plug-ins reference the same shared source files?
Thanks Steve, could you clarify this direction? We are not aware of a method that allows you to reference shared source files without the need for dlls or combining the plugins in a single project. Would there be any other way to force the latest version of the DLL to be loaded?
Note: that our plugins contain both components for Grasshopper and Rhino.
We decided, for now, to always install all three installers built at the same time from the same branch to prevent any .dll issues. This is definitely not ideal, so would love to hear about this option you suggested @stevebaer