There is no domain in .Net 10 so nothing to reload
Because we want to use modern technologies modern .Net and modern C# we need to agree with modern way to optimize development 
Unity already show pretty cool way to deal with new .Net code reloading systems
Way better than in pure .Net so we must be thankful
Thatās going to take some getting used to.
Not opposed to it at all. Just plenty of times Iāve ended up with some broken/unrecoverable static state that is easily fixed by initiating a domain reload.
Would be slightly inconvenient to have to close/open the editor every time to deal with that.
Finallyā¦ The CoreCLR is right at the corner.
I will use CoreCLR in Unity 6.8 when it became stable.
Not trying to be rude or sound pedantic, but you should look in depth into that design if you are having those problemsā¦ 
Itās just bugs that happen when working on a new system. Obviously I weed those bugs out and it stops being an issue.
Hi there! Iām sure this runtime port will bridge the gap with NuGet even further. Is an official NuGet Package Manager on the roadmap? I know we have āNuGetForUnity,ā but having it built directly into the engine would be a huge game-changer.
No, not part of our current plans.
Itās a bit disappointing to hear, but I truly believe that native NuGet support would be a massive productivity boost for many developers. I hope it can be considered for the future roadmap once the current migration settles down.
@jivalenzuela Great news! Waiting for CoreCLR in Unity for many years. Feels very excited.
My project āAI Game Developerā contains a dependency to System.Text.Json:10.0.3. I have that DLL in my manifest.json as a dependency for a while and it worked well until Unity 6.5, that brings the System.Text.Json:8.0.0 as part of the Unity Editor. It creates a compilation error.
Is it any way to have updated dependency manager that will handle such a conflict in the dependencies? And can we use NuGet as the source of the NuGet packages with CoreCLR?
I have the same, I like the feature but when something got into a buggy state, it can get quite annoying. It would be lovely if there was a (menu) option to manually trigger/force a domain reload.
Canāt wait until we have access to the latest .net functionality in Unity.
I was wondering if there are plans to place all the special attributes used to mitigate the absence of domain reload inside itās own nuget package or atleast .dll that can be included into other .net project.
We have a couple of shared .dlls that are independent on the main unity dllās and would like to keep it that way as much as possible. A little dll/nuget package just containing the import attributes or interfaces might be acceptable middleground. So that the shared code is fully unity compatible.
Iām planning to use CoreCLR for desktop platforms and stick with IL2CPP for mobile. I want to keep a unified codebase. Is it possible for both backend targets to run on .NET 10 (i.e., the modern .NET runtime) instead of having one target use .NET 10 and the other fall back to .NET Standard 2.1? Iām hoping to avoid maintaining two separate API surfaces.
Everything will be .Net 10
The only difference is GC
IL2CPP will continue to use Unity custom BohemGC instead of CLR GC
Yes, both will support the new C# features, so no need to maintain two separate APIās.
The main difference compared to the current pipeline is that IL2CPP is expected to keep using the older Unity Boehm Garbage Collector. In contrast, JIT compilation will use the .NET garbage collector. Some other features, such as the limitations on reflection emit will continue to have limitations with IL2CPP, the same as they do today. But both compilation types will support the new C# features and the Base Class Library.
@jivalenzuela Great stuff, so excited to see CoreCLR finally arriving!
For that Project Auditor tool you mentioned, will it also catch issues in managed plugins, UPM packages, Asset Store assets, etc.? I use a number of 3rd party libraries, and Iād like to be able to tell if their code is preventing me from using Fast Enter Play Mode rather than my code.
It works via Roslyn analyzer, so anything with a source code integration should get picked up. Weāre using it internally to flag 1st party package violations.
Weāre still in the process of testing and notifying Asset Store publishers to help them prepare for the transition - if you detect something you suspect is an issue feel free to let them (and us!) know
Good. It is a well cohesive decision 
.
And about Unity ECS? We might have some impact in existent projects?
great observation! I would like to add a bit on Fast Enter Playmode topic - moving to the CoreCLR VM is a fundamental shift which eliminates the ability to have a completely āfreshā start within Editor process. This is due to the fact that CoreCLR doesnāt support multiple AppDomains (there is only one) and it doesnāt support unloading from the process.
AssemblyLoadContext as a replacement for the code/assembly isolation allows us to simulate the fresh start, but it requires cooperation from the code - our Editor code and your game code.
Effectively with CoreCLR transition the requirements for the state reset are equivalent for both Code Reload and Fast Enter Playmode! Right now the plan is to hide most of the complexity of the Code Reload within the Editor itself, however to leverage more granular assembly reload in the future your code would need to also āreset stateā and break all references to unloading assemblies so that they can unload. So I would expect those requirements to converge at some point.
Fundamentally to achieve the best iteration times within Editor we need to allow keeping the data that does not change between states and make sure it is easy to do so for you 
.
Ofc reality is different and it may require more work, so we keep the option to be as much compatible with the old behavior as possible.
Thatās a lot of tech talk for people like me that just want to make game and not worry about setting up environments. The mention of using NuGet (or any package manager outside of Unity) makes me uneasy. The #1 reason I like Unity is because everything I need is included in the project.
I wonder if you could put some of this into lamens terms with screenshots of Unity settings, etc. to point out exactly what youāre referring to in several places.
Example: You mentioned āTarget Frameworkā and ā.NET Standard 2.1ā. The only setting I see in current player settings that mentions ā.NET Standard 2.1ā is the āApi Compatibility Levelā. Are you talking about the same thing? If so, this inconsistency can be very confusing. If not, screenshots are golden to help explain.
Will NUnit be upgraded from 3.5?