From everything I’ve read, C# dll’s are considered managed plugins, so why is the C# plugin I’m using considered a native plugin? It would make things so much easier if it was considered a managed plugin, but I’m still trying to work with it regardless, using DLLImport. However, I run into problems using this method as well, since some of the functions I need to use are embedded in classes that need to be declared, and variable types used are also declared within the DLLs.
DLLImport isn’t meant for managed plugins. Just drop your DLL into your project and your code should “see” it just fine.
1 Like
I’ve already dropped two DLLs into a plugins folder in my assests section, both are written in C#. The first is considered a managed plugin, and is working fine. The second is being read as a native plugin, and this is where I’m running into issues.
Maybe the second was compiled as .NET Native or something weird? They should be compiled as .NET Assemblies, targeting .NET 2.0.
Is there a way for me to check how it was compiled? Also, if it was compiled as a .NET Native, is there a way where I could compiled as .NET Assemblies targeting .NET 2.0?
I’m not sure if there’s a simple built-in way to do it, but you can download dotPeek: https://www.jetbrains.com/decompiler/
Run it, click and drag the dll’s into it, and you can get a bunch of information on them. Here’s a dll, the header should say which Framework it’s for (anything up to and include v3.5 should be fine for Unity) and the mscorlib reference it’s using (which should be 2.0.0.0).
If it’s compiled for something else, I don’t think there’s a way to recompile it unless you have access to the source code. You can try using dotPeek to decompile everything, then load it all in Visual Studio and recompile it targeting a different framework but that could get complicated.
The DLL met both of those requirements. Is this a managed DLL?
Yeah, that looks fine, I’m not sure why it’s not working. Sorry. Looks like it’s a C++/CLI dll, maybe that DLL is calling a native dll itself?
Interestingly enough, the one DLL that is read as managed (NationalInstruments.Common) has a reference named “NationalInstruments.Common.Native”. The DLL that is read as native references the NationalInstruments.Common DLL. Could this be part of the issue?
Wait, are you saying it’s not a C#-written DLL? Because in that case, it would make sense as to why it doesn’t show up as a managed plugin.
Well it has a reference to Microsoft.VisualC there at the top, which is the C++ library. The C# one is called Microsoft.CSharp. But even if it’s written in C++, it is still a .NET DLL, not a native DLL. (You can write in several different languages including C++ and they all can be made into .NET DLL’s.) So Unity should recognize it. So unfortunately I’m not sure why it’s not working correctly. You could try submitting a bug report to Unity; maybe they will have better answers.
And yes, that could be the issue. Maybe you could contact the NationalInstruments people who made the DLL and see if they have any info on getting it to work with Unity?