[Bug] Cannot execute on mac .NET 6

[SamboyCoding]

I'm the developer of a project called Cpp2IL which uses Capstone.NET to do a lot of heavy lifting regarding disassembly of ARMv7 and ARM64/ARMv8 binaries.

Your NativeDisassemblerHandle and NativeInstructionHandle class both inherit from SafeHandleZeroOrMinusOneIsInvalid, which is in the Microsoft.Win32 namespace, and thus probably should only be used on Windows. However, the library runs just fine on .NET 5 or 6 on Ubuntu too.

The problem, unfortunately, comes when running on Mac OS, where you get an exception like the following:

System.TypeLoadException: Could not load type 'Microsoft.Win32.SafeHandles.SafeHandleZeroOrMinusOneIsInvalid' from assembly 'netstandard, Version=2.1.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'.
   at Gee.External.Capstone.CapstoneDisassembler`8..ctor(DisassembleArchitecture disassembleArchitecture, TDisassembleMode disassembleMode)
   at Gee.External.Capstone.Arm64.CapstoneArm64Disassembler..ctor(Arm64DisassembleMode disassembleMode)
   at Gee.External.Capstone.CapstoneDisassembler.CreateArm64Disassembler(Arm64DisassembleMode disassembleMode)
   ...snip...

On top of that I have had to add assembly resolve listeners to account for not just #27 (which is fine, I can just get users to install capstone from whatever package manager) but also the fact that, no matter how I compile my application, only the managed capstone.net assembly for Windows is added to the resulting application, rather than for the target operating system, and thus I have to manually load capstone from runtimes/win-x64/lib/netstandard2.0/Gee.External.Capstone.dll.

Otherwise, thank you for the library!

[9ee1]

Thanks for your report. That is interesting behavior. I am not sure why the behavior would be different on MacOS with respect to the type loading exception.

As for packaging the native lib with the NuGet package, I am thinking its finally time for me to get around to #27. I don't have access to a Mac so I most likely will not be packaging a native lib for Mac.

As for having to manually load the native lib when you reference the package in a project (i.e. your application), my testing at the time had indicated it should copy the native lib to the output bin directory. I'll need to double check this again but I think it should be an easy fix.

but also the fact that, no matter how I compile my application, only the managed capstone.net assembly for Windows is added to the resulting application, rather than for the target operating system

I just reread this line and I realized I misunderstood earlier. This is expected behavior at this point in time since the NuGet package only contains target assemblies for Windows. I believe this should also be addressed by #27.

[9ee1]

There is something that is interesting to me. Someone had reported an issue on MacOS in #30, but it was because the native Capstone lib wasn't installed so it couldn't be loaded. But once the lib was installed, everything works correctly. I am curious why it works for them and not you.

[SamboyCoding]

After more testing, it works on .NET 5, but not on .NET 6. Possibly a bug in the runtime?

[9ee1]

I couldn't find anything on MSDN to suggest this behavior has changed in .NET 6. I might need to search the .NET Runtime repository to see if this is a known bug/limitation in .NET 6.