You’r right, now I see the problem. 
I’m curious about the new logging system that was quickly announced in the GDC video, any info on when we’ll have a good look at it?
Also, will this be replacing Entities Journaling, or are there completely different things?
In 2026 the focus is native logging and we probably won’t surface anything to the C# API. There may be some performance benefit for logging heavy code, but we haven’t measured it.
Unrelated.
Thanks!
Can you explain what you mean with “native logging”?
Is it Console.WriteLine(), Microsoft.Extensions.Logging?
From your message I understand it won’t change anything for us, but from the video they were talking about more control like log output.
Maybe I’m missing something idk.
I think people has an impression that there will be a new and better logging API to replace Debug.Log. So it’s not the case and the changes are only internal?
Can we force auto static cleanup as default for all statics? I currently don’t see a good reason to keep statics after a recompile (other than maybe UnityEditor code)
4 Likes
Yeah I think default it and then let us set them off should be a good idea, no?
11 Likes
Right. All the announced logging work relates to the internal layer, which is a prerequisite to any future C# logging API changes. We haven’t talked about a release version for those yet.
10 Likes
Those attributes are not for after a recompile; they are for when Fast Enter Play Mode options are enabled. That mode disables reloading Domain/ALCs when pressing Play in the Editor. That mode is gonna be enabled by default soon. The way those attributes work (with a source generator), it’d be very hard for this functionality to work by default when entering Play Mode. For example, classes with static fields need to be partial, and they can’t be generic. It could also break stuff without recompilation.
On the other hand, the reloading of Assembly Load Contexts (ALC) after recompilation already resets static fields of the reloaded ALC. ALCs are what CoreCLR uses instead of domain reloading. They allow reloading a single assembly instead of reloading the whole application.
So if all user ALCs are reloaded, even ALCs for user assemblies that were not recompiled, the behavior you desire might already happen. I don’t know if that’s the way it’ll work. I’d like to know too 
. Maybe it’s much faster to only reload the ALCs for the assemblies that were recompiled.
Either way, we may also need to remove references to user types from Unity assemblies before recompilation, as it seems Unity’s own contexts will never be reloaded. For example, we may need to manually remove our listeners from Unity Editor callbacks before recompilation (although, maybe Unity could clear them manually themselves).
3 Likes
Thats very awesome to head, thanks unity team <3
1 Like
Understanding that Unity continues to level up, performance wise, where does Unity Visual Scripting fit in these updates?
I mean… DOTS, Entities, new hierarchy… C# 14 update?
uVS as it stands today - will remain relevant and functional with these updates like in the sense of getting better because they somehow are reflections of c#?
That means that if c# changes…
uVS nodes internal logic, follows up as well?
If c# gets better and more functions are available, so does the nodes library and types?
Long ago, almost a year ago, you said something about:
“Visual Scripting in particular is that it’s already available and clearly valuable and being used”
…is it?
I would love to see updates in its performance and the way it plays in real time performance, not to compete against blueprints from unreal, but to keep the pace of becoming a better engine overtime.
Or visual scripting may be something that is going to be removed / deprecated due to insufficient efficiency to grow in pair with c# and other unity features?
I only use uVS, so im interested in its future. Which is still a mistery to the active community in the official discord. Some official word helps 
3 Likes
Unity Visual Scripting is dead. Especially in the AI era.
7 Likes
With the migration to CoreCLR, I’m wondering how Satori GC (GitHub - VSadov/Satori: Experimenting with dotnet runtime. · GitHub) performs in Unity as a low-latency GC with decent throughput and small memory footprint.
Satori GC can be adopted by replacing dll files in the published app with Satori’s build (10.0-based branch for .NET 10), specifically, coreclr.dll, clrjit.dll and System.Private.CoreLib.dll.
2 Likes
The performance impact of that would be interesting to see.
It could be noticeable in large projects because it has to happen after every exit out of playmode and it linearly scales with the codemass!
CoreCLR finally allows us to have iteration time that should not become worse with code mass…
Will Unity CoreCLR support nullable types from C#? If yes:
- How would a nullable struct like Vector3? be serialized in the inspector?
- How would a non-nullable component work if the GameObject is destroyed? Would we see any console errors?
Cheers,
2 Likes
These are two different questions.
-
Nullable value types have been supported in Unity for a long time because they have been supported in C# since version 2. You can declare any value type as nullable, such as
int,bool, or evenVector3. However, they cannot be serialized. Unity’s serialization system does not support generics, with a few special case exceptions such asList<T>. Since nullable value types are implemented usingSystem.Nullable<T>, they are not supported by the serializer. The support of nullable value types has nothing to do with the movement to CoreCLR. -
For reference types, nullable annotations were introduced in C# 8. They can already be used in Unity with some additional setup. However, nullable reference types are only a static analysis feature intended to help prevent dereferencing potentially null variables.
In Unity,
nullis not always a truenull. Unity overloads the equality operator so that it also checks whether the underlying C++ object of a component has been destroyed. Because of this behavior, the analysis can run into the same kinds of issues that occur with other null checks, such as the null-conditional operator?..For that reason, the move to CoreCLR is unlikely to affect this behavior, aside from potentially removing the need for the extra setup currently required to enable nullable reference types.
4 Likes
Unity has been supporting generic serialization for a long time, if I’m not mistaken, since version 2020.1.
3 Likes
You’re correct, the issue is with the nullable struct. I think generic serialization handles custom structs and classes but may not fully support .NET types, since null could cause problems in the C++ serializer for primitive types. I could be wrong about the exact reason, though.
Simply speaking, we need a new serialization system to support this, and the matter is unrelated to CoreCLR.
They stated in the Product update on the GDC that they are working on improvements on the serialization system, and that they will support DICTIONARIES serialization.