NetCore R8 vs R9 Plugin load failing

Rhino Developer
,
1

Morning all, bit of help please,

We are preparing our plugin for Rhino 9, wondering how I can get more specific info about why my plugin that DOES run in Rhino8 with NetCore 8, fails when loading to Rhino9 with NetCore 8.

I get a generic fail screen, with a link to reasons, none of which are valid to explain the failure. Is there a way to run a plugin that gives feedback about its load process and specifically where/why its failing?

image
image1107×899 186 KB

image
image639×368 49.6 KB

2

Hi @chris.botha,

Try running Compat.exe, a command line utility, which is in Rhino’s System folder.

– Dale

3

I looked up the usage from here Rhino - Moving to .NET Core
but I get errors, the command itself not actually working, is there an update howto or article I can use?

(again for clarity it already works in netcore in R8, just not in R9, so I assume I need to use the R9 compat.exe)

image
image1098×413 18.8 KB

4

@dale ignore above, does not work in powershell at all, does work in CMD. My bad didnt read properly.

Getting following exception, so I guess i start poking at system security.. any ideas why this does work in R8 Net8 but not in R9 net8?

C:\Users\cbotha\source\Workspaces\Pallion.RhinoPlugins.FULL - PreNetCore\Pallion.RhinoPlugins.V7\Pallion.RhinoDock\bin>“C:\Program Files\Rhino 9 WIP\System\netcore\compat.exe” -q --check-system-assemblies Pallion.RhinoDock.rhp
Pallion.RhinoDock, Version=2.0.1.0, Culture=neutral, PublicKeyToken=null

Exception occurred, cannot check the rest of the module
System.InvalidOperationException: Circularity when resolving exported type: ‘System.Security.Principal.WindowsIdentity’
at Mono.Cecil.ExportedType.Resolve()
at Mono.Cecil.MetadataResolver.GetType(ModuleDefinition module, TypeReference reference)
at Mono.Cecil.MetadataResolver.Resolve(TypeReference type)
at Mono.Cecil.ModuleDefinition.Resolve(TypeReference type)
at Mono.Cecil.ExportedType.Resolve()
at Mono.Cecil.MetadataResolver.GetType(ModuleDefinition module, TypeReference reference)
at Mono.Cecil.MetadataResolver.Resolve(TypeReference type)
at Mono.Cecil.ModuleDefinition.Resolve(TypeReference type)
at Mono.Cecil.ExportedType.Resolve()
at Mono.Cecil.MetadataResolver.GetType(ModuleDefinition module, TypeReference reference)
at Mono.Cecil.MetadataResolver.Resolve(TypeReference type)
at Mono.Cecil.ModuleDefinition.Resolve(TypeReference type)
at Mono.Cecil.ExportedType.Resolve()
at Mono.Cecil.MetadataResolver.GetType(ModuleDefinition module, TypeReference reference)
at Mono.Cecil.MetadataResolver.Resolve(TypeReference type)
at Mono.Cecil.MetadataResolver.Resolve(MethodReference method)
at Mono.Cecil.ModuleDefinition.Resolve(MethodReference method)
at Mono.Cecil.MethodReference.Resolve()
at Compat.Program.TryResolve(Object operand, TypeDefinition calling_type)
at Compat.Program.Main(String
 args)
5

ok, ignore and/or delete thread, I got it running using Claude.

image
image1419×874 225 KB

6

Can you share what the problem was and how it was resolved? This may be useful for others experiencing similar problems.

7

The primary issue was that the Project in VS was still set to copying DLL’s into the plugin folder, (I have to use VERY specific Microsoft Dynamics DLL versions to negotiate with our ERP, The dynamics DLL’s only want to play with specific security dll’s too etc etc..its a bit touchy, so when bug shooting this before I made VS copy ALL DLLs to the install folder and then loaded while incrementaly deleting/swapping them to find my culprit, forgot to turn that off.

I am unsure why this was not an issue in the Rhino8 plugin install though as they are still in that install now, anyhow, removing them at least got the plugin to stop saying it wanted to run in .netframework. and attempted loading long enough to pop error messages on the command line in Rhino 9 about the failed loading issue… Rhino reported the Plugin had no GUID.

(Rhino9 command line error:)
Error occurred loading plug-in Details: plugInId Can’t be Guid.Empty (Parameter ‘plugInId’)

here im not sure why this failed, but, Claude added the same GUID back into the plugin class, and added this wierd little idField bit routine with some USINGS, and it stopped failing to load.

using Rhino.PlugIns;
using Rhino.UI;
using System.Runtime.InteropServices;
using System.Reflection;

namespace Pallion.RhinoDock
{
[Guid(“6cef8511-a474-4679-af71-f4e919de7a76”)]
public class PallionRhinoDockPlugIn : Rhino.PlugIns.PlugIn

{
    public PallionRhinoDockPlugIn(){Instance = this;}
    public static PallionRhinoDockPlugIn Instance{get; private set;}
    protected override LoadReturnCode OnLoad(ref string errorMessage)
    {
        if (Id == Guid.Empty)
        {
            var idField = typeof(PlugIn).GetField("m_id", BindingFlags.Instance | BindingFlags.NonPublic)
                          ?? typeof(PlugIn).GetField("_id", BindingFlags.Instance | BindingFlags.NonPublic)
                          ?? typeof(PlugIn).GetField("Id", BindingFlags.Instance | BindingFlags.NonPublic);

            if (idField != null && idField.FieldType == typeof(Guid))
            {
                idField.SetValue(this, GetType().GUID);
            }
        }
        System.Type panelType = typeof(CAM_Uploader);
        Panels.RegisterPanel(this, panelType, "PalloysCAM", Pallion.RhinoDock.Resources.Icon);
        return LoadReturnCode.Success;
    }
}

}

That code is NOT in the Rhino 8 / Core 8 version and it loads and runs fine in Rhino 8, that is the only code diffrence between the two installs.
here is the version of that code that loads and runs fine in Rhino 8

using Rhino.PlugIns;
using Rhino.UI;
namespace Pallion.RhinoDock{
public class PallionRhinoDockPlugIn : Rhino.PlugIns.PlugIn{
public PallionRhinoDockPlugIn(){Instance = this;}
public static PallionRhinoDockPlugIn Instance{get; private set;}
protected override LoadReturnCode OnLoad(ref string errorMessage){
System.Type panelType = typeof(CAM_Uploader);
Panels.RegisterPanel(this, panelType, “PalloysCAM”, Pallion.RhinoDock.Resources.Icon);
return LoadReturnCode.Success;
}}}

8

Thanks for sharing the details about the problem and the solution. You should not need the complicated bit in the OnLoad about the Id. That’s messing with private variables through the reflection API of .NET and that should not be necessary.

9

No doubt, but path of least resistance, that at least got it running, so for now I can start poking a stick at it, a full rewrite will follow to eto from the winforms components now. I dont think that will be done soon enough to meet your release date so for now “if it aint broke, don’t fix it”

semi related question, is it possible to have two running rhino windows each running their own .net dependency? I have had to start writing a whole supporting software because the orginal author abandoned his work in rhino 6.. would be nice to be able to have a rhino window running netframework and copy paste to the netcore window? Would save me a lot of ballache too..