Unity Future .NET Development Status

Unity Engine
,
1

We’ve had a good bit of interest on various forum threads about Unity’s plans for C# and .NET in the future. Microsoft has been pushing the .NET ecosystem in a number of beneficial directions, and we at Unity want to bring those improvements to our users as soon as we can.

While we are not in a position to mention specific details about when various newer .NET features will come to Unity releases, we would like to provide more transparency into our ongoing work to bring these features to Unity.

Our goal with this forum thread is to provide updates on what we are working on, and when we think it will be available to Unity releases. As with any large software project, there are many unknowns, so everything discussed here is subject to change.

Please do not consider discussions on this thread to be official announcements, those will happen via release notes and blog posts. But we hope that more information will allow you to have more insight into our progress.

94 Likes
2

We wanted to give an update about our current progress towards support of new .NET features in Unity. I’ll try to list the work items we know about now and provide both a likely release as well as confidence about how likely we are to make that release goal.

Everything here is subject to change!

Update Unity’s fork of Mono to the latest code from the upstream Mono repo

(You can follow the development in our fork here: GitHub - Unity-Technologies/mono at unity-master-new-unitychanges)

Unity’s fork of Mono is about two years behind the latest upstream code.

  • So this effort pulls in many bug fixes from upstream Mono.
  • It also improves the managed debugger.
  • It will allow Mono to run in 32-bit floating point mode, improving floating point performance.
  • It brings in more .NET Core class library implementation, including many changes to the way the class library code interacts with platform-specific code.

When this change is available in Unity, it won’t have any new .NET features. But it does provide us a firm foundation to use to ship new .NET features in Unity.

The internal cut-off for Unity 2021.2 is approaching (weeks away), but we are 95% confident that this work will land in time.

EDIT: This work landed in Unity 2021.2.0a18

Add support for .NET Standard 2.1

Many of the API that users have been asking for from .NET Core (namely Span and ranges) are in .NET Standard 2.1. We’re planning to first add .NET Standard 2.1 support to Unity’s existing .NET Framework-based ecosystem. Although .NET Framework does not support .NET Standard 2.1, Mono’s class libraries do support it, so we should be able to provide a nice bridge to a .NET Core-based ecosystem.

We’re hoping to get this into Unity 2021.2, but it is not far along enough to be sure, I’m 75% confident that we will make it though.

EDIT: .NET Standard 2.1 support will be available in Unity 2022.1.0a3. It will also be available in a 2021.2 beta release. I’ll update here when I know the version.

EDIT 2: .NET Standard 2.1 support will be available in Unity 2021.2.0b6.

Complete C# 8 support

The newest Mono code mentioned above has default interface methods support. We still need to add this support to IL2CPP as well.

This, along with .NET Standard 2.1 support, will give Unity users full access to C# 8 features.

We’re hoping to get this into Unity 2021.2, but it is not far along enough to be sure, I’m 75% confident this one will make it as well.

EDIT: Default interface methods support is available in both Mono and IL2CPP in Unity 2021.2.0a21 and later.

EDIT 2: I was incorrect, Unity 2021.2.0a21 does not yet have default interface methods support. I’ll update this part of the post later when we actually have it shipped properly.

EDIT 3: Default interface methods support (and full C# 8 support) will be available in Unity 2022.1.0a3. It will also be available in a 2021.2 beta release. I’ll update here when I know the version.

EDIT 4: Default interface methods and full C# 8 support will be available in Unity 2021.2.0b6.

Complete C# 9 support

We’d like to have covariant return type support in Mono and IL2CPP for Unity 2021.2. This will bring full C# 9 support to Unity users as well.

We still have some discovery to do on this one, so I’m maybe 50% confident this will make Unity 2021.2.

EDIT: We don’t plan to have covariant return type support in Unity 2021.2. Other C# 9 features that do not depend on runtime support are present in Unity 2021.2 alphas.

Future .NET support

We are actively working on supporting .NET in Uinty, both in the Unity editor and for all player platforms. The latest information about this is available in a blog post, which includes a link to a GDC 2022 talk about our plans.
We’re not far along enough in this work yet for me to give a meaningful confidence level about when it will ship, but watch this thread and the Unity blog for updates.

EDIT: We’re planning to move directly to the CoreCLR technology a JIT runtime for .NET 6/7 support.

EDIT: I’ve updated our current status for future .NET 7/8 support and linked to our blog post and talk about the plans.

EDIT (October 27, 2023): We’re focused internally on developing and shipping new .NET support, with our current target being .NET 8. We don’t have a shipment date to share publicly yet, but I’ll respond on this forum thread with details when I do.

152 Likes
3

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

4 Likes
4

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.

11 Likes
5

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.

19 Likes
6

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.

7 Likes
7

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.

6 Likes
8

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.

1 Like
9

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.

10

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

11

Good point, done!

12

Yes, we do need to accomplish all of these step to get to .NET 6 support.

Mono already supports .NET Standard 2.1, C# 8 and C# 9 (although there might be some missing there, I’m not sure yet). So most of the work for these tasks will be Unity and IL2CPP. Honestly, I listed these tasks as separate steps because they are differently logically, but they don’t require nearly as much effort as the first task of upgrading to the latest Mono and the last task of full .NET 6 support.

I’m not sure about this yet. Our current plan is to continue to use Mono as the JIT runtime solution with the .NET 6 class libraries from corefx (the same ones used for .NET 6 from Microsoft). But there are still some unknowns around that. Here is a post on another thread where I recently tried to summarize the .NET ecosystem as we see it and what we plan to do: https://discussions.unity.com/t/779212 page-6#post-7029694

6 Likes
13

This is not something that we want to tie to the .NET upgrade work, as breaking changes for the move to .NET 6 will likely be possible to catch at build time. This breaking change would probably only be detected at run time, which makes it more difficult to diagnose with useful errors.

With that said, this change is likely not off the table, but is outside the scope of my team. I’ll ask the team which might tackle it though.

5 Likes
14

I’m not familiar with these two modes of Span. Can you provide links to documentation about them? I’d like to learn more.

15

This really is our long-term intention. There will always be some lag between a new .NET release from Microsoft and Unity’s adoption of it. But our goal is to make this lag a fixed, predictable time so that users can plan ahead.

9 Likes
16

Thanks for the feedback on this. I’ll bring it up with the team that handles it. I don’t think it is tied to the .NET upgrade, but certainly it seems there are areas here where Unity can improve.

10 Likes
17

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

2 Likes
18

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).

19

That’s not completely correct. Unity today is using a (stack-root) conservative GC mode and it’s an orthogonal problem to the Fast Span implementation. A conservative GC is more conservative than a normal GC, but it still tracks references on the stack. That being said the work required to support Fast Span is still necessary, but that was brought to Mono a few years ago already, so we should in theory benefit fast span (I haven’t checked how well this is working in Mono). The codegen won’t be as good as CoreCLR, but that will help to smooth the transition to it.

3 Likes
20

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.