Unity Future .NET Development Status

Is this video being reuploaded? I would rather listen to a version with bad audio than none

 

@Ferazel the Video is now marked as private - is there any chance to watch it still?

 

Be careful with this kind of assumption, you maybe not need it for now but who know in the future. For our game we heavily rely on this capability to adapt unity to our specific needs, and for us it's a major progress in the unity environment to have that. Before when you had an issue, it was not only hard to debug, but you also had to wait the unity team to fix it to move forward. These issues don't exist anymore. Also, with the profiler you can provide useful feedback to the unity team on bugs or potential improvement you find, by providing them a block of code to explicitly point the issue.

Beside that I think that you probably lose more time with domain reload than package compilation.
And I think that CoreCLR, .Net 6 will help on that, so that's a great news for us.
If you really have huge compilations timings you can split your code with asmdef, but the time you will get on the compilation might be lose on the domain reload (because you load more dll).
If after profiling, compilation is really the issue you can create a dll from a unity package since you have the source code and include it inside the projet as a plugin.
That would be an interesting profiling test to do, compare a unity with dll vs a classic unity with code compilation and see what are the timing differences, maybe it's huge maybe it's not, hard to tell without profiling it. But you lose the ability to setup define from player settings for the dlls, since they are already compiled, so there is a trade of here also.

I'm just so happy with the direction that unity is taking, about .Net6, CoreClr, new GC, csproj all of that was my dream, thank you for that. When you dig a bit, you realize how much keeping this mono would have been difficult, I believe that one aspect of the IL2CPP is to mitigate some performance issue with mono, maybe also burst?
Knowing that unity team aim to leave this fork away and stick to the actual .netstandard of microsoft is a great news, because it means that we can benefit directly from microsoft performance improvement of each new .net version (better gc, free alloc string interpolation...), while unity team can focus more on engine package.

Congrats for that unity team, modifying underlying tech is a difficult task, and it can be hard to justify this kind of changes because you don't get the shiny demo with incredible graphics, but for me this is as much as important if not more than the latest URP/HDRP demo, since all of us will benefit from it!

PS:
Here are some examples of packages we have modified so far:

• URP - UniversalRenderer inheritance, that enable us to have a main UniversalRenderer inherited by all of the other renderers in our scenes. With that we can have, a main renderer that define all the basics requirement for all scenes, and then inherit from it to specificaly add water support or whatever we want for each specific scene. That heavily simplifies the maintenance of renderers. Also really usefull for managing different quality settins like Low, Medium, High.
• URP - Camera stacking supporting individual post processing, which is a highly requested feature. With that we can easily setup post processing independantly for each camera in the stack.
• URP - Performances, be able to identify things that doesn't matter for us and remove them from the package using the profiler help us to gain some little performance back.
• TextMeshPro - Implement new font generation system, to have better font quality. We used this tech under the hood https://github.com/Chlumsky/msdfgen. The font atlas generation is also insanely fast with that compared to some of textmeshpro methods.

 

I'm not saying the use cases don't exist, I'm just saying that we need to have an opt-in mechanism for source available on a per package basis. That way you only pull in the sources you want to modify. And in regards to having source there for debugging, Rider supports debugging against compiled assemblies so I wouldn't say that makes this a necessity.

Also as it stands, you can freely modify package sources, but if you need to modify engine code (not available in packages) you are looking at a $100k fee for source access (don't quote me on this but I was informed by a team looking to add quantized mesh rendering and ray tracing/global illumination support to unity that they couldn't easily because of this pay wall).

 

It could be interresting if it is really a hot spot in compile time/reload time, and since they are planning on moving to coreclr, it's hard to tell if this will really worth the trouble to maintain, and distribute all the dlls and .so for release and debug for each configuration unity support. What could be an option, would be to compile the package only once on the first pull, and this is probably the case, so you pay the "price" of the compilation only twice, one for the debug build and one for the release. I don't know how it works until now, do they recompile all the package each time? I don't think so, but I don't know for sure.

I know that, and I could not agree more on that, but they maybe have a good reason to do so, because they are making huge engine changes with dots and .net tech. Maybe they consider that this it is not wise to open something constantly changing, and maybe they will open it later when they are done with these massive rewrite, who know. Packages are at least a way to have a bit of control, it's far from perfect indeed but this is a step in the right direction I think.

 

I have remembered that iOS 14 already allow JIT

Would that also be consider allow dynamic and Reflection.Emit and stop using AoT for publish unity?

 

It seems there exists a flag since iOS 14.2 that allows JIT compilation: https://developer.apple.com/documen.../entitlements/com_apple_security_cs_allow-jit

However the apple documentation also states: "The Hardened Runtime disallows this by default, because it creates a security risk"
So the question would be if they actually allow apps submitted with this flag - maybe Unity can ask Apple about this?

 

Does it, though?

As someone who's been porting the same ~30 lines of custom lightmapping / SH code from URP and RP Core through 3 major versions of Unity and manually needs to update, merge, and repackage the whole shebang each time a new URP package is made, I would really, really like this feature to be there in Unity's Package manager.

Package Development has disappeared into "experimental" / "no longer functional" Limbo, and even a simple system like overriding parts of a package or writing code that can access package-internal sources has been mostly fruitless for me.

Do you folks behind SRP even realize how hard it is to write a custom RenderPass (even as basic a behaviour as RenderObjects) that is not shipping with its own fork of the RP? Some of the most fundamental fields are made internal or private, and at this point I'm starting to assume it's malice. It takes considerable skill and planning to make a scriptable render pipeline so fundamentally unscriptable.

I would love to be able to inject C# and Shaderlab code somehow into this process so when I want an additional uniform with my Input.hlsl, I don't have to go fork the Core RP AND the Universal RP to add a Handful of Uniforms for custom interpretation of Lightmaps. (like, an optional include for Input.hlsl that can live in my assets... but I digress, that's not about C# or .NET, but it sure is about packages)

 

Because there is no security risk of any kind with AOT, right Apple?

 

It just said: “creates a security risk with JIT compilation”, not: “no security risks with AOT compilation”.

 

Let's not derail the thread, please

 

I'm having some issues with IAsyncEnumerable.ToObservable() in Unity where the observable times out, I can only assume that there was changes made in the runtime to support this which doesn't work through netstandard2.1 compatibility as this works fine in a normal net6.0 project. System.Linq.Async does reference newer versions of the runtime so I'm guessing I will just have to wait for net6.0 or higher support in Unity to do this.

 

Any news about the GDC video reupload? if not does somebody have a link to or downloaded the old one?

 

Yeah it would've been nicer to mark it as unlisted instead of private for as long as the fixed version isn't available yet.

 

I actually disagree. Usually NuGet projects are available on Github. If I want to change source I add them as git submodules or clone/paste. UPM packages (especially these provided by Unity) in most cases aren't on Github. Modifying them is a nightmare to maintain.

The only proper way to modify UPM packages is to create repos out of them. Someone even started doing it here https://github.com/needle-mirror .

You have to do a lot more to be able to merge updates.

I once released a bug that prevented new players of making accounts because of small little change that I forgot to add again to updated package. After that I ended up changing whole UI to not relay on my modification.

 

Very long thread here - I'm just trying to figure out "when" (ETA) Unity will support .NET 6.0? Our game runs in .NET 6.0, on Urho.NET currently, and we're planning to port it to Unity, and are hoping that we don't have to downgrade our game logic from .NET 6.0 to something lesser.

So for sake of planning, we're looking for the ETA on Unity3D supporting integration with .NET 6.0-based source code, and/or DLL's. What's the latest ETA (date range)?

 

info:

it is most likely to get a very early preview with late .net 7 or .net 8

 

The video is available again.

 

This look very promising. Are all of these already available in 2022.2alpha?

 

No, watch the video for a timeline.

 

It said completed here at 2022 so I expect that `alpha` version is already `future`

 

Nah, ilt can be anywhere between now and the thermal death of the universe
Jokes aside, I expect we'll see the CoreCLR player in 2023 and editor in 2024.

 

CoreCLR in Unity Player and Editor is best news in several years. Finally we'll get a modern GC, proper debugging experience, high performance JIT with SIMD support and much more. The csproj format instead of asmdef is also great, because it allows us to fully utilize any kind of MSBuild tooling.

Can't wait for the first alpha version!

 

28:00 about dlls in UPM packages. Isn't Nuget resolution going to fix this @JoshPeterson? Package would have Nuget reference instead of containing dll directly.


Early feedback about:


Could AwaitableCoroutine be renamed to something shorter? I like UniTask but that collides with UniTask library so maybe UTask or something similar.

 

I'm probably misunderstanding, but judging by the roadmap slide, only Unity editor will get full support for .NET 6/7, while players will stick with .NET Standard 2.1 (and even then only standalone players). Does that mean, that even at the point when Unity Editor will move to CoreCLR, we still won't be able to use all the .NET 6/7 APIs with mobiles, consoles, etc?

 

You got it backwards, kind of. All targets including the editor will support the latest APIs. Players will support the new runtime first, and editor will later (which can support the new APIs on the mono runtime). As for which players will support it, only platforms that allow JIT, same as the current mono, otherwise IL2CPP will still be required.

 

Thank you for the clarification. I hoped for full .NET support on all player platforms (assuming .NET runtime would be "replicated" under IL2CPP). Not the ASP/forms stuff, of course, but APIs like System.Text.Json (which is only available in .NET 5 and later) in my opinion would be really nice to have.

 

Yes, all that will be available on all platforms. The API surface is not the same as the runtime.

[Edit] Except threads and thread-related APIs which still are not supported in WebGL, but compile just fine and fail at runtime.

 

Not really, I guess it's slower but works.

 

Regarding newer runtimes...has anyone at Unity been following the state of deterministic float operations in .NET? There's a few different issues open about it, mainly

• Update the runtime to have deterministic floating-point to integer conversions #61885
  
• Updating the x64 casting behavior to be IEEE 754 compliant and to use saturation for overflow #61761

Determinism in Unity is a big topic, but if float operations are to IEEE spec in the runtime would it then transfer over to Unity (ignoring all the native code in Unity of course, and the fact that System.Math uses intrinsics and so on)?

 

I'm glad Unity will not use Conservative stack scanning GC mode, but normal mode. Finally leaving Beohm GC (with ALL it's drawbacks) in the past and moving forward.
https://github.com/dotnet/runtime/issues/61919

@JoshPeterson Could you explain a bit what switch to CoreCLR means for Domain reloads in Editor?
Will this use AssemblyLoadContext instead?
Or will you tear down .NET runtime and initialize it again from scratch?

I'm really looking forward to Edit-and-continue support mentioned in the GDC Talk. Any feature with potential to reduce time between making changes to code and seeing them in action is great.

EDIT:
Also using AssemblyLoadContext for modding sounds great! Finally a way to switch mods without restarting the game (and you can even tell whether the mod successfully unloaded or not!).

 

Could you share any updates on this issue @JoshPeterson?

 

@JoshPeterson if the plan is to replace Coroutines with async programming, where can I voice my concerns with Coroutines so that these may hopefully be addressed by your team as they're working on this?

I have a few:
- Problem: Coroutines don't work on disabled objects. Wish: Async should work on disabled or destroyed objects. Calls to gameObject returning null in an async OnDestroy() method may be expected and should be supported. Motivation: Flexibilty.
- Problem: Coroutines only work with MonoBehaviours. Wish: Async works anywhere, e.g. a static manager. Motivation: Allows for cleaner code practices, no injection of "dummy objects" required.
- Problem: Coroutines can't be started from a reference to a MonoBehaviour. Wish: Async calls can (I figure this one will simply 'be' supported through access modifiers and the way async already works). Motivation: Flexibility.

Definitely happy and excited for this change to come to Unity! I hope the API gets shorter and clearer, AwaitableCoroutine is already kindof an outdated name if the whole point is to replace Coroutines.

 

I really, really, really prefer coroutines to async for things that are supposed to run over several frames that interact with components in the scene.

The ability to take a handle to the coroutine from the outside, and then kill it from the outside when necessary is incredibly nice. The CancellationToken stuff is an utter mess, but then again asynchronous programming requires you to introduce some mess. Coroutines are not asynchronous, and taking on the cost of an async pattern to a fundamentally synchronous problem is very expensive for no reason.

If Unity introduces some way of getting a handle to a Task in a way that allows us to stop running the Task without having to inject an object into the task that has to be checked after every await, that'd possibly make it useful as a general purpose coroutine replacement. Maybe.

 

That'd be great. Hopefully it'll be clarified in the upcoming blog post.

That's an opt-in package, while I've meant built-in library, which is only available in .NET 5 and later: https://docs.microsoft.com/en-us/do...stem-text-json-migrate-from-newtonsoft-how-to

If I got it right, they're not planning to remove the coroutines, but add an async API layer or something, similar to how addressable operations allow to choose between callbacks, coroutines or awaiting a task (but without the additional allocation overhead).

 

I think what you want is actually reactivex

 

Async functions already work exactly like that. Async state machines have no concept of gameobject ownership, they just store an internal reference to

this

, which would be your MonoBehaviour, and will continue when the awaiter tells it to, whether that object is destroyed or not.

 

In an early iteration of ProtoPromise, I actually supported storing a reference to a pending Promise object and directly canceling it. In practice, I found that to be extremely clunky and error prone, and you couldn't cancel chained operations deeper in the call stack. I ended up replacing that functionality with cancelation tokens to clean up the whole process.

Stopping chained Coroutines is a huge mess itself. Stopping an outer coroutine does not stop an inner coroutine that was yield returned inside it.

[Edit] Also, async functions cannot be stopped externally, as any finally clauses would never be ran. Cancelation tokens are required for any disposable objects to be properly cleaned up. There is no way for Unity to get around this limitation without adding the functionality to the C# compiler itself... And as it so happens, I believe you have the same problem with Coroutines.

 

I also want to voice a concern about "async void" shown in the examples from GDC, this is a bad practice in regular .NET and will cause problems. Please don't encourage this, use Task or whatever you decide to be the Unity equivalent.

 

Check this clarification on async void: https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/issues/15#issuecomment-432510102

In summary, a properly implemented "SynchrozationContext" for a UI framework (or in this case Unity) will not cause a crash.

I think this also relates to the misconception that @Baste mentioned above. The Unity synchronization context can make the async/await pattern work as predictable as coroutines. When mentioned above that async/await is "asynchronous", it is likely intuitively referring to the behavior of async/await when called with .ConfigureAwait(false), or on a framework without a synchronization context like ASP.NET Core.