ENABLE_WINMD_SUPPORT and precompiled DLLs

Hello,

We use a third-party Unity library from the asset store. In the past we have compiled this plugin into a .dll for inclusion in our project - this part of our setup is important for various reasons, on other platforms.

For the UWP platform, the plugin now uses #ifdef ENABLE_WINMD_SUPPORT checks to compile in references to .NET classes when building.

However, our understanding is that ENABLE_WINMD_SUPPORT only works when used in a script under the Unity "Assets" folder, to compile the script differently when making a build (versus running in the editor).

For precompiled DLLs, what is the recommended equivalent? In another library we did this:
* Included the .WINMD and .DLL dependencies in our .csproj/project for compiling our own .DLL ("Library.DLL")
* Copied Library.DLL and the .WINMD dependencies under the Plugins folder

...But we're not sure if this is correct. Among other things, Library.DLL is always unloaded in the editor with an "unloaded broken assembly" error (similar problem to this forum post). We assume that is due to the references to the other .DLLs and their symbols being unresolved in editor - but that when we make a native build, these symbols are found and used, since everything works correctly at that point.

This is not entirely clear, however; and while we've seen no side-effects to compiling things this way, the "broken assembly" error in editor is concerning.

Is this an appropriate approach to changing the reference to .winmd-based symbol dependencies when building our code into an external DLL? Or should we be using something like "placeholder plugins"?

 

We've been slammed shipping our game since this post... but I now have time to report a bug for this, since it IS causing issues at runtime (or maybe is just related to other issues we're having at runtime).

Please review my bug report #1104311. Whenever we build libraries (the one in question was InControl, but again we're building it in a non-standard way into a DLL library) that include a reference to symbols within Windows.Foundation.UniversalApiContract (specifically Windows.Gaming.Input), these problems occur. I included a different library that does basically the same thing...

Both DLLs cause strange errors. The particular problem which we repeatedly saw in the player (NOT just in the editor!) was that when the scene was deserialized, and there was a script on an object, and that script had references to an innocuous class in that DLL, then we would get errors like "__level0 is corrupted! Remove it and launch Unity again!"... and then our game completely gated or crashed. Note that in our usage, that problem WENT AWAY when the same object/prefab was deserialized from an AssetBundle - everything works fine in that case, which is very mysterious.

Our team has lost weeks of person-time just to issues around this, for our XboxOne/UWP game. I spent all of today trying to narrow this down, and investigate code-stripping and other potential culprits, but came up empty-handed. I'd really appreciate Unity checking this repro - if it's not a Unity bug, then we would love to know what we're doing wrong, and especially why it would cause deserialization to fail in some cases but not in others.

 

Thanks for catching that. However, as I noted in the bug report, the same error will cause runtime player errors when we make a build. This isn't just a problem in the editor - though I can get nearly the same thing to happen in both places.

This is a confusing issue, another engineer and I spent many hours trying to narrow down what was happening. So please let me know if you have more questions.