Is there a plan/ETA for the .NET Standard 2.1 support?
Standard 2.1 no longer work with the “old” .NET 4.x Framework, and Mono support it with version 6.2.
Would new features like Span only be available if you selected NET Standard 2.1?
Is there a plan/ETA for the .NET Standard 2.1 support?
Standard 2.1 no longer work with the “old” .NET 4.x Framework, and Mono support it with version 6.2.
Would new features like Span only be available if you selected NET Standard 2.1?
We don’t current have an ETA for .NET Standard 2.1 support in Unity. We will make an announcement if/when we have an idea about support.
You can use backported version of Span from this NuGet-package: https://www.nuget.org/packages/System.Memory/
But standard BCL APIs that actually utilize this type are unavailable
Some benefits with Span would be the stackalloc without unsafe code. In some cases you can maybe replace native arrays.
I’d love to see support for .net standard 2.1 sooner rather than later.
So many awesome new things it adds like Span, ValueTask, …
Definitely would love to see support for .net standard 2.1
Count me among the folks waiting for .NET Standard 2.1 support in Unity. But I think Microsoft is the prime mover here - according to last years’ MSFT announcement blog post the new standard brings breaking changes that are mainly of interest to advanced users. I read that as implementation/upgrade will be cautious and possibly stay in Experimental/Preview mode for quite a while.
Personally, my project timelines won’t support testing out the new runtime for a while yet, so if it shows up in 2019.3 or even 2020.1, I’ll still be a happy camper.
Joachim mentioned in HPC# vs .NET Core 3 Benchmark - Unity Engine - Unity Discussions :
I have a library that uses .NET Standard 2.1 and now I see an error message saying I can’t create a type from it in Unity.
Backporting this library to .NET Standard 2.0 is possible but it will require quite a lot of additional changes.
Any ETA updates since?
Sorry, we don’t have an ETA on this yet.
As .Net Standard 2.1 was released mid-2018 as a long time support version, it’s surprising that Unity has not considered supporting this version as of mid-2020! Unity aims at cross-platform game development, which collides with .Net standard goals. I would personally love to see more support for cross-platform C# backend code. Thanks, and keep up the amazing work.
Slightly crazier to me is 2.1 apparently being a breaking release. Emphasis on it being a minor version. A breaking release by Microsoft. Is this some kind of sorcery?
We still don’t have an ETA for .NET Standard 2.1 support in Unity. Unity does support .NET Standard 2.0 though.
.NET Standard 2.1 is not just an API update, it also requires the .NET runtime support default interface methods. We don’t have support for this feature in Mono or IL2CPP yet. Once that support is available, .NET Standard 2.1 support will be possible.
How about telling people “It’s not supported by the runtime, don’t try to use it”?
Sorry, I’m unclear what you mean. Can you elaborate on where we should be informing users about this?
The compiler throws an error if you try to use default interface implementations on a runtime that doesn’t support it (like the current .NET Framework 4.7.something equivalent), thus there’s no risk of issues arising from it unless there’s miscommunication about the lack of runtime support.
From my understanding, you could support C# 8 and .NET Standard 2.1 without a runtime update, telling people only “Default interface implementations from C# 8 are currently unavailable because Unity’s runtime doesn’t support it” in the release notes and the usual release blog post. All we need is good communication. If you want to make it extra clear, have the Visual Studio Tools for Unity analyzer issue a message with the above quote when the CS8701 error is detected.
Thanks, I understand the question better now.
This is exactly what we have done for C# 8 support :). You can get it in the latest 2020.2 alpha release of Unity. Although we’ve not put out a release blog post yet.
I think the situation is different for .NET Standard 2.1, as it requires default interface implementation support from the runtime.
I don’t think so? Default interface implementations requires runtime support, but I don’t think it uses any new types. There’s no hard connection between the .NET Standard 2.1 class libraries and the .NET Core 3.1 runtime, is there?
Ahh yes, you are correct here. .NET Standard 2.1 is simply the reference profile, and does not say anything about how the BCL code used at runtime actually is implemented. My thoughts on this issue were muddled.
At the moment, the best chance for us to support .NET Standard 2.1 is with an upgrade to the latest Mono BCL implementation, which does support it. That code requires default interfaces to be implemented in the runtime. We have work currently in progress to make this happen, but we don’t have a release ETA yet.
Is this for real? You’re saying Unity only now has work in progress to support netstandard 2.1 with no ETA and we are stuck using technology from late 2017… at this rate .NET 5 will be released before you support netstandard 2.1, are we then going to be waiting years to get an uplift for that too?