Unity Future .NET Development Status

Yea that certainly went off the rails quickly. Perils of posting in General, I suppose.


On-topic, I'm wondering if the .NET 7 AoT is on the radar to fit into (probably distant) future plans, as a possible new back end alongside Mono, CoreCLR and IL2CPP. Not sure if it has any serious limitations that would preclude its usage with Unity (and it doesn't seem to support many platforms right now). I know that Unity maintains its own runtime library for IL2CPP, so wondering if using .NET AoT would take that load off long term.

 

I've and others have asked that already because we were wondering the same thing. Essentially since it only supports relatively few platforms yet, they won't do it soon, but they will keep an eye on AOT's development.

 

Can't believe how there are such people even existing. Was a pain reading through the thread after the first few normal messages. Am definitely also of the opinion that source should be available for all. For the betterment of the Unity in general.

 

I mean y’all made me curious and WOW XD

my favorite :’)

 

Could all of this quote be added to the docs?

 

Oh, I already tried that too before and it allocates twice as much (or x4 more than IEnumerator)

Are any other callbacks awaited (like OnEnable, Start, OnDestroy etc)?

Hopefully what I said half year ago won't be true but so far UniTask seems to be better than Awaitable.

Spoiler

Requirement to await is pretty limiting. What if I want to add callback to let's say a button or an event? Or simply not await on purpose to continue my logic. For ex. let something run in the background, possibly on another thread? Often I do something like:

Code (CSharp):

1. void Start()
2. {
3.     // some logic
4.     LoadImage(myImg, image).Forget(); //don't await, it may take long time
5.     LoadImage(myImg2, image2).Forget();
6.     // continue
7. }
8. async UniTask LoadImage(string imagePath, Image image)
9. {
10.     var tex = await UWRAsync.GetTexture(imagePath);
11.     //obj may be destroyed before img loaded
12.     if (tex != null && image != null)
13.     {
14.         image.texture = tex;
15.     }
16. }

 

Not really as it allocates even if awaited in different place. Maybe some weird Func<Awaitable> would work but that's too cumbersome to use.

 

It's my understanding async void is not ever awaited so wouldn't using it on a unity update mean code in that update could overun into the next frame?

 

Thank you, that definitely helps and I can confirm it doesn't alloc and runs with same or a bit better performance than UniTask.

I don't see a reason why it couldn't be added to the core lib. I'll definitely use it with a name like AwaitFree. But who knows maybe Net core will land in 2023?

For anyone still wondering what we are talking about, here's how you use Awaiable without allocs (Foo renamed to AwaitFree):

Code (CSharp):

1. class BenchAsync : MonoBehaviour
2. {
3.     void Awake()
4.     {
5.         Work();
6.     }
7.  
8.     async AwaitFree Work()
9.     {
10.         await Awaitable.WaitForSecondsAsync(5);
11.         throw new Exception("test");
12.     }
13. }

To get exceptions in logs I recommend adding LogException:

Code (CSharp):

1. public void SetException(Exception e)
2. {
3.      Debug.LogException(e);
4.     _stateMachineBox.Dispose();
5.     _stateMachineBox = null;
6. }

 

There's no point using async Update, it's just a silly way to benchmark it.

async Task/Awaitable/UniTask Update

also aren't awaited.

 

This is not a Unity issue or limitation, this is a Windows limitation because... DOS. You need to explicitly enable long file paths in your registry. Set

HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled

to 1.

 

I know, and I have enabled it, and as far as I know every other tool I use has no issues with it (git, Visual Studio, Visual Studio Code, dotnet cli, Node.js, etc.) except for the Unity Editor. In the ticket I have opened the support could reproduce the problem and they said that they are investigating the problem further.

 

So this was from a while back, and though I still don't really agree with the black wizardry going on here I came across OpenSesame while I was looking through some UI packages from this guy (check 'm out he's fantastic). Anyway OpenSesame seems to do the whole "call private and internal API" thing: haven't tested it out and I'm not gonna, but thought I would share.

 

Seems like it changes the compiler for a .csproj and I suspect that it won't work... Remember, Unity currently uses it's own compiler right now.

I wouldn't use it anyways, as it exposes EVERYTHING! That's definitely not secure and definitely not something I would want, especially in a team enviroment!

 

The creator specifically made it unity compatible, it even lets you change the roslyn version

The creator made a Unity compatible version, it even lets you change the roslyn version https://github.com/mob-sakai/CSharpCompilerSettingsForUnity

 

Agreed, though I've always wanted to be able to add an attribute to a class/method like

[Nosey]

that would allow it to ignore access modifiers. Not something I'd use very often, but definitely can help avoid unsafe reflection code.

 

Yes exactly, fully agree. That or some compiler flag.
Every time i brought it up though people gave me S*** about it. Glad to know i'm not alone in a request like that.

 

@JoshPeterson
Happy holidays to you and the team!
Finally got a chance to watch the .net presentation and got even more excited about the changes this will bring with it. The double compile elimination might actually be the thing I'm most excited about from a workflow perspective, just as a sheer time/concentration saver. I tend to start spacing out when the unity bar pops up and it pops up a lot on my sad old laptop (sometimes for minutes at a time just for a simple code change), so it can be a bit of a challenge to stay in the zone when I'm trying to rapidly iterate on some new idea or a troublesome bug.
Really looking forward to diving into trying awaitable out as well, but haven't made the leap to the alpha yet.
Here's to hoping that you and the team have had good luck with making all your tests turn green. Any chance you can make me even more hyped and say if its looking good for 2023.2? I seem to remember seeing some mention of it being a possibility many pages ago, but that might be wishful thinking or me just misremembering something.

 

I've talked with one of the main devs of NativeAOT about your comment and he'd like you to explain why do you find it non production ready.

MacOS support has been already merged and will come with .Net 8, Android support is "trivial" to add (I even recall there being successful attempts of it already) and it also has been successfully ported for all major consoles (PlayStation, Xbox and Switch).

Addtionally, I've seen that the IL2CPP team is already trying to use NativeAOT for the IL2CPP tool.

 

I think he didn't mean that the NativeAOT itself are not production ready. But about unity experimental subbranch that replace its own AOT with NativeAOT are not production ready

 

Most of software isn't production ready for few months after the first "production ready" release. Pre-releases always get too small user base to find all the bugs. Recently that was my experience with Unity 2021.3 LTS and even whole Net.7 that seems less stable than Net.6.

Anyway for Net7 only these platforms are supported meaning it's definitely not production ready for anything else:

 

The issue tracking android is here and here's an example patch for it on top of .Net 7. The big restriction in contrast to Mono is that it doesn't support JNI interop.
The contact for console ports is available here.

 

https://issuetracker.unity3d.com/is...r-script-in-a-path-longer-than-260-characters
The issue tracker link is now active

 

Raise an issue on github, not in this thread

 

hmm you're right, will do

 

With .Net having dropped support for Windows 7 and 8.1, will Unity then also drop support for those when moving to it? Or does Unity maybe plan to readd support for those in their fork?

 

https://forum.unity.com/threads/inc...1-and-dropping-support-for-windows-7.1355966/

 

Thaks fo sharing! Good news and good plans

 

what's the word on more official NuGet support? manually managing lib/*/*.dll files for each package is kind of tedious

 

https://github.com/xoofx/UnityNuGet

 

Hi there, this is kinda unrelated (sorry) but I'm spearheading an initiative to improve the Unity gitignore, especially for beginners. There's a lot of smart(er than me) people in this thread and I would appreciate it if you would give it a look

https://forum.unity.com/threads/mak...re-easier-for-students-and-beginners.1385646/

 

Apparently iOS with NativeAOT is also in plans for .Net 8.

 

What is the current update on public beta with .net core?

 

@JoshPeterson Maybe you could talk a bit about what you're currently working on, what challenges you've faced and how you've resolved them?

I find this topic very interesting and I'd love to read as much information as possible. The more technical, the better
I've read everything xoofx wrote about .NET Core, GC, his Roslyn experiments and so on.

Thanks for being so active on the forums!

 

I am curious about how async/await can be improved.

 

Compared to UniTask there's some:
As for something different that both could use maybe alloc free CancellationToken(Source)? I know that C# ones can't be pooled as their state can't be reset to avoid race conditions.

This looks pretty heavy and really, what's the point?

 

Sorry if this is a stupid question, but by "alloc free", do you mean something that is natively allocated--unmanaged by the GC--or pre allocated?

 

Tbh anything more lightweight than CancellationTokenSource.

I've looked a bit more and it seems that CancellationTokenSource.TryReset was added in net6 (https://github.com/dotnet/runtime/issues/48492). It can reset not canceled source tokens. Prob could be used for MonoBehaviour.destroyCancellationToken as:

Code (CSharp):

1. static Stack<CancellationTokenSource> sourceTokensPool = new();
2. private CancellationTokenSource m_CancellationTokenSource;
3. public CancellationToken destroyCancellationToken
4. {
5.   get
6.   {
7.     if(m_CancellationTokenSource == null)
8.     {
9.       if(!sourceTokensPool.TryPop(out m_CancellationTokenSource))
10.         m_CancellationTokenSource = new CancellationTokenSource();
11.       OnCancellationTokenCreated();
12.     }
13.     return m_CancellationTokenSource.Token;
14.   }
15. }
16.  
17. public bool TryReturnDestroyCancellationToken()
18. {
19.   if(m_CancellationTokenSource.TryReset())
20.   {
21.     sourceTokensPool.Push(m_CancellationTokenSource);
22.     m_CancellationTokenSource = null;
23.     return true;
24.   }
25.   return false;
26. }

Then if you care about performance you could try to return token after a task:

Code (CSharp):

1. async Awaitable DownloadAndSetImage()
2. {
3.   try
4.   {
5.     Texture texture = await UnityWebRequestTexture.GetTexture(url, destroyCancellationToken); //when one day UWR has token :)
6.     TryReturnDestroyCancellationToken();
7.     myImage.image = texture;
8.   } catch (OperationCanceledException) {}
9. }

Btw, this post explains old method of pooling timeout tokens before net6 with CancelAfter(int.MaxValue) (https://stackoverflow.com/questions/60723430/allocation-free-timeout-on-task)

 

Whole "cancellation through exceptions" seem "wrong" to me. It seems fine for cancelling tasks based on user requests, but as soon as the cancellation can happen without user input and more frequently, it's problematic for me.

Some platforms have really slow exceptions and that can severely limit the throughput of such systems. I would much appreciate different cancellation, without involving exceptions. I've seen some approaches used in UniTask, it was not perfect, but it was a good direction IMO. I think we should focus more on that.

 

Async is really one of the most abused patterns in .Net and I would hate to see it become pervasive in Unity.

Async was designed to solve for IO. MS coerced it into being it's general api over everything parallel, and that's where async went off the rails generally in .Net. Resulting in the whole 'async all the way' paradigm.

And to fix the performance issues of async, they introduced ValueTask. Which is broken by design due to it's 'might or milght not block' design. So now you have tons of methods everywhere in .Net libraries that use this, and you have no idea if they block or not. And to make that even worse they put ValueTask on a ton of abstract classes.

what wikipedia doesn't tell you is that async as a concept really originated back with polling based architectures. I happened to work on some of the early implementations of these. Web scale needed a better way to handle hundreds to thousands of clients waiting on IO. And out of that futures/promises/async was born. It's a pretty good pattern for what it was designed for. The other route was event based popular in languages which only had green threads. Ie nodejs.

Unity's job system is more aligned with what works well in games. It needs a few more higher level abstractions like ergonomic parallel iterators to really round it out, but overall it fits better.

The rust ecosystems is a good example of how async is used mostly correctly for what it's actually good at. They start with an excellent set of abstractions that make it easy for the community to use the right tool for the job. Like one of the best thread pools out there. And then another library that uses that to add parallel iterators over all the common collections. And then a separate async library, that wait for it... is almost exclusively used by the community for IO related things.

There are certainly more people in the game industry that understand a lot of this then in the general .Net population. But there are a ton of people using Unity especially on the mobile side that really have no clue. I think it's really up to Unity to be a bit opinionated and push these people in the right direction. Nobody is doing them a service by making it easy for them to shoot themselves in the foot.