Search Unity

2018.4.1f1 w/ .NET Scripting backend - System.Net.WebSockets no longer exists

Discussion in 'Windows' started by sjando, Jul 3, 2019.

  1. sjando

    sjando

    Joined:
    Nov 6, 2017
    Posts:
    18
    In project that makes use of System.Net.WebSockets using.NET scripting backend, builds are now broken as of 2018.4.1f1 and newer when using "Unity C# Projects" option in build settings. Project is generated but Visual Studio build fails with:

    "The type or namespace name 'WebSockets' does not exist in the namespace 'System.Net' (are you missing an assembly reference?)"

    Same project works without issue in 2018.4.0f1 and recent 2018.3.X.

    Seems related to the fix discussed in this thread: https://forum.unity.com/threads/typ...-when-building-net-uwp-project-2018-3.656779/, which appears to have dropped the Microsoft.NETCore.UniversalWindowsPlatform version in generated projects but not in the main project.

    Can be worked around by not enabling "Unity C# Projects" or by manually bumping the dependency in all affected generated projects.

    I'd expect scripting assemblies by default to always be built against the same UniversalWindowsPlatform version regardless of "Unity C# Projects" option, and that that version should not remove features introduced in Unity 2018.3.X
     
  2. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,680
    Bumping of Microsoft.NETCore.UniversalWindowsPlatform for generated C# projects for scripts was not intentional and it broke many things. It wasn't a "feature". 2018.4.1f1 just reverted it to what it was a few weeks before.
     
  3. sjando

    sjando

    Joined:
    Nov 6, 2017
    Posts:
    18
    Thanks for the clarification.

    Was bumping to the same version in the main generated UWP application project (Editor\Data\PlaybackEngines\MetroSupport\Templates\UWP_.NET\project.json) at the same time also an unintentional change (still in place as of 2018.4.3f1), or was that one part of the plan?

    Also, is there a list somewhere of the things that are known to be broken by the now-reverted change? This would be helpful in making a decision around what to do with my project moving forward (I haven't encountered any issues with it yet)

    Relating to the above, is there a way I could override this per-project? (with e.g. a build script - obviously this isn't officially supported) With Unity C# Projects generated modifying each class library's project.json is enough to get things working. But the only way I could find to get a solution generated to begin with is modifying Editor\Data\PlaybackEngines\MetroSupport\Tools\project.json, which will obviously impact all projects. There seems to be a per-project copy of this stored at UWP/project.json but that gets overwritten every build attempt and fails the build before there's a chance to modify it.
     
  4. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,680
    That one was intentional. There was a .NET GC bug that some people were hitting that was causing a memory leak. The only way to fix it was to bump the final applications target .NET version.

    The specific instance I know of is System.Net.NameResolution.Dns class: https://issuetracker.unity3d.com/is...fails-when-using-system-dot-net-dot-dns-class

    I don't think there's a supported way to do it.

    By the way, the only reason we haven't updated it was because we don't have a full grasp of what would break when we do, and since we are deprecating the .NET scripting backend we didn't see value in doing due diligence in finding that out as it would involve a lot of work.