Using .NET Standard 2.0 plugin with Unity 2017.2, UWP target only

I'm trying to use the Azure SDK library Azure Storage Data Movement in Unity 2017.2.1p2. Ultimately, the only target I care about (for now) is UWP since this is to be used in Windows Mixed Reality apps/games. I'm using the .NET scripting backend with .NET 4.6 Experimental support. I'm able to use the default Azure Storage library, but the Data Movement library gives me issues.

This library only ships with two types of DLL:

1. .NET 4.5 DLL
2. .NET Standard 2.0 DLL

The .NET 4.5 DLL works fine as a plugin in the Unity editor for that platform target only and Play mode works. The problem is when I try to produce a UWP build, Unity just doesn't like the .NET Standard 2.0 DLL, even if I flag it as "don't process" and surround my code with #if WINDOWS_UWP. I get several errors about some of the types requiring the .NET standard DLL. But even if I add that as another 'Don't process" plugin for WSA only, it makes matters worse, multiplying the errors by 10.

Has anyone had any kind of success integrating a .NET standard 2.0 plugin with Unity 2017.2? I don't need to use it in the Editor in play mode, and I don't care if it doesn't get processed. I just need to produce a UWP build and run it in UWP only.

 

Could you upload a minimalistic project that causes these errors when you try building it for UWP? Doesn't need to contain anything related to the project, just enough so that the errors occur.

 

Sure thing, it's not a big secret anyways, this is just a sample I'm working on. The code is already on my GitHub page at https://github.com/ActiveNick/AzureStorageDemoUnity3D. It works in the Unity editor but obviously not for UWP yet. There are 3 buttons in the UI Canvas and the third one is the one that calls the Data movement library. While the goal is to eventually make this a Windows Mixed Reality project, for now it's just a normal UWP project to facilitate debugging.

The UWP code itself was already tested outside of Unity in a regular non-Unity XAML C# UWP project, see https://github.com/ActiveNick/AzStorageDataMovementTest.

 

Okay, I'll take at look at it tonight. I hope you can wait a bit.

 

No worries, I'm exploring other approaches in the meantime. Any help is appreciated.

 

I think I discovered an interesting bug and/or limitation in Unity 2017.2.1p2 (I suspect it’s widespread in all 2017.x builds). It seems that Unity is unable to produce a UWP build of a project if a UWP DLL is used as a plugin and that DLL targets 16299.

Some notes:

1. Create a new Unity 3D project and switch to UWP platform, doesn’t have to be MR-enabled. Make sure to target 16299 / latest SDK.
2. Set the Scripting Runtime Version to .NET 4.6 Experimental.
3. Set the Scripting Backend to .NET.
4. Import a UWP DLL as a plugin and only include it for the WSAPlayer platform in the import settings. Make sure this DLL has at least one public class with a public method that returns a Task.
5. Add the proper #if WINDOWS_UWP in your Unity C# script to only call the plugin in the UWP build.
6. Try to build your UWP project. You will get the following error:

error CS7069: Reference to type 'Task<>' claims it is defined in 'System.Runtime', but it could not be found

I was able to reproduce this in two separate projects (including the project I linked above). Feel free to test for yourself using my very simple repro project WeatherExperience: https://github.com/ActiveNick/WeatherExperience. The OpenWeatherLib.UWP.dll plugin has been included in the repo, but you can check out my WeatherTalk project here if you want to see the source for this library: https://github.com/ActiveNick/WeatherTalk.

Any insights, explanations or recommended workarounds are appreciated. I know that 2018.1 adds some support for .NET Standard 2.0 and might address this problem, but it’s not an option. Using .NET 4.6 Experimental support is already a stretch, pushing so early onto 2018.1 beta isn’t realistic for now.

 

I played around for 10 or 15 minutes, but didn't quite solve it. I could get rid of the error highlighted above, but it kept doing the same with "FileMode" instead. It doesn't appear to be a bug, since some types were moved around during to iterative process of adapting to the .NET Standard.

I've had similar problems with a different library some months ago and solved them somehow, that's why I asked for the project in the first place. It wasn't the exact same error message, but it was a tricky one as well. It turned out I was a slightly different version that was set in the dependicies and thus couldn't figure out how it's supposed to work with it.

I'll try it again later.

 

@Suddoha I can probably figure out the file mode stuff. What did you do to solve the Task error?

 

Oh it's basically the same error, but I'll post the changes that I've made when I'm back home at my other computer.

 

@Tautvydas-Zilys is the same true about .NET Core DLLs?

Here's my problem exactly: I have a few plugin DLLs that are managed UWP class libraries targeting/min version of 16299. Not all of them cause an issue, but I do encounter this same "Reference to type Task<>…" error for the DLL that is returning some Tasks as part of the API. The ones that don't use Task seem to build and work just fine.

 

Interesting, the Microsoft.NETCore.UniversalWindowsPlatform nuget package I've been using for these UWP class libraries is targeting the latest version, 6.something - definitely not 5.0.0.

I haven't tried lowering the nuget package version to 5.0.0 yet because I found a different work around: Lowering the library's UWP target/min version to 15063 (instead of 16299) made everything build happily in Unity and ultimately works as expected. Again though, I didn't change the nuget package version, so not sure what affect lowering the UWP min/target version is having (?)