Unity Future .NET Development Status

@JoshPeterson I'm writing a simple clock system and I want to use TimeOnly which is in .NET 6, so I copied it and put it in a separate Asmdef.

Will there be a compiler definition to specify ".NET6_OR_NEWER"? I want to specify it be undefined in my constraints.

 

I guess you'll be able to use the framework defines documented here: https://learn.microsoft.com/en-us/d...eprocessor-directives#conditional-compilation

So it'd be NET6_0_OR_GREATER in your case.

 

Oh… right, my brain is square.

 

Hi. I was watching the Unity roadmap for 2023 talk from the GDC, and Simon Elliston Ball says that they are working on an API to make Fast Enter Play Mode easier to adopt. Then he says that this will also help projects be ready for the future of .NET with Core CLR. Here's the video at 7:20.

Here are some questions: Does anyone know what's the relation between using Core CLR and Fast Enter Play mode? Does the absence of Domain Reloads mean that we'll have to use Fast Enter Play Mode shenanigans? I already use them, I don't need to be convinced to try them, but it still makes me a little worried. I imagined Unity would still have something equivalent to Domain Reloads. If that isn't the case, what will happen to existing Objects in the Editor after user code is modified and recompiled outside of Play Mode?

Thanks!

 

How's this unlisted...

 

I don't have any internal information, based on posts here on forums I think it's something like this:

With CoreCLR, Unity Editor will use feature called "AssemblyLoadContext" for user assemblies

• AssemblyLoadContext supports Unload
• To successfully Unload assemblies, there cannot be any references to user types or instances
• If you subscribe for example to EditorApplication.update, that's a reference
• If you add instance of you class into some list held by Unity Engine, that's also a reference
• If you create GCHandle to instance of your type, that's also a reference

There are few possible ways to address this

1. Use Weak references (these don't "protect" object from Garbage collector)
2. Callback "OnBeforeDomainReload" with analysis tools
3. Analysis and forceful clearing

ad 1. Weak references are problematic for several cases, they are slower, make GC slower and would need to be placed everywhere where user instance can be stored (probably impossible).

ad 2. Callbacks on the other hand might work well, the problem with them is that they require users to use them and handle them well.

ad 3. Forceful clearing might work, but I'm not sure how realistic it is. Setting references to user instances to null might cause more issues.

My guess is that there will be some callbacks, which get executed when user code is about to be unloaded. You'll unregister events and remove object references you've stored anywhere in the Unity Engine. This will be accompanied by analysis tool, which will tell you which references are still there preventing unload.

Also it's likely there will be some fallback system, which will simply unload Unity Engine assemblies as well - or in the worst case, it will restart whole .NET runtime (which I'm guessing will be probably as slow as Domain reload with Mono).

@JoshPeterson Would be nice if you could confirm or refute this ^^

 

Personally, I'd hope Unity would rather host the player code in a separate process and just use IPC to communicate with that. This would remove the need for assembly unloading and would also introduce more stability to the editor.

 

That would not work with custom editor scripts.

 

AFAIK yeah fast enter playmode and coreclr require functionally similar code considerations, like resetting static fields manually and such easy tasks. But it only effects the editor behaviour and not anything in the compiled and shipped game.
So really not sure what @OndrejP is talking about.

 

Resetting manually is all good until you use a libary that cant do it and then its impossible

 

99% certain that only statics in monobehaviours / directly unity-interfacing-types have to be reset.

 

Wow that's wonderful.
I want more details about trends of Unity game development.

 

No, all static variables will remain with previous values, not only unity related ones.
For example, the native gRPC library seems to hold values in static variables so it completely breaks when u try to use it without domain reloads.

 

What's the plan re: static editor events that callback into user code? For example...

https://docs.unity3d.com/ScriptReference/Undo-undoRedoPerformed.html
https://docs.unity3d.com/ScriptReference/EditorApplication-update.html
https://docs.unity3d.com/ScriptReference/EditorApplication-playModeStateChanged.html

And the one that seems most tricky for this type of thing...

https://docs.unity3d.com/ScriptReference/AssemblyReloadEvents.html

 

Thank you for the detailed info, it sounds great.
Automatic event cleaning is good idea. I think that's one of the most common cases.

What about other things, for example when you add your object into some list, which is stored in Unity Engine? PlayerLoop comes to my mind or hooking something into UI through UI Toolkit and VisualElement hierarchy.
Will that be full responsibility of us?

 

So the best practice for a custom undo handler would be something like...

Code (CSharp):

1. // run once on app startup, then any time the assembly is reloaded
2. [InitializeOnLoadMethod, AfterCodeReload]
3. static hookUndoHandler()
4. {
5.     // subtract then add to prevent accidentaly being called twice; we on;y ever want one instance
6.     // of the undo handler attached
7.     Undo.undoRefoPerformed -= myUndoHandler;
8.     Undo.undoRefoPerformed += myUndoHandler;
9. }
10.  
11. [BeforeCodeReload]
12. static unhookUndoHandler()
13. {
14.     Undo.undoRefoPerformed -= myUndoHandler;
15. }
16.  
17. static void myUndoHandler()
18. {
19.     /* ... */
20. }

...? Ehhh... seems like a bit of a PITA, but I guess it's not too bad, and at least it makes it explicit what's going on.

 

Why do you think those wouldn't work with an IPC system? There's not really any reason why they couldn't, it just depends on the implementation of IPC used.

 

If I'm understanding ALCs correctly, an ALC can't be unloaded if there are references to it in other ALC. So I believe line 7 shouldn't be needed?

Many Editor tools and systems access runtime objects directly in code. Wouldn't that be impossible with IPC? I'm not saying all that code couldn't be changed to use IPC channels to interact with the running game, but that would mean rewriting a lot of code.

 

I don't know much about the domain/assemblies reloads that Unity must do when compiling or playing the game in the editor. But, I wonder if something like this could be used: DotNetIsolator: an experimental package for running .NET code in an isolated sandbox - YouTube.

 

I wouldn't expect this as it would require probably an entire revamp AGAIN of the engine and second of all I wouldn't expect it to work on the C++ side as well...

Sounds like something cool to mess with, but probably idiotic in a game engine setting XD

 

Sorry if this question is lacking awareness with regards to the current state of Unity, I'm just revisiting after being gone from this project for a while.

Is .NET 7 fully supported now for development with Unity beta 2023.1? - If it matters, I only target Windows.

By fully support I mean including the usage of C# 11.0 language features and able to build with the preprocessor symbols 'NET7' / 'NET7_0_OR_GREATER'.

 

No

 

@simon-ferquel-unity Have you considered hosting the user code in separate process and just closing that on reload while using IPC to make sure all the APIs work the same by the way?

 

This was mentioned above. It seems full of pitfalls and a TON of work on Unity's side to make everything work right (plus, some graphics APIs rely on direct pointer access to memory; you could maybe try to work it with memory mapped files, but... yeah, that sounds like its own can of worms).

The big question is "why"? They're already working on making code reload safe by doing the several layers thing, and adding instrumentation/analysis to help users modify their scripts to be code reload safe. The main benefit of process isolation would be sand-boxing/security, which isn't as much a concern in Unity as in like a web browser.

 

Well, actually it would be really nice for games which support modding. You could create an isolated runtime which does not let mod code access file system or network resources. It would probably not work with IL2CPP, but why would it not just run with the upcoming CoreCLR?

@JoshPeterson Did you have any internal conversation about this yet?

 

Well, yes you could make it so that editor code is reached through some IPC but that would require a lot of work from Unity. I think that with those resources they should just improve the hot reload experience.

 

Because third-party libraries which were not specifically made to be used in Unity -but in .NET as general- wouldn't work properly when reloading code. That is why.
The fact that Unity has these special quirks makes it much more difficult to use libraries from nuget.

 

What's an example of a 3rd-party library that would not work in Unity with ALCs in .NET core, but *would* work if it were hosted via IPC?

 

You can already do that yourself, though. If you're making a game (targeting mac/windows/linux) and want sand-boxed mod support, you can launch another process, give that process the exact permissions you want it to have, and access it via IPC. Sounds like a massive pain to do, but I guess if you're worried about viruses in mods.

 

While I somewhat see the benefit here, that should ultimately be completely up to the end-dev if they want to do it this way or not, just as burningmime is suggesting. Restricting possible resource access for mods is something that is deeply limiting, and is not something that 95% of games should ever consider, especially since you as the game dev are not in any way liable for mods and people should have the mental capacity of knowing to only use mods they trust, just like any other application.

 

In Unity2021LTS, List.Sort/Array.Sort allocates 128b, in .NET 6, there is no memory allocated. It's too bad.

 

Sure, in a performance critical context that IS bad, but you could just code your own algorithm , right?

But seriously though, performance improvements like these, which are built-in directly into the BCL is why we programmers are awaiting Unity + .NET 6!
Hope we get to see a polished implementation soon!

 

When will .NET 6 implementation published to alpha stage?

 

From what I've seen on Github, Unity's fork is already on .NET 8.
What would interest me is whether it is planned, since the .NET release and the first tech release are in the same period, whether Unity then updates the .NET version every 202x.1 version.

 

They stated previously that they will switch to a new dotnet version always very shortly after a new one is released.

 

Adding to my list of things to check out when the new .NET is available to test: ONNX Runtime for C#.

I know Unity has an inference engine in Barracuda, but Barracuda is really limited. I haven't been able to run a LLM on it yet .

 

Random thing I found in Net7:
https://stackoverflow.com/questions/390900/cant-operator-be-applied-to-generic-types-in-c

Code (CSharp):

1. You can do this with C# 11 and .NET 7+:
2.  
3.     static void Main()
4.     {
5.         Console.WriteLine(Compare(2, 2));
6.         Console.WriteLine(Compare(2, 3));
7.     }
8.     static bool Compare<T>(T x, T y) where T : IEqualityOperators<T, T, bool>
9.     {
10.         return x == y;
11.     }

There's a lot of interesting possibilities. Hopefully we'll get it soon!

 

Well yeah. 'Generic math' is one of the bigger parts of up to date .net. Definitely a great feature, and good to see more people finally being aware.

 

And the cool thing about all of this is that afaik this doesn't box, meaning no garbage!

 

im really exited to hear anything on this. Super happy to read this forum post and replys. can we expect a ".NET 8 pivot" engineering tools roadmap or unity platform roadmaps? i do see the roadmaps on their regarding upgrading to a newer version of C# and .NET Runtime roadmap but will there be one for this change in particular?

 

Is there any estimation as to when we will get this release plan? I.e. "a few years" or rather "a few months"?

 

They won't disclose their targets because they are not yet ready for the public. It doesn't matter how many people ask, it will be the same answer until they decide to tell us.