.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<T> only be available if you selected NET Standard 2.1?

 

You can use backported version of Span<T> 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<T> 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 https://forum.unity.com/threads/hpc-vs-net-core-3-benchmark.762857/#post-5081243:

 

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?

 

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?

 

How about telling people "It's not supported by the runtime, don't try to use it"?

 

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.

 

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?

 

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?

 

I'm really disappointed to hear that. I've been a long time Unity user (since v1) and advocate. The gap between unity's .net and the rest of the worlds is growing. It's causing a lot of friction between Unity and the packages I want to use.

.net standard 2.1 or net 5 would be welcome as soon as possible. I understand it may be difficult, but the .net compatibility is one of your main selling points.

However, after the IPO, it's possible this will be even further delayed. Really disappointing.

 

I am curious if Unity uses Mono why is it so hard to support .NET Standard 2.1?

Mono added support for that in Sept 2019 along with compiler support C# 8. We are over a year since it was added and you are saying that Unity still doesn't support .NET Standard 2.1?

If Mono supports it why doesn't Unity get automatic support just by upgrading to support Mono 6.4.0 or later? Is Unity 2020 still on Mono 5?

 

Because they've modified Mono so much that it would take a lot of work to update their fork. Stupid decision if you ask me.

— https://github.com/Unity-Technologies/mono

 

Is there maybe a slim chance of getting a vague estimate of when we might see .NET Standard 2.1 support become available in Unity?

 

Now that .NET 5 is out this is becoming more of an issue, we would like to move our shared libraries over to .NET 5 but we are limited by what Unity can use. What can we do to convince Unity to assign some more resources to this?

 

Product Manager for the .NET area at Unity here.

We are hearing the user feedback on aligning with the latest development in the .NET ecosystem loud and clear and it is important to us to provide the best possible C#/.NET experience in Unity. While we do not have any plans to share at the moment, we are actively working on both short and long term plans within this area.

 

I for would love to stop having macro #if and 2 different .csproj for my project, one for 2.0 version of my lib for unity and 2.1 for my desktop, Xamarin and Blazor application. It make supporting Unity more and more difficult over time. I would upvote support for this.

I cannot slow down my other project from using 2.1 only Unity is dragging behind now a day, 2.1 has been out for a long time, maybe they wait for .Net 6???

 

You don't need two different csproj's, you can replace single <TargetFramework> with multiple <TargetFrameworks>.

 

TargetFramework is only fun if your API is covered by both frameworks. If the lib is fully compatible with it, yeah sure, but this is not always the case, sometime you have to prevent part of it cause it require more recent capability or dependencies this quickly get out of hands.
I can only use a single csproj and define value there and perform the macro into the source, but this is getting messy. I made 2 csproj and include the proper project instead was more clean in the end. One for Unity and 1 for the rest (Xamarin, Blazer, Desktop, Core...).

 

Are there any estimates here yet? The amount of time it seems people have been waiting on such a simple request seems pretty absurd to me.

 

So basically, the class library update also involves a runtime update, which hopefully means improved performance without user code changes? Not as fast as CoreCLR, definitely, but still welcome.

 

Please prioritize this for a climate change project

 

What? Lower power usage or something?

 

Microsoft.EntityFrameworkCore 5

 

I wanted to add a loosely related note here.

I've built a .net standard 2.0 dll, which performs heavy calculations on float-type data. When I consume it from .net core 3.1 console app (for testing purposes), and Unity (with api compatibility level .net standard 2.0), I observe very slightly different numeric results. The discrepancy ratio is about 1~2/100000, so for vast majority of cases this is quite negligible.

 

Maybe it may be because Unity's Mono currently handle floats internal as double. This will probably change with the mono update.

 

For those following this thread, Unity has new development status thread: https://forum.unity.com/threads/unity-future-net-development-status.1092205/ with .NET Standard 2.1 being available at the earliest in Unity 2021.2.