When using a normal DLL file, Unity will recognize this and the methods will be available before compilation. But when placing a winmd file inside the appropriate folder Asset > Plugin > Metro(/WSA) it won’t work as with a DLL.
Unity won’t recognize that it has been “imported” and thus you can’t write “using MyDerpLibrary”.
When trying to create a build it still won’t understand that there’s a winmd file that contains the necessary definitions.
there is a simple workaround to this problem: create an empty DLL targeting .NET 3.5 with the same public classes/methods but without any implementations, and put that to Assets/Plugins. When compiling scripts, Unity will use DLL as reference target, but when you build your project, Unity will copy the winmd file to final project location and your scripts will actually land in winmd when they call its methods.
Okay thank you! This should really be mentioned somewhere, found one other post vaguely mentioning this, so wasn’t sure it actually was still the correct way of doing things.
I kinda got it to work. But once the project is it Visual Studio and I try to build it I get build error saying that my methods exist both in …/Unprocessed/MyLib.dll and in …/Unprocessed/MyLib.winmd. I solved it by manually removing the MyLib.dll in the Unprocessed folder, but is there a “cleaner” way of doing this?
In Unity 5, you can explicitly check which plugin is Editor only and which one is for WSA. In 4.5.5, because the filenames of these plugins don’t match, you’ll have to probably move/delete file before building to WSA and then restore it, you could do that from the script though…
Hmm, that’s unexpected. I don’t think Unity 4.6 is able to automatically handle it - it assumes there’s another .dll with the same name next to the .winmd. Since your .winmd is made from C# code, it will not be there. What happens instead is that it picks up the fake DLL that was meant for Unity editor, and copies it next to the .winmd file.
I suppose you don’t have source code for it? Of course, the easiest solution would be to rebuild it as .dll rather than a .winmd.
Another solution you could do, is create a new empty Visual Studio C++ DLL project, build it, and copy the resulting DLL next to winmd in Assets/Plugins/Metro. Then, Unity will copy the native plugin to the final build directory, and there would be no conflicts as native DLLs don’t have classes. The dll you compiled wouldn’t be used in any way - it would be there to just trick Unity.
Let me know how it goes if you try making it work.
I will try one of these solutions. I actually do have the source code, so I will try to build is as an DLL instead. If possible to make a DLL why would one make an winmd file to begin with?
EDIT:
I’ve now tried your solutions without success.
Tried building the source into a (Portable) DLL (a normal DLL won’t work because of Universal App nature). Failed with some error (when trying to build in Visual Studio) which didn’t really indicate anything to what might be wrong.
Tried to build an empty C++ DLL. Not sure which kind you were referring to here since there’s a bunch of different DLLs, but I kinda tried them all. I’m also not sure what you meant by this solution. Was I supposed to keep the C# DLL with the method declarations so that Unity still understands that the methods still exists? The closest I came to a build with this solution was that VS complained about “x86” and “MTIL”, but it seemed way off.
What’s the error? I’d try building it as “Windows Store” C# Class Library, instead of portable.
Any of them should work. My idea was this:
Assets/Plugins/MyPlugin.dll // The fake C# DLL that you made for editor
Assets/Plugins/Metro/MyPlugin.dll // Empty C++ DLL
Assets/Plugins/Metro/MyPlugin.winmd // Real winmd file
Sorry for not getting back to you @Tautvydas-Zilys ! I don’t seem to get notifications from this thread any more?
There is no “Windows Store” C# Class Library. The only options are: Class Library (Portable for Universal Apps) and Windows Runtime Component (Portable for Universal Apps). I took the former, since the other one is winmd-files.
You are correct, there actually was an “Class Library (Windows)”. I clicked the “Store Apps” menu thinking it would list them all, but it didn’t. Thank you and sorry for my blindness.
(Haven’t had time to try any of these solutions correctly yet, will get back when I’ve managed to do it)
It will give the following error when trying to build from Unity:
Error building Player: Exception: Assembly compatibility check error:
Failed to get assembly information for one of two plugins: D:\GitHub\my-game\Unity\Temp\StagingArea\Data\Managed\Plugins\Metro\PushSDK.dll
Is there anything I’m missing? I tried building:
C++ > Store Apps > Windows Apps > DLL (Windows)
C++ > Store Apps > Universal Apps > DLL (Universal Apps)
That’s not the right setup, you can not mix native/managed plugins.
I’d recomment you do the following setup:
Assets/Plugins/MyManagedPlugin.dll // The fake C# dll for editor
Assets/Plugins/Metro/MyManagedPlugin.dll // Real C# plugin for WSA, that calls MyPlugin.winmd internally
Assets/Plugins/Metro/MyPlugin.winmd // The real winmd, completely hidden from scripts by MyManagedPlugin
@Tautvydas-Zilys told be to do the setup I mentioned. That I should place an empty C++ DLL in the folder so that it doesn’t conflict once it’s inside the Visual Studio Project. But now you are telling I should create a real C# DLL file which actually does stuff?
This seems like a very big hassle. Sure that Tautvydas solution won’t work some how, @Aurimas-Cernius ?
You can try Tautvydas solution too, but having managed dll for editor is wrong, when platform dll is native.
You can try to remove editor plugin completely and instead wrap calls to plugin in scripts with define. It can be !UNITY_EDITOR or NETFX_CORE.
