Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

2018.2.16f1, UWP, .NET Scripting Backend, .NET Standard 2.0 Build Errors

Discussion in 'Windows' started by mtaulty, Nov 26, 2018.

  1. mtaulty

    mtaulty

    Joined:
    Feb 1, 2018
    Posts:
    8
    I wanted to check whether what I'm seeing around .NET Standard 2.0 in UWP applications is expected behaviour or not so if someone could possibly help me out I'd be much obliged.

    I am using 2018.2.16f1 and targeting the UWP platform (minimum and maximum versions both 10.0.177630).

    I have my Scripting Runtime Version set to ".NET 4.x Equivalent", my "Api Compatibility Level" set to ".NET Standard 2.0" and my "Scripting Backend" set to ".NET".

    I then try to use types from .NET Standard 2.0 such as "UdpClient" or "HttpListener". The editor is fine with me using these types & compiles my scripts but when I try to get Unity to build my Visual Studio solution I get an error "the type or namespace name 'HttpListener' could not be found (are you missing a using directive or an assembly reference)".

    As far as I know, these types are in .NET Standard 2.0 and I have used them inside of UWP Applications outside of Unity so I would hope to be able to use them inside of Unity when targeting UWP and .NET Standard 2.0.

    If I switch to IL2CPP then the project builds ok but I'd really like to be able to use the .NET backend if possible as it seems better during development from the point of view of build times & debugging.

    Should I expect to be able to build with these APIs using the .NET backend or do I need to give up and just work with IL2CPP?

    Any help greatly appreciated.
     
  2. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,646
    We don't support .NET Standard 2.0 on .NET scripting backend. It's only supported when using Mono and IL2CPP.
     
    mtaulty likes this.
  3. mtaulty

    mtaulty

    Joined:
    Feb 1, 2018
    Posts:
    8
    Ah, ok - thanks for confirming as I don't think I'd quite appreciated that .NET Standard 2.0 was strongly tied to IL2CPP.

    Is there a document link to that somewhere that I can reference which highlights this?

    A follow-on question. If I put my use of UdpClient inside of a UWP class library and then referenced that as a plugin from Unity would I then be able to make Unity build the code or would I hit the same problem?

    Lastly, I wondered whether the editor/build-system might stop me trying to build the combination of ".NET Standard 2.0" with ".NET Backend" if it's not a supported option?
     
    Last edited: Nov 26, 2018
  4. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,646
    I don't think we have any documentation with that exact wording (we do mention that a lot of types are missing here), but in general API Compatibility Level option has no effect for .NET scripting backend. Perhaps we should have disabled it, but it's too late for that as .NET scripting backend as a whole is getting removed.

    Putting that code in a class library might get you further, but I don't think it will work in the end anyway.
     
  5. mtaulty

    mtaulty

    Joined:
    Feb 1, 2018
    Posts:
    8
    Thanks again. I'm going to see what the effect is of putting my ".NET Standard 2.0" code into a class library and then telling Unity not to process those libraries and wrapping conditional compilation (ENABLE_WINMD_SUPPORT) around the code that is visible to Unity which makes calls into those libraries.

    My hope is that if I go down that route then Unity will leave my UWP specific code (and its calls into .NET Standard 2.0 APIs) alone.
     
  6. mtaulty

    mtaulty

    Joined:
    Feb 1, 2018
    Posts:
    8
    For anyone that follows on this path - you're absolutely right in that even if I embed my code into a library then I end up hitting the same 'unsupported' scenario for a library which targets a version >= 16299 as per this thread https://forum.unity.com/threads/usi...gin-with-unity-2017-2-uwp-target-only.514959/ where you provided a similar answer last year. Thanks again for all the help - I think I'm just going to have to "learn to love" IL2CPP and see if I can get to be anywhere near productive with using that :)