Hello guys,
I’m kind of in a pickle. My managed plugin is being read as a native, which means I can’t using it in my scripts. Because it’s a managed code, I can’t even used DLLImport. What do I do?
https://www.dropbox.com/sh/txo1ngqgiwev2j1/AADNj0rS6laymHfVX7x7A9yPa?dl=0
here is a link to the plugins I’m using. The one I’m having issues with is the ‘NationalInstruments.DAQmx.dll’.
Do either of those two assemblies use COM / import native assemblies themselves?
I’m not sure. How would I find out, and what would that mean if the did?
Well they may not be native but they may be using native stuff. Did you create these assemblies?
No, I did not. I have talked to the developers however, and they’ve told me that both are written in C# and have been compiled as managed plugins.
I see, those are National Instruments assemblies. No idea what they do internally, but my guess is that the DAQmx and Common dlls are trying to use .NET 4.5.1+ so they can’t be imported. You need a .NET 2.0 / .NET 3.5 version of the dlls.
Yeah, I’m actually using Dlls from an older driver, so they are already in .NET 3.5
You might have to try an even older version that targets .NET 2.0. The common dll imports fine but the DAQmx.dll does not. It’s throwing a CS0009 error, which is missing or corrupt metadata or something that prevents the DLL From properly importing. My guess is that it’s attempting to use .NET 3.5 features that are not available in Unity’s version of Mono.
I downloaded an older version of the dlls and it still loaded as native. I’m going to call the developers again, but what should I say regarding CS0009 error? Is there a list of .NET features Unity won’t accept? Also, I’m using visual studios.
Oh I thought you were loading it in the Unity editor. That’s where I saw the CS0009 error. Just tell the developers you’re getting that error.
No no no I am loading into unity, I was just confused by your use of mono. I thought you meant mono developer, my mistake
Would I be possible to create a new managed dll using this dll as a reference, and then importing that dll into Unity? Or would it be read as native as well?
No idea. I’m not sure what you mean by “read as native”. I just get that import error.
When I say “read as”, I mean that the type label in the plugin’s inspector says “native”.
I wrote a new plugin that loaded Nationalnstruments.DAQmx as a resource, and when I imported it to Unity, it was seen as a managed type. However, when I try to execute some of the functions that rely on DAQmx, it gives me the following error:
FileNotFoundException: Could not load file or assembly ‘NationalInstruments.DAQmx, Version=9.9.35.39, Culture=neutral, PublicKeyToken=18cbae0f9955702a’ or one of its dependencies.
Do I need to place the DAQmx plugin into a specific folder on my computer, or is there just something wrong with the plugin?
I have no idea. I have a feeling, even though they say it’s fully managed, that the DAQmx DLL is calling out to some native code or has unsafe code or something in it. I’m not 100% sure what all triggers the “Native” flag.
It is in fact referencing Mircosoft.VisualC; does this make it a native plugin? Should I be using DLLImport to call functions? What do I do if these functions are within classes?
Yep, looks like it is. Yes you’ll have to use DLLImport. As to your last question, I’m not sure. I don’t have much experience there. Maybe @lordofduct or @MV10 might have an idea?
DLLImport supports a C api, so technically classes aren’t really supported (as far as I know).
Object pointers can be passed between unmanaged and managed code with an IntPtr, but that’s about it.
If your C++ code has some method that you’re attempting to access, it implies there’s a need for an instance of that class to operate against (otherwise, why is it a member of that class?). So you’ll need to have a C api that uncovers a ‘create’ method to get an instance which hands back an IntPtr, then a c method to call that class member method, which takes in the IntPtr and any parameters.
If you really want to get hightech with this… you could have a class on the managed side (C#) that is a wrapper around the IntPtr, which you then call back and forth to your C code.
Unity themselves have an even weirder way of doing it themselves, and its implemented via their custom version of the mono runtime. But I don’t know exactly how they pull it off (when you look at the UnityEngine.dll you can see attributes and tags to it everywhere)… nor do I think it’s actually usable by us.