I solved the problem and deleted most of the post. Here’s a summary. (BTW, a delete post button would be nice…)
Long story short:
When creating a .NETCore DLL to be used in Plugins/Metro, be sure to include C:\Program Files (x86)\Unity\Editor\Data\PlaybackEngines\metrosupport\Managed\WinRTLegacy.dll in your DLL’s project if it contains any MonoBehaviors or [System.Serializable] attributes.
I’m confused by this… which is probably more ignorance on my part as I have not “yet” created a plugin in Visual Studio for use in a game with Unity (the whole, use two versions library thing).
I just thought all you needed to do was include UnityEngine reference to the project in Visual Studio and set the project to 2, 3, or 3.5. But I guess if you need 4.x features, well… not even sure how to go about that… I suppose it would require a wrapper of some kind.
Windows 8 Store apps must be built to .NETCore 4.5 for Windows 8.0 and .NETCore 4.5.1 for Windows 8.1. .NETCore does not include many of the features of the full .Net framework, so if you build your DLL with .NET, you’ll run into issues. The game may build, but you will probably not pass certification.
To build with .NETCore 4.5, you’re forced to use Visual Studio 2012 and create your project for Windows Store apps. For 4.5.1, you must use Visual Studio 2013 and also create your project for Windows Store apps. There’s no option to easily change the Framework setting to .NETCore, which is quite annoying and confusing at first. If you publish your VS 2012 8.0 project in 2013, it will become .NETCore 4.5.1 and you’ll lose 8.0 compatibility.
Even building your DLL at 3.5 and publishing to Windows Store breaks quite often because there are features used in the older versions of some .Net classes that are not supported by .NETCore. For example, if you use an IEnumerable in your DLL, build at .Net framework 3.5, then publish to the Store, you’ll get a bunch of build errors telling you that IEnumerable is using System.Threading which isn’t supported.
Unity tried to solve a bunch of this by including classes in the WinRTLegacy.dll which basically substitute for missing classes in .NETCore so your code can “just work”. They seem to be adding things slowly to this dll, so the version of Unity you publish with is fairly important (this makes a diff for app store publishers). They also do some rewriting of the code when building to remove some references to unsupported classes, but this doesn’t work with a DLL.
Windows 8 support is rather confusing at present. There are a ton of gotchas and the documentation isn’t very complete, so be prepared for a LOT of trial and error.
One correction here: we do this at IL level, not source level - we rewrite references for all the assemblies that are gonna end up in your final VS solution. Therefore, if you build a DLL targeting desktop, but actually not use any of the types and methods that doesn’t available in .NETCore, we will “fix” the DLL to work. If we cannot do this, we will spit an error.
If you found any cases where it is not being the case - it’s most likely a bug on our part.
Note: the types and methods must match exactly with full namespace name.
Some customers reported issues with my plugins from the asset store. I can’t reproduce them because I don’t have Windows 8.x. I checked the API and everything should be available, although at different places. Would it makes sense to report it, even if I can’t reproduce it?
Did any of your customers send you the list of errors they’re getting? It really pinpoints exactly what is wrong. What’s your plugin called?
Unfortunately I didn’t get detailed error reports. There were issues with the Cloud System:
I did some research and found out it is most likely related to the usage of thread pools as they were moved to a different namespace. But again, I haven’t test it.
Unfortunately, we cannot automatically patch it if it changed namespace, as we do not know whether it’s really moved or there’s just another class with the same name (happens a lot in Microsoft API). The only solution would be to rebuild your DLL and provide it for Windows Store Apps so users could place it in Assets/Plugins/Metro, which would then use that DLL version for the build.
Which is unfortunately not possible without Windows 8.x.
Ahh, thanks for that clarification. Makes sense. Understanding how this works will make debugging problems easier.
I did find a couple of bugs I’ve queued up to report on this process. I’ll just mention them here:
Abstract class with serialized fields.
If you have a base abstract class with public fields in it that should be serialized, and a sub-class of that class with the [System.Serializable] attribute on it, and forget to put [System.Serializable] on the base class, the built game will crash in such a way that it is very difficult to find the error. I realize not putting [System.Serializable] on the base abstract class is an error, but it just works in the Editor, Windows Standalone, webplayers, OSX, etc. Only when you get to the built game in Windows 8 Store does it fail.
Some class methods are being flagged as unsupported by the framework when they really are supported. I’m not sure how you’re determining what’s supported by the .NETCore framework, but if its by using the MSDN documentation, it is not always correct. I went through a discussion with the SharpDX developers on this:
Unsupported properties used in WinRT · Issue #458 · sharpdx/SharpDX · GitHub
Unity build fails on these properties:
TypeInfo.GUID
TypeInfo.IsEnum
TypeInfo.IsValueType
Type.BaseType
Type.IsPrimitive
These methods are listed as unsupported by the MSDN documentation, but in actuality they are supported in .NETCore and pass WACK certification tests. There may be others, but these are the ones I ran into.
Is your product a DLL or scripts? Because if its scripts and you just want to test it or need to add #if statements for Win8, you can send it to me and I’ll build it. If its a DLL, then coming up with a solution may be more difficult because you will have to create a .NETCore version of your DLL, which I could also do for you provided it doesn’t require a ton of changes.
It is a dll, but the source code is also provided within a unitypackages. Thanks for the offer, but as several updates are planed, I wouldn’t feel comfortable to annoy you each time.
Oh well. I guess you could get Win 8 and dual boot it or run it in a VM for testing. Anway, good luck!