Unity Future .NET Development Status

Thr

the UI and hotreload/compile system seems to be entirely in C#. As is the main menu and at this point a lot of the entities.

 

Has "Span" arrived?

 

@JoshPeterson If you can pull off .NET 6.0 without forking it, will we get an option to not bundle it with the build and require installing it separately?

And could the player maybe become a .NET application eventually? No technical reason for it; just purity, I guess.

 

I've upgraded Unity to 2021.2.0b1.3029, and Visual Studio to 16.10.2, and Visual Studio Editor package to 2.0.9. Cmd also reports: .NET SDK is 5.0.301 and version 5.0.7 (NETCore 3.1.16 & 5.0.7, etc)

Still getting: "Target runtime doesn't support default interface implementation." when I try and make a concrete function inside an interface. I must be doing something really simple wrong. Is there a config I may have missed? Or is there a problem elsewhere and 0b1.x doesn't actually have 0a21.x update?

 

Thank you for the swift response!

 

I could be wrong but it should be expected for now, isn't it?
I mean it's still .NET 4.x and .NET Standard 2.0 only in API Compatibility Level. There no option to select .NET Standard 2.1.
And as I understand this error is OK while there no option to choose .NET Standard 2.1 api level

 

Will .NET Standard 2.1 api level be supported in 2021.2-3 ?

 

I mean using the "framework-dependent" model (like with .NET Framework), where players have to install the runtime instead of shipping it with and bloating the build, which isn't possible with Unity today because it uses a forked Mono and thus the official one is incompatible.

Ideally, the official runtime would also download and cache NuGet dependencies. I can dream...

 

Btw I didn't forget it, it's just that I wait for Unity to fix a crash bug that my project runs in always, so I can't test it.The bug report says editor, but it actually crashes the player too.

https://issuetracker.unity3d.com/issues/2021-dot-2-0a19-crash-when-entering-the-playmode

 

I'm wondering, what will happen to the old api levels? Will they be deprecated down the line in favor of .NET Standard 2.1? Personally I'd love to see only 1 supported api level in Unity eventually, even if its an older one, just for that extra layer of compatibility assurance. What is Unity's take on this?

 

.NET has the ability to replace the built-in GC to a user implemented GC, which means Unity can use its own GC implementation with .NET side by side.
See: https://docs.microsoft.com/en-us/dotnet/core/run-time-config/garbage-collector#standalone-gc

 

I think we can understand, thank you for letting us know !

 

Any word on updating Roslyn for source generators?

 

From my experiments it's possible to build dll with generator and insert it in project that target Unity 2021.2 as analyzer and it's just work.
But it need to target Microsoft.CodeAnalysis.* version 3.8.0

 

@JoshPeterson I'd just like to thank you for creating this thread, updating it regularly and openly communicating what your team is considering to do and what you are currently working on. We realize it's extra effort and I'd like you to know it is appreciated.

 

Is .Net Standard 2.1 targetting still gonna be added to 2021.2 now that it's already in beta (which means that in general only bugfixes, not new features are added)? The editor is already happy to load .Net Standard 2.1 assemblies when set to targetting .Net Framework (in .Net Standard mode it errors out saying that the assembly has a higher target framework) so I believe it wouldn't be much work other that changing the reference assemblies.

 

Do you know if Burst will have support for Span<T> as well?

Last I tried to use it with including System.Buffers.dll, burst failed to compile.

 

Are any C#9 features that require runtime support supported? For example function pointers with unmanaged calling convention.

 

Those require the presence of some types in the S.R.CompilerServices namespace (eg, CallConvCdecl) which aren't part of .NET Standard 2.1, so they're not likely to be supported until Unity supports .NET 5 or 6. You might be able to manually define the types though (they're all empty classes).

 

When will the alpha builds be available to download and try out?

 

I've been wondering, are there any plans for after .NET Standard 2.1 is implemented? There has been a lot of talk and speculation about switching over to CoreCRL, upgrading to .NET 6, even rumors of hot reloading have been spread around, but are any of these points (coming) on the "Team Josh" agenda?

 

Any update on using the standard .NET project system / build tools? It would be really beneficial if the csprojs would not be auto generated and we could have NuGet support, referencing csprojs outside of unity, and finally stop checking DLLs into version control?

 

I currently use a dummy csproj that copies the .dll and .xml files into the Unity project on build. It's a lot more convenient than manually downloading all the dependencies, allows me to avoid checking binaries into my repository, and avoids (most of) the weird edge-case issues that can crop up with the third party NuGet integration plugins I've tried before. I just went ahead and published it all here for anyone interested.

I should also mention that if a package references something that is already included (and thus results in errors within Unity), you can add it explicitly and then use ExcludeAssets="all" to prevent it from being copied into the project:

Code (xml):

1. <PackageReference Include="System.Numerics.Vectors" Version="4.5.0" ExcludeAssets="all" />

 

I have also made several solutions to this:
(Newer solution) https://github.com/KuraiAndras/CsprojToAsmdef
(Older) https://github.com/KuraiAndras/UnityCsprojNuget

I was recently tasked with creating internal documentation on among other things, what options are to using NuGet packages in Unity. I mean I get why it is not a high priority issue for Unity, but honestly It just bogles my mind that when some .NET developer wants to use NuGet packages as they used to, they have to spend days of fiddling just to get it somewhat right (neither of my solutions work the way a sane project setup would work).

 

This one ain’t mine so I can’t tell you too much about it, but for someone who isn’t really well-versed in all the compiler behind-the-scenes, this solution was really easy for me. https://github.com/GlitchEnzo/NuGetForUnity

It basically adds a NuGet package manager into Unity that handles the rest. I don’t know if it’s a complete solution to all the things described above, but I have been happy with its NuGet handling at least.

 

I finally measured the difference between

old mono fork

and

new mono fork

with that project I used for years to report performance regressions to Unity.

New mono fork is faster with this project. Below are the results and how the test works is explained here.

 

@Peter77 You are comparing a17 vs b5, could that difference just be that b5 is more polished/fixed up?

 

I would be more curious for a comparison of a version running the old .NET RT vs the new one *both* on .NET 4

 

@Peter77 The .Net 4.x/.Net Standard 2.0 setting only changes the target framework the dlls have, the runtime used for both is the same.

 

To be exact, the comparaison there is not .NET 4/.NET Standard 2.0, but instead old Mono fork from 2018 vs updated Mono

 

You're right, thank you for pointing it out. I've corrected my post.