Unity Future .NET Development Status

It's not Core anymore since 2020. Microsoft dropped the “Core” suffix (in favor of no suffix) starting from .NET 5.

 

Syntax sugar works
everything else not

I have use it for many years in production projects
Every Unity version has C# compiler with support for roughly 1 C# version bigger than default option but you can use only syntax sugar from it.

 

Since the csc.rsp is thrown around a lot here lately, i want to make everyone aware that you don't need the .rsp anymore. If you go to Edit -> Project Settings -> Player -> Additional Compiler Arguments
you can actually just add

-langversion:latest

or

-langversion:preview

or even

-nullable

as well as other arguments to get the desired outcome without polluting the project with an extra file, as well as easier managing of these values.

 

Sure you can. Those are language features, not something defined by .NET Standard (which defines APIs, not language features). In fact, it's even easier to do this in an external .dll because you have more control over how it gets compiled.

Also worth noting that using this approach and/or the .rsp file approach won't work properly with the Visual Studio integration (JetBrains Rider integration will parse the .rsp file and report the right language version though). Not sure about Visual Studio Code integration.

You also cannot use file-scoped namespaces with MonoBehaviours and ScriptableObjects if you upgrade the language version this way, because when Unity parses your .cs files to locate the types defined in them, it doesn't do it in a way that is compatible with file-scoped namespaces. To fix that you need to patch the editor, or just use UnityRoslynUpdater to do that automatically.

 

Looks like at Unity 2023 cycle deprecated AssemblyBuilder API and I can't use it anymore. I still need AssemblyBuilder to generate assembly for my use case. What's the replacement solution to get similar AssemblyBuilder result?

 

Hi, can I have any hope that when the editor moves to the .NET runtime the game will no longer run as part of the same process as the editor? The current way things work make working with native plugins a nightmare as you have various issues with hot reloading (solved on Windows easily enough.. well we've done the work already) but on Mac when you have either Objective-C or Swift code (basically forced to use most Apple API's) dylibs will not unload on dlcose() due to the way the runtimes work in those languages.

The other issue you have is that crashes in native code bring down the editor, with a chunk of work can be partitially mitigated on Windows, again not so much on mac with no unloading.

Thanks, Ed.

 

I would like to know which part of dots will break when official upgraded to CoreCLR? Is that breaking changes just exactly the same with at game object land?

 

Hey @JoshPeterson. First of all, thank you for being very active in this thread, we appreciate it. I have been following this thread and have been excited for this change for quite some time, but I can't help myself becoming slightly impatient.

I understand that this is a monumental task, but I am also slightly annoyed that Unity, being the most popular engine in the world (with most resources and close relationship with Microsoft) does not already have this supported. With recent Unity scandal, I have been researching quite a few different engines and a lot of those running C# already have .NET 7 supported. I have a feeling that Unity management does not know what should be prioritized.

So, I wanted to ask:
1. How big is the team currently working on this incentive (as in number of people)?
2. I know you can't give any dates, but could you give an estimation of % being done (rough estimate)?
3. Could you give lower and upper bound time estimates when we could approximately expect this update?
4. What are currently the biggest/hardest problems that you are solving?
5. Are there any problems that need to be solved, but yet haven't been started?

Once again Josh, you have been wonderful in this thread and I have no doubt this will get finished under your leadership. This "rant" was not directed at you, rather at Unity management. Thank you.

 

@JoshPeterson one question, what progress has been made on the whole sdk style projects / dotnet native tooling feature? @xoofx started the UnityNuGet project and I am eternally grateful, in fact, he knows that to this day it is a child that we share (I'm a mantainer too)

But honestly, I can't wait to set that project on fire and get real NuGet support.

 

@JoshPeterson About that struct static constructor bug in IL2CPP, it was only half fixed. It still doesn't work for generic structs. I emailed back on the issue and got an automated response that it was re-opened, but haven't seen anything else in over a month. Could you check on it? (IN-43207)

[Edit] I was wrong, it does work with generic structs.

 

One reason why I *always* use a for loop with an upper limit instead of a while loop... ugh

(Although this is kind of a best practice...)

 

That had to be a huge job. Good to hear it is getting closer to initial release.

 

I hate to ask again, but is there any news on that blogpost?

 

Seem like they would keep everything to release in Unite event

 

This is a part of the modern .NET feature set, and is not "Stride-like". It, and things like it, will be a large part of the .NET transition this whole thread is talking about. There is no ETA, but it's under active development and in the coming year we'll see it.

 

Nearly a week now

 

We're all waiting...

 

@JoshPeterson
Hi, our team is doing preliminary research for future projects. The basic structure of future projects are: there will be a main project which works as a launcher. And there are several sub-projects which works as mini-games opened by launcher.

All these projects wish to be made by Unity. For now, our approach is to build main project as an apk running on our device. And all sub-projects will export the asset as AB, and export all codes as dlls. The main project is responsible for loading dll and ABs. And we are using hot-reload solution HybridCLR to make the demo.

The problem we are currently encountering is that the loaded dll cannot be unloaded, and all dlls can only be loaded into one app domain.

Whether it's possible to run each dll in the separate app domain, and unload / reload it at anytime in the future Unity version with .net?

Our core requirement is to safely isolate the running logic of multiple mini-games from the Launcher (the crashed mini-game will not lead to launcher crash and mini-game can not access launcher codes), but all content can be rendered together. If you have a better solution, please tell us

 

Sad...
Is there any alternative to app domain in the current .Net ？The requirements I am most concerned about are that the assembly can be load/unload/reload dynamically at runtime and the script in one assembly can not access the other via reflection (for safety)

Are both of these requirements impossible in future version of Unity with .Net?

 

I hope that with the .net upgrade, that sounds like i brings some breaking changes anyway, it will also be possible to finally get rid of those unnecessary magic properties, like .rigidbody, .camera, .light etc., that just generate undesired warnings ('use new to hide'..) because it's natural to use these names for your own members.

 

They shouldn’t bring too many breaking changes actually, apart from switching AppDomain with AssemblyLoadContext.

Anything that it does break however is unrelated to API implementations like these.

Personally, I’m with you, those properties are idiotic.

 

I would propose a different naming convention for your private fields such as

_rigidbody

; (underline in front) otherwise it is too easy to clash with your local scoped variables anyways.
However I agree that all unity fields that are exposed should really behave like a field access (fast, no side effects) instead of calling

GetComponent<>

internally. Also please make sure the dispose pattern is properly implemented for Components (instead of needing to check the instance against a boolean)

 

Hi, thanks for the hard work, is there an ETA that we can have access to CoreCLR in alpha builds?

 

It's now three weeks since you say there was a blog to be published though

 

Still can’t do things like

renderTexture?.Release();

Any hope you’ll take a second look at handling null in Unity? It’s only gonna get worse…

 

I always thought that the improvement for Unity's null handling would be to replace it's equality operator overloads with some kind of

IsAlive

property or method. The thing is, it wouldn't allow that kind of null-conditional operator, because you'd still need to check if the Object's native part still exists.

I'm curious about how that kind of null-conditional usage would be allowed. Would the Release method check if the Object is still alive before actually trying to execute?

 

You can do this right now by using an extension method. Inside the extension method, do the null check and call the relevant method if the check is false.

Code (CSharp):

1. public static class RenderTextureExtensions
2. {
3.     public static void Free(this RenderTexture renderTexture)
4.     {
5.         if (renderTexture == null)
6.         {
7.             Debug.LogWarning("Attempted to free a null RenderTexture. Ignoring request.");
8.         }
9.         else
10.         {
11.             renderTexture.Release();
12.         }
13.     }
14. }

This is not the best solution, as you would need to do this for 100s of methods, but it's a good enough workaround for now.

 

The problem is, why would I want to do that? The point is not so much about possibility as it is about convenience. I already make sure to do null checks. Extensions methods sound not like such a good practice here, because it gives you a lot of small code with little purpose to do upkeep on, and when or not you implement this pattern requires clear and distinct rules as to not confuse anyone using your codebase.

To be fair, there is a larger issue about clarity and causality. If Unity won't tell you the difference between

null

or

destroyed

, then this can in special cases lead to unforeseen and hard-to-debug errors (mostly editor scripts). My point is more so about

null

not being properly represented that makes it hard to reason about some things here and there.

EDIT:
That being said, sorry for being a bit douchy, I appreciate you taking the time to help and think along <3

 

I agree. I never actually do the above unless I need to log that such an operation was attempted. I really despise how Unity handles

null

. I am DREAMING for the day I will be able to use my dear

?

and

??

operators

 

The problem with the ? and ?? that they aren't overridable, so we will never be able to use them while we also have fake nulls to keep tabs on the unmanaged objects. I really like the analyzer approach, if it can be made robust and replace these usages with isDestroyed calls (or whatever the method for checking ends up named) in case of Unity-specific objects.
Although obviously it's a little bit error-prone since we need a robust analyzer otherwise we open up for very (I mean very) hard to find errors.

 

A cool thing coming to C# 12 is that it will start introducing breaking changes. But the way they do it is as such:
- They have determined a breaking change they want to introduce in the future.
- The next version (in this case C# 12) will start to throw compiler warnings about the breaking change.
- The version after that (C# 13) will include the breaking change.

I've said something along these lines before, but Unity can start deprecating code, with a message stating in which version that deprecated code will be removed. That sounds like a perfect fit.



For anyone interested, the breaking change in C# 13 is going to be field as a keyword. I'm pretty excited as it will allow for the following code:

Code (CSharp):

1. [field: SerializeField] public float myFloat
2. {
3.     get => field;
4.     set => field = Mathf.Clamp01(value); // Instead of keeping a separate value.
5. }
6.  
7. void OnValidate()
8. {
9.     myFloat = myFloat;
10. }

 

Hi Josh. The last update to the main post was back in February 2023. Would it be possible to update it based on current goings-on?

 

The blog post is live: https://blog.unity.com/engine-platform/porting-unity-to-coreclr