Unity Future .NET Development Status

Thanks for sharing with us, you might want to pin this.

 

Hi, Josh, thanks for the info and I really appreciate you are really trying to help.
It seems like you have a lot on your plate and I'm a bit worried if you will burn out before reaching the goal. ^^

To be honest, the only thing I'm interested in is the .NET 6 support. The biggest problem I had was slow Editor performance and long iteration time as project size grows. I currently ditched Unity because it was too painful to use and moved Unreal right now. I'm really happy with Unreal but I miss C#. I vowed to myself not to start another large-scale project on Unity unless Unity gets rid of Domain Reload and improves Editor performance. I believe .NET is the only answer.

Mono will be history soon and it has no future. And my question is that, are all support for .NetStandard, C# 8, 9 necessary steps for .NET 6? I'm sure it's useful but I'm not certain if we need to beat around the bush instead of going to the goal directly. It looks like you will be quite busy throughout the year supporting Mono. .NET 6 will probably give us everything you mentioned above anyway, no?

I'm really excited about the .NET preview later this year. I suppose it is an independent build without Mono, right? If so, it is really a good decision. Rolling in smoothly into the existing eco-system will be very difficult with all the old baggages to carry around. It will be much easier to add Mono migration support after it's released first.

Please keep the good work.

 

Exciting news. While breaking changes are happening, is there any chance of rectifying the funky Unity-only behavior of the null coalescing and null propagating operators? While I understand the reasons for the null equality override that causes this issue, the concern seems outdated in a context where Unity development has become more professionalized.

The operators themselves are a very popular feature, and I'm unfortunately put in a position where I constantly have to steer my teams away from them, to their dismay and indeed skepticism. It seems to me that exposing a public `Object.destroyed` member would be a good tradeoff for getting to use more updated language features - even if this were only made optional in project settings.

 

Thank you.
I'm really looking forward to the new .NET and C#.

One thing that bothers me about this story is Span.
There are two modes of Span, one called Fast Span and the other called Slow Span.
There is a big performance difference between them.

I think we have to wait for CoreCLR before we can start using Fast Span,
but one more thing, I think we need to support IL2CPP.

It would be nice if the status of Fast Span support could be made visible.

 

This is great news and something I hope that comes sooner rather than later, and that you can stay up to date with the latest releases!

One thing I think you guys really need to get on is the Visual Studio integration. Unity projects are still dodgy and not real .csproj files, and lack features such as project references, which is really important for some projects such as Client/Server games, where multiple projects are needed, with shared projects between. Something I am working on. I was shocked to find out a few months ago that project references are not supported, and that I had to add post-build command arguments to copy the generated DLL files into the unity scripts folder to use them, this is just a bit dodgy and removes features such as debugging and being able to step into code from the shared project, as there is no code available in the DLLs, metadata.

I would be glad to talk to you more about this if you need more feedback.

 

Pretty sure that you can generate the pdb and copy them along with the dlls.
I know that it is possible to attach Visual Studio and debug mods for games allowing loading dlls at runtime.

But you're 100% right, improving Visual Studio <--> Unity link would be a very good idea.
Especially the attachement which sometimes do not work well, and the breakpoints which will not always work (maybe because of generics, not sure about it).
Unfortunately I'm pretty sure that it's not the same team in Unity who is responsible for that.

 

How would a destroyed property fix the null coalescing and null propagating operators? As far as I understand, the problem with those is that they cannot be overridden and always check the true null state, instead of the custom null comparison.

 

I think the point is, we then could have unity in newer version have a converter to convert code that use implicit conversion from GameObject to boolean into GameObject.destroyed instead

 

The biggest elephant in the room here is the GC implementation.

 

This is related to my previous post. Fast Span cannot be implemented as long as Unity uses their old GC implementation as the GC must be aware of the Span references (don't remember the details but can be easily found on google).

 

Yes probably not tied to .NET version at all, unless switching to .NET Core / .NET the csproj structure is considerably different. Thanks for replying to my concerns, it pleases me to see you guys stepping the right direction.

 

Ah so you are saying that the current GC implementation would already support Fast Span? Last time I asked I thought that the GC implementation was one of the biggest obstacle to overcome, but tbh this part of the CLR is not clear to me as I have read about it just once a long time ago.

 

There are some features that are still not supported properly in IL2CPP. IE exception filters:
https://forum.unity.com/threads/il2cpp-exception-filter-support-eta.1087604/#post-7010431

I wish there was a comprehensive list of things that are and aren't supported when comparing IL2CPPs version of C# to the version of C# Unity claims to support. Its not enough to know unity has support for, say, C#8 or whatever - I guess we need a clear breakdown of whats actually supported with each version and what isn't. Preferably a single page that lists the C# feature and which unity version onwards supports that feature. Or something that effect. One source of truth where I can check to make sure I'm not using something that'll break on device but work fine in editor.

 

I would just like to applaud the Unity team here on such clear, and honest communication with regards to such a core engine feature. Seeing this fills me with confidence that Unity scripting is on the right track, and working on solid, measurable improvements in reasonable time frames.

Good luck to the Unity team and keep up the good work with .NET and IL2CPP!

 

Thank you for the thorough overview - an excellent roadmap to look forward to
On the topic of planning ahead: Do any of these moves hold the potential to disrupt use of Cecil on Unity-compiled assemblies? On the surface I would not expect so, but wanted to verify in case we do indeed need to account for an eventuality like that.

 

Excellent! Exactly my meaning and expectation. Thanks

 

.NET 6 will probably have an official nativeaot (in preview) compiler which produces higher performance code than il2cpp. I think unity can make use of it to replace il2cpp in the future.
https://github.com/dotnet/runtimelab/tree/feature/NativeAOT

 

Can you expand more on this? The only feature I would like to see for this future .NET Core ecosystem is the plan to reach ultimate goal of Unity getting to insanely fast 500 ms compile and enter play mode iteration time. Currently what I see despite the long script compilation time, the domain reload also cost quite long time. Will Assembly Load Context can totally eliminate domain reload or only domain reload the changed assembly if my project supported fast enter play mode? Just change 1 line of code should take less than 5 seconds.

 

Pretty sure the original scenario described is something like:

1. cs Project A builds an assembly with shared resources / protocol definitions etc.
2. cs Project B builds some runtime target like a server standalone - it references project A directly - not via assembly.
3. Unity Project C needs to interact with B via A (network protocol / file formats / IPC / whatever).

AFAIK step 3 can only be resolved by having Project A produce an assembly which is dumped into Unity Project C - rather than optimally have it reference Project A directly like Project B does. Unless there is an asmdef/ref use case here which I am unaware of?

 

Mono is a dead end. Time to break and move to CoreCLR.

 

Looking forward to covariant return types! Might make some templating a bit more elegant.

I think I would prefer the more concise and elegant code that the new null operators allow over the additional debug info when a NRE is thrown. Usually the LOC is enough information to find the source of the issue.

 

@xoofx

Can you elaborate on this part? Especially the "today" part. Has something changed with core GC mode since this documentation was written: https://docs.unity3d.com/Manual/BestPracticeUnderstandingPerformanceInUnity4-1.html
I'm not talking about incremental feature, it just supplementary to GC corework.

 

Can you elaborate on this one? Will unity support multiple tfm configurations similar to Xamarin/Maui? Because that would be neat.

 

My 2 most painful points today that would be easier to alleviate by the fact of not having to do with .NET5/6/Mono/CoreCLR/etc have to do with project generation.

1. Inability to use Nuget packages

The fact of not being able to do it leads to having to bring the whole chain of dependencies of a nuget package manually (dll one by one) with the loss of time that it supposes initially and in the consequent updates.

It has led for years to "fight" conflicts of different versions of asset store asset assemblies or even official Unity packages. Examples:

https://forum.unity.com/threads/ple...ystem-runtime-compilerservices-unsafe.732056/

https://forum.unity.com/threads/con...onsoft-and-packagemanagers-newtonsoft.843898/

Another problem that I've been fighting for quite a long time and I managed to solve partly thanks to @HaraldNielsen: https://forum.unity.com/threads/edi...ken-assembly-could-not-load-signature.754508/

Luckily since the emergence of UPM projects like @xoofx (https://github.com/xoofx/UnityNuGet) have emerged, to which I have contributed in several PRs and it helps quite a lot at least to be able to add nuget dependencies "in the world" of UPM.

I do not understand how in the era in which Microsoft embraces open source and cross platform tools, Unity does not take advantage of them and alwaays tries to reinvent the wheel with the expense of time ("NPM -> UPM fork" instead of using Nuget, Mono fork very far from the official one with the complexity of updating it, ...) and resources when it could be focused on functionalities more typical of an engine like Unity.

Since Unity left aside the other two languages (UnityScript and Boo) I don't understand why it doesn't use official .NET tools.

2. Replace asmdef files with sdk style csproj files

I see that this is something that is going to be worked on and I am very happy because it is something that solves the first problem and solves many others.

Since the sdk style format was created it makes it very easy to edit the csproj files by hand so it would not be necessary initially to have a special inspector in the editor unless you need properties that you want to migrate from Unity's own asmdef.

A problem that we encounter is the same as @Issun and many others and is the fact of being able to reference external projects to Unity (pure C#) without binaries (source code directly) as is the very common case of our communication protocols between a backend and Unity: Rest APIs with NSwag, shared data models, utility libraries, etc ....

It would also solve in part the continuous reloads with the Visual Studio blocking dialog that makes you open a new instance of VS. With SDK style reloads in many cases happen in the background without blocking interaction.

 

Welp, a 100 times, this. I also tried to do this with various degrees of success: https://github.com/KuraiAndras/CsprojToAsmdef

But the main pain point remains: All the automation you can do to reference packages and projects outside of unity can only get you so far. I have managed to use most NuGet packages, and csprojs outside of unity, but there are things that are still near-impossible to do. (Using the correct platform specific DLLs from SQLite? Localized DLLs used by FSharp.Core?)

Also, if you make changes to the project system what will happen to UPM? Will this mean that Unity will get some custom TFM, or that you will make it available on NuGet.org or through some other nuget feed?

 

Care to elaborate? I am a CoreCLR advocate but even I know that there are feature differences between the two that hold the transition back and those feature differences are important (like domain reloading).

Also, just wanted to say thanks here as well for making this blog thread. It was a bit overdue but much better late than never. Things like this give us the confidence to stay with Unity.

 

Meh, trivialities aside the truth is Unity is too busy maintaining its Mono branch to be serious about moving to CoreCLR.

 

Others have already answered this question, but here's what you need.

Code (CSharp):

1. // Fast Span
2. public readonly ref struct Span<T>
3. {
4.         ByReference<T> _pointer;
5.         int _length;
6. }
7.  
8. // Slow Span
9. public readonly ref struct Span<T>
10. {
11.         Pinnable<T> _pinnable;
12.         IntPtr _byteOffset;
13.         int _length;
14. }

Detailed blog post: https://adamsitnik.com/Span/
Quote:
IL and C# do not support ref T fields. .NET Core 2.0+ implements it by representing it via ByReference type, which is just a JIT intrinsic.

It's great to know that the latest mono already supports it.
I understand that IL2CPP works on a different mechanism.
In order to reduce confusion, and also for the sake of performance,
it would be nice if IL2CPP also supports Fast Span at the same time.
(Also, interoperability with NativeArray, etc.: ......)

Recently, I've found a big performance issue only on Unity in my library that work on both .NET Core and Unity.
That performance issue is caused from the use of (Slow)Span.
There was a bigger performance difference than shown in the bloThere was a bigger performance difference than shown in the blog (maybe because the runtime on the .NET Core side is .NET 5).
g (maybe because the runtime on the .NET Core side is .NET 5).
I don't want to think about SlowSpan if I'm going to be able to use it as standard in Unity.

 

Care to explain more? Maybe this was the missing bit I was thinking of. In other words I could just ask: what is actually missing to support fast span?

 

Ah, yes, I see what you mean, I've read your blog a while back on this proposal of local to stack reference types.
Honestly, it is about time we can have some leeway in the size of the stack within reasonable limits that dont affect hurt general performance much. Perhaps may be per thread with some small additions.

 

I'm sorry but I have to ask if you're trolling or you were just too lazy to read the posts above.

First off, they've already said here and in the other thread that they need to support these features (.NET 6, C# 9+, etc.) to be able to move over to CoreCLR/RyuJIT in the first place. A couple of posts up, they even bring up an issue with AppDomainReload versus AssemblyLoadContext in that the latter is lacking functionality. In other words, they can't port the editor over with it as-is. There's more, just go actually read it.

Also, their process makes sense. If they go in the order of .NET Standard 2.1 -> C#9 -> .NET 6 -> CoreCLR. They will be able to update IL2CPP to be on par with CoreCLR (mostly) at the time they switch over. Then they'll have a much better base to keep things in parity with Microsoft.

And before you claim I'm a blind fanboy or something along the lines, I was one of the people grilling them in the other thread that lead to this dev blog even being made.

Of course, we'll see in the next 1-3 years how well they keep up on this.

 

1: Right they are in no rush to move to CoreCLR. It is not their main priority. They have too many platforms and they want to update mono.

2: You make it sound like CoreCLR is somehow is lacking too much functionality right now but that is far from accurate. Some things will need work but CoreCLR can deliver.

3: .NET Standard 2.1 -> C#9 -> .NET 6 -> CoreCLR. Does not make sense for most developers

This is a really silly discussion because Unity has its own plans which are based around their mono branch and all their platforms. Not necessarily what most developers want.