Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct here to familiarize yourself with the rules and how to post constructively.

  2. Unity 2022.1 is now available as the latest Tech release.
    Dismiss Notice

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

Discussion in 'Windows' started by NickLandry, Jan 30, 2018.

  1. NickLandry

    NickLandry

    Joined:
    Oct 12, 2016
    Posts:
    26
    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.
     
    florianthurnwald likes this.
  2. Suddoha

    Suddoha

    Joined:
    Nov 9, 2013
    Posts:
    2,825
    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.
     
  3. NickLandry

    NickLandry

    Joined:
    Oct 12, 2016
    Posts:
    26
    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.
     
  4. Suddoha

    Suddoha

    Joined:
    Nov 9, 2013
    Posts:
    2,825
    Okay, I'll take at look at it tonight. :) I hope you can wait a bit.
     
  5. NickLandry

    NickLandry

    Joined:
    Oct 12, 2016
    Posts:
    26
    No worries, I'm exploring other approaches in the meantime. Any help is appreciated.
     
  6. NickLandry

    NickLandry

    Joined:
    Oct 12, 2016
    Posts:
    26
    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.
     
  7. Suddoha

    Suddoha

    Joined:
    Nov 9, 2013
    Posts:
    2,825
    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.
     
  8. NickLandry

    NickLandry

    Joined:
    Oct 12, 2016
    Posts:
    26
    @Suddoha I can probably figure out the file mode stuff. What did you do to solve the Task error?
     
  9. Suddoha

    Suddoha

    Joined:
    Nov 9, 2013
    Posts:
    2,825
    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. :)
     
  10. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    9,451
    Hi,

    we don't support using .NET Standard 2.0 DLLs on .NET scripting backend. It should work if you switch to IL2CPP.

    We don't support it because that would mean we would have to increase minimum supported OS version to 10.0.16299 (Windows 10 Fall Creators Update), which just came out and that majority of the gamers have not yet updated to it. And by the time that dynamic changes, we'll be dropping .NET scripting backend support whatsoever.
     
  11. briank

    briank

    Joined:
    Mar 25, 2017
    Posts:
    74
    @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.
     
  12. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    9,451
    You can use .NET Core DLLs on .NET scripting backend as long as they are compiled against Universal Windows Platform, version 5.0.0. Later versions require IL2CPP.
     
  13. briank

    briank

    Joined:
    Mar 25, 2017
    Posts:
    74
    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 (?)
     
  14. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    9,451
    That probably made you reference older class libraries.
     
unityunity