.Net 5 support

On that note, is it possible to get any confirmation on what the platform defines will be for the newer class libraries and features? I'm currently using NET_STANDARD_2_1 and NET_5_0 pre-emptively throughout my code, but it'd be nice to know in advance if NET_5 is used instead for example, as well as if there'll be a define for default interface implementation support.

 

C# 9 and .NET 5 relation is the same as C# 8 and .NET Standard 2.1. Some features require new BLC types, some require runtime support, but most of the features are just syntax sugar and could be used outside .NET 5.

All C# 9 features could work outside .NET 5 except

• Init only setters. Require new type
• Suppress emitting localsinit flag. require new attribute
• Covariant return. Require runtime support
  

P.S. Functional pointers could be used outside .NET 5 but look like il2cpp fail to process assembly that contains it.

 

There's also the module initializer feature which requires an attribute as well. However, Roslyn will happily allow you to use those features by defining the attributes manually. Unity also has the option of providing an automatically referenced assembly that includes them (which would just be a reference assembly with type forwarders when compiling for .NET 5).

As an example, I currently have this in a project which allows me to use SkipLocalsInit (as long as I use an updated Roslyn that supports it):

Code (CSharp):

1. // Licensed to the .NET Foundation under one or more agreements.
2. // The .NET Foundation licenses this file to you under the MIT license.
3.  
4. #if NET_LEGACY || NET_4_6 || NET_STANDARD_2_0 || NET_STANDARD_2_1
5. namespace System.Runtime.CompilerServices
6. {
7.     /// <summary>
8.     /// Used to indicate to the compiler that the <c>.locals init</c>
9.     /// flag should not be set in method headers.
10.     /// </summary>
11.     /// <remarks>
12.     /// This attribute is unsafe because it may reveal uninitialized memory to
13.     /// the application in certain instances (e.g., reading from uninitialized
14.     /// stackalloc'd memory). If applied to a method directly, the attribute
15.     /// applies to that method and all nested functions (lambdas, local
16.     /// functions) below it. If applied to a type or module, it applies to all
17.     /// methods nested inside. This attribute is intentionally not permitted on
18.     /// assemblies. Use at the module level instead to apply to multiple type
19.     /// declarations.
20.     /// </remarks>
21.     [AttributeUsage(AttributeTargets.Module
22.         | AttributeTargets.Class
23.         | AttributeTargets.Struct
24.         | AttributeTargets.Interface
25.         | AttributeTargets.Constructor
26.         | AttributeTargets.Method
27.         | AttributeTargets.Property
28.         | AttributeTargets.Event, Inherited = false)]
29.     public sealed class SkipLocalsInitAttribute : Attribute
30.     {
31.         public SkipLocalsInitAttribute()
32.         {
33.         }
34.     }
35. }
36. #else
37. using System.Runtime.CompilerServices;
38. [assembly: TypeForwardedTo(typeof(SkipLocalsInitAttribute))]
39. #endif

 

Yep, I forgot about module initializer.

BTW type for Init Only setter could be defined manually to. I even try it with unity but looks like il2cpp fail to process property setter with modreq.

Spoiler

I use just this in my .NET Standard 2.0 library (not for Unity) and Init only properties compile without any error

Code (CSharp):

1.  
2. namespace System.Runtime.CompilerServices
3. {
4.     internal static class IsExternalInit {}
5. }
6.  
7.  

 

function pointers is the biggest feature I'm looking forward to with its use in high performance C#. Would be great to be able to use that instead of

FunctionPointer

in Burst, since c# function pointers support generics.

 

https://www.dotnetconf.net/

.NET 5.0 launches tomorrow. Free online conference for everyone. Starts Tomorrow (November 10, 2020). Maybe Unity will make an appearance? (and no, I'm not expecting "we support .net 5 now" ... but maybe some news??)

 

Well, time to test Unity mono vs il2cpp vs Burst vs Net 5 mono vs Net 5 coreclr.

 

Spoiler alert: .NET 5 CoreCLR decimates the first two and maybe the fourth, Burst can maybe compete. Unity can't be bothered to make the switch anyway.

 

Can't tell whether you misread or I'm missing the joke ._.

 

I didn't misread. .NET 5 Mono is still Mono, which means that it's probably slower than .NET 5 CoreCLR, hence the "maybe".

 

Yes

https://www.infoq.com/articles/mono-xamarin-webassembly-net5/

This was half year ago.

It's worth mentioning (I was confused myself) that bigger part of mono is in Net 5 https://github.com/dotnet/runtime/projects/33#card-33949287, https://github.com/dotnet/runtime/pull/1912. More will be added in Net 6.

 

I wish Unity to support .Net 5 at least experimental in Unity 2021 and come to this conclusions:
- Unity 2021 LTS will be released around march 2022
- .Net 5 already released and .Net 6 will be released in Nov 2021 around half a year before Unity 2021 LTS
- .Net 5 dont have support for Android and iOS platform. Their support will come in .Net 6
- .Net 5 is not LTS and will be supported for 15 months
- .Net 6 is LTS and will be supported for 3 years

- if Unity want to implement experimental .Net 5 (and future) support into Engine then they already need to start prototype it for Unity 2021 and move to .Net 6 in Unity 2021.2 alpha to ship at least experimental support for .Net 5-6 features and build for PC and Mobile platform.

So question. Do Unity internally have plans to skip .Net 5 and apply .Net 6 as first supported .Net Standart 2.1+ feature compatible platform?

 

By the time unity would support dotnet 5, would unity like to switch from current build system to native dotnet build system? At least for html/wasm platform, I felt the interoperability and efficiency are better than emscripten

Also if we could switch to dotnet build ecosystem in mobile platform, we would have more access to xamarin codebase and library

Is it possible?

 

It's not only for C# code. The latest Mono can build for wasm, so you can run arbitrary c# code in the browser see --enable-wasm https://github.com/mono/mono#configuration-options . Also with Mono web assembly interop you can even invoke arbitrary js from the browser https://docs.microsoft.com/en-us/dotnet/api/mono.webassembly.interop?view=aspnetcore-3.0

 

Oh, I see what you mean, and yeah for the unity engine code Emscripten seems to be heavily needed.
But what I don't understand is why Unity continues with IL2CPP. Basically for the foreseeable future if you want to support newer dotnet versions you need to update IL2CPP, which also has it's own limitations. Why not ditch the C++ engine code and rewrite it in C#? I understand that is a HUUUGE undertaking but overall wouldn't it pay for itself? C# now offers a ton of low level optimizations, AOT compiling (I don't know if it would work with iOS but maybe?), and has an overall higher developer productivity than C++. To me it seems that with the time and effort put into IL2CPP and DOTS you could have just as easily rewritten Unity on C#, and do optimizations from there. Heck you could even create your own GC for specific optimizations. With a full C# toolchain you would not need to generate csproj and sln files, and developers could rely on nuget and .net standard project (now .net 5) libraries which would further make devs happier.

I understand that this would produce an unimaginable amount of work for your company, but to me it seems that by ditching the standard dotnet toolchain you gained some momentum ten-something-years-ago but the ecosystem caught on now, and you are just creating problems for yourself (upm instead of nuget? Dots?). Other companies already written pretty good (but really not as popular as Unity) game engines fully in C#. For example NeoAxis, and Stride.

I mean I know it won't happen in the foreseeable future but it would be really damn nice if starting a new unity project would just require:

Code (CSharp):

1. dotnet new unity
2. dotnet run

 

I see, that's unfortunate that we have a huge dependency at C++ side. It understandable then but still regrettable

Still I think we might have some option, such as separate most of engine code into wasm library and build our game code with dotnet 5 instead of IL2CPP

All in all I hope unity would improve js interop system so we could call arbitrary js library easier soon

 

What is missing in the interaction of Unity and JS is

• the lack of modern build systems such as Babel and webpack.
  
• .d.ts files (optional)

There is no official way to control the relationships.

 

Take from Razor is as easy as just this

https://docs.microsoft.com/en-us/aspnet/core/blazor/call-javascript-from-dotnet?view=aspnetcore-5.0
https://docs.microsoft.com/en-us/aspnet/core/blazor/call-dotnet-from-javascript?view=aspnetcore-5.0

Don't need to `merge` or any complicate setup. Calling js directly anywhere. Passing reference object around in any direction. JS could call C# method immediately instead of SendMessage. Working with promise and async is seamless

 

Also this https://forum.unity.com/threads/super-fast-javascript-interaction-on-webgl.382734/

Since 2016 we haven't seen improvement around this area. WebGL have been left behind every other platform. We haven't seen any major improvement especially around interop system, which required in complicate web game and webapp to use complex library written in js, majorly 3rd party like firebase and aws

 

Will the new JIT(the CoreCLR or the newer MONO) support ARM64 on Android?

​

 

Just wondering, what's the current status of Net 5 in Unity now that it's been officially released?

 

When we could expect the documentation, or at least, could you provide some sample and little explanation right here. Because I am currently working on webgl project right now

 

I can't undrstand, WHY don't you write all your engine in c++, but maintain all core in c++ and interop via c#? In this case you need to maintain 2 systems aginst 1, WHY do you complicate your life? The core is in c++, the BASE of the engine, so i think the UI can be write very easy in c++, maybe you have it written in c++, and again you have interop it via c#. The c++ is low level language, more powerfull, now it is upgraded every 3 years. WHY don't you give us the oportunity to write games in your engine in C++?
And then will not be the questions like in this forum, as why .NET 5 is not available in Unity

 

Ok, then why don't you do as Huszky said earlier: rewrite all engine in C#? If C# is better than C++. And then we will have all modern C# features, as soon as they will come in release, and again, here will not be the question like this )) Why did/do you write core in C++, if Unity is a framework/app based on C#?

And i find it interesting why Unity don't give us oportunity to select between C# / C++, like CryEngine as example do?

In your answer you will understand why we don't have C# 9 and NET. 5 at the moment, and why we can't write in C++, and why Unity are between these 2 tehnologies and why these tehnologies can't be updated to the last features, but we need to wait minium year and more before we will get the last features, wich are allready outdated when they come in the engine, and on the market are other new features more performant, wich we again will need to wait while Unity will impliment them
As example C# 8 was released in september 2019, but we will get it in Unity 2020.2 wich will be released we dont know when, maybe at the end of this year but more likely next year.
So let's other people make their impressions, we need your answer to this.

 

I know you want to provide correct and helpful answers, which is very appreciated, but I think you shouldn't be compelled to answer to people that clearly are only ranting, especially when these 'questions' have been answered a few times already.

 

Unity can't move to Net5 CoreCLR from Mono because CoreCLR doesn't have any embedding API like Mono have.

CoreCLR provides a host c++ class and a way to call a static function from c++ to c#, that's all.

They are not providing embedding API like Mono, it's a dick move from Microsoft.
If Unity want to change, they have to create their own embedded API to run Core DLLs based on System.Runtime.dll instead of mscorelib.dll.

Also, Unity use App domains to load and update scripts, you can't create app domains with CoreCLR, CoreFX API, whatever.

 

To be fair. I know there was many complicate reason and history why unity are stuck with many legacy. Actually it was boiled down to the same old legacy burden problem like everything in our world

But I think the point is, sure it would not be immediately but, I think unity should planning for decoupling its engine system out away from build system. And make it so we could upgrade or exchange the dotnet version freely. We could still have C++ engine and all but it should not interfere with what we building that would get into IL anyway

This should also apply to build tool and platform support. We should not stuck with specific java or android or emscripten sdk version. Every build templates should be pluggable and you should opensource it so we can contribute, fix bug, or make our own

Which so far I think I don't see any plan about this. What I see at least what you talk about in here is only plan on engine system, which is great on its own, but not solving the problem about platform building

 

Unity 2020.2.0b13 includes .NET Core SDK under "Editor/Data/NetCore/" but the included .NET Core SDK version is v2.2.
.NET Core 2.2 is unsupported now.

How about including .NET 5 sdk as the first step of supporting .NET 5?

 

I thought porting C++ to HPC# (C# + Burst) was the consensus at Unity based on this post.

 

Any updates regarding that research (for Windows in particular)?
It'd be really nice to have more flexibility with code that needs better performance than can be provided by the current runtime. At the moment, the only options are Burst and native plugins but they're often an overkill.

 

Got it ^^
Thank you for your patience answering our constant questions.