Can I make a Rhino plugin for Mac using .net standard 2.0?

I’ve got some cross-platform code that I’ve already written which I’d like to reuse in a Rhino plugin I’m developing on the mac. The existing code targets .net standard 2.0. I’m able to make my plugin project target .net standard 2.0, reference my existing dll, and build everything successfully. But Rhino doesn’t seem to recognize the plugin. When double-clicking on the .macrhi, I get a message in Rhino that I’ve successfully installed the plugin. Then nothing happens when I type the plugin name on the command line in Rhino. I previously had this working with my plugin project targeting .net framework 4.5, so I assume that this is an incompatibility with .net standard 2.0.

Hi Ian,
I’m not exactly sure. I haven’t spent a whole lot of time researching .NET Standard 2.0 beyond just getting an understanding what it is and how it fits into the .NET ecosystem. Rhino 5 for Mac is embedding an older version of mono which may also be the source of the problem. Have you tried this on Windows?

@curtisw, have you played around i this area yet?

Thanks,
-Steve

The older version of mono is probably the issue. I assumed that when McNeel updated the project templates to work with Visual Studio, which supports .net core and .net standard, that perhaps we’d get a version of Rhino mac that uses Mono 5.4, which I believe supports .net standard (https://docs.microsoft.com/en-us/dotnet/standard/net-standard).

Does Rhino for mac write plugin load/exec. failures to a log? I can help diagnose a bit here.

We ran into a problem when Microsoft started integrating their source code into mono where encryping/decrypting the rhino license file didn’t work due to some change. At that point we decided to not update mono on for a product that is already working pretty well. We have updated to the latest mono for our internal build of V6 Mac Rhino (which we haven’t started WIP testing of quite yet.)

/Applications/Rhinoceros.app/Contents/MacOS/Rhinoceros -RhinoLog

should generate a Rhinoceros.log that you can look at in the ~/Library/Logs section of console. Maybe that will help point to the problem.

Definitely looks like Mono can’t load the types in my assembly. Feels like I have to reconstruct a .net 4.5 project using the same assets and go that route.

9/11/17, 9:52:23 PM: [MonoHost::LoadPlugIn] Start
9/11/17, 9:52:23 PM: path = /Users/ikeough/Library/Application Support/McNeel/Rhinoceros/MacPlugIns/RhinoCoGS.rhp/RhinoCoGS.dll
9/11/17, 9:52:23 PM: ReflectionOnlyLoadFrom succeeded
9/11/17, 9:52:23 PM: Assembly loaded for real... GetExportedTypes
9/11/17, 9:52:23 PM: looking for /Applications/Rhinoceros.app/Contents/Resources/ManagedPlugIns/RhinoDLR_Python.rhp/netstandard.dll
9/11/17, 9:52:23 PM: could not find file
9/11/17, 9:52:23 PM: looking for /Applications/Rhinoceros.app/Contents/Resources/ManagedPlugIns/RhinoDLR_Python.rhp/netstandard.dll
9/11/17, 9:52:23 PM: could not find file
9/11/17, 9:52:23 PM: Caught reflection exception
9/11/17, 9:52:23 PM: Got 3 loaded types
9/11/17, 9:52:23 PM: 0 - RhinoCoGS.RhinoCoGSCommandCode
9/11/17, 9:52:23 PM: 2 - RhinoCoGS.RhinoCoGSPlugin
9/11/17, 9:52:23 PM: System.MonoType[]
9/11/17, 9:52:23 PM: Got some loader exceptions
9/11/17, 9:52:23 PM: System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded.
  at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (System.Reflection.Assembly,bool)
  at System.Reflection.Assembly.GetExportedTypes () [0x00000] in <filename unknown>:0 
  at Rhino.Runtime.MonoHost.LoadPlugIn (System.String path) [0x00000] in <filename unknown>:0 
9/11/17, 9:52:23 PM: RhMono_LoadPlugIn result=error_unable_to_load

Sure looks like that is the problem

Yes, I’ve played around with .NET Standard a bit so far. .NET Standard 2.0 requires .NET 4.6.1 on Windows and Mono 5.4 on Mac (which is still in beta).

.NET Standard 1.x would possibly work better, though only up to .NET Standard 1.1 as that supports .NET 4.5 (which I think is the minimum requirement for Rhino).

@Ian_Keough, given this situation, I think your idea of creating a separate project is the way you’ll need to go. With new tooling (at least on windows), you can create a multi-targetting .csproj that targets both .NET Standard 2.0 and .NET 4.5. Take a look at this post for details on that.

Hope this helps!
Curtis.

Thanks all. I got a multi-targeting solution working to use both versions of .net standard last night, but unfortunately there were changes in some of our APIs which mean I actually have to make a separate branch with different code :frowning: I will make a .NET standard 1.1 branch and let you know if that works.