When we finally get .NET 4.6 / .NET Core 2.0 / .NET Standard 2.0 (with a preview of .NET 4.6 API in the next release 2017.1):
There is going to be some really important matters to solve:
Do Coroutines still make sense to exist? We will have “async” and “Task” though tasks create threads and cannot access Unity API that it’s not thread safe. Are we getting at some point more Unity API thread safe? We still can’t make things like create textures, readpixels and so on from another thread.
Yield instructions needs to be awaitable and be used like: await WaitForFixedUpdate();
As I wrote some months ago about System.Numerics: System.Numerics - Unity Engine - Unity Discussions Are you going to adopt this API? It makes sense to use it and avoid having a Unity specific API for this that it’s already available on Mono / .NET.
Serialization. We will have DataContract API available to use. Can Unity get advantage using this in some way?
I don’t remember more cases because as I’m so used to use .NET 2.0/3.5 API that Unity uses I don’t really know much changes from 2.0/3.5 > 4.6 API that could benefit Unity.
I mean, I think that Unity should adopt more and more API from .NET platform and mark as deprecated o change it’s own API in places that makes sense so it can put it’s resources in other tasks that are Unity specific.
That’s not true at all.
You can create your scheduler in any way you like, making it not spawn any threads if you want and always route all execution into the main thread…
Also all this new Task stuff is incredibly allocation heavy.
You want await WaitForFixedUpdate(); as a task? No way, people are getting all worked up about coroutines allocating a few bytes every iteration, and now you want to bomb us with 10x or 100x that much GC pressure per frame? whew…
There’s no way that stuff will make it into Unity in its current form.
Maybe people will come up with some new tricks to make more things into structs or maybe even somehow recycle Tasks…
edit:
It may not be clear from the way I worded things, but I’d very much like to be able to await stuff everywhere if it were somehow possible!
It’s just that video games need extreme performance.
You know how it is, a “short” 50ms pause to do some garbage collection is just completely unacceptable most of the time.
And as you know we developers have to constantly optimize against allocations just to make sure that doesn’t happen too often.
Also tasks have a a lot of overhead, there’s tons of code that’s getting executed behind the scenes to make it all work. So even if everything was allocation free, you’d definitely pay a few FPS to really make use of Tasks and await
You can await anything that is awaitable, not just Tasks. There’s no reason await WaitForFixedUpdate would need to allocate anything. In addition, there is ValueTask which does no heap allocation. GC and performance is not a good reason to use IEnumerator-based coroutines over awaitables/Tasks.
Don’t think of Task<T> as something necessarily thread-related. It’s rather readonly view for TaskCompletionSource<T>, making future/promise pair correspondence. You can combine them with current coroutine approach without creating new threads.
I am very impressed on the port work. Async / await works like a charm, especially with existing .net libraries.It will be great to see the UnityWebRequest behave the same and / or having the capability to use HttpRequest with WebGL and other platforms.
Note: Async / Await works perfectly on Desktop / Editor including System.Net.HttpClient. I like the fact that it can be used in the same way as WPF, Forms by decorating a method async.
Is it in the roadmap to provide that same level of support on Android, iOS and consoles? Will libraries System.Net.HttpClient become a first class citizen in Unity, and be able to be used across all platforms without changing your code base?
Will WebGl support async? and from my previous question if System.Net.HttpClient is not a first class citizen will Unity classes have async capability as welll as Iterators, so the can be used in conjunction with other .Net libraries?
A question from another performance paranoid developer who’s striping things out to try to prevent GC pauses…
What will the non-poolable memory implications of all of this? I’m aware there’s a non-allocating LINQ implementation. How close to a zero allocation implementation will likely be managed?
I’m trying to write UWP code in Unity3D by adding the Nuget Microsoft.NETCore.UniversalWindowsPlatform to my Unity3D Visual Studio project but it won’t let me. It keeps complaining that I cannot install Microsoft.NETCore.Jit 1.0.3 as my project targets .NET 4.6. How can I set Unity3D to target .NET Core 2.0?
It won’t be possible to target .NET Core 2.0 in Unity, as that is not really a .NET profile. We are working on support for .Net Standard 2.0 (which might be what you need), but it is not yet availble in Unity 2017.1. I’m not specifically familiar with Microsoft.NETCore.UniversalWindowsPlatform, but is there a version of it that works with .NET 4.6? If so, that might work.
I’m sorry for necroing, but cannot find some Unity official response to the questions in this thread: with the .NET 4.6 support, will the .NET stuff like async/await, Tasks, System.Net.HttpClient, etc. treated as first class citizens in Unity (maybe with some limitation on some platforms, like WebGL), or should we keep using the Unity stuff?
I am a newbie Unity developer coming from .NET world. I would like to use the .NET stuff because we have some code with that already. But I am not sure about some possible negative consequences.
Anything in .NET 4.6 should work correctly in Unity. However, often these things are not appropriate for game environments. async/await generates a lot of heap allocations, for example. So Unity coroutines may be a better option.
Thanks for the answer, Josh. So async/await is ok for such tasks like HTTP communication but should be cautions when doing some frequent small tasks.
AFAIK System.Net is not working in WebGL, at least. That’s what I miss in doc - some list platforms where some particular .NET API is supported (or maybe a list of excluded platforms, if it’s shorter.) Microsoft does it already in their doc.
One more problematic thing is System.Globalization.CultureInfo.CurrentCulture (CurrentUICulture, InstalledUICulture). Many folks report id does not work on iOS, Android, even Windows 7. E.g. see here , or here. Please, document if it’s supported, on which platforms it does work and the relation to Application.systemLanguage.
This is supported, and was recently corrected for some platforms. Check the latest releases of 2018.3, 2019.1, and 2019.2, but it should be working now.
But that’s exactly, what I expect in doc:
version 2018.3. supported on platforms …
version 2019.1. supported on platforms …
etc.
And not to check every platform (we plan to release on 5 platforms) by myself. That’s very time consuming.
The fact that System.Globalization.CultureInfo.CurrentCulture was not working was a bug, so we did not document that it does not work on certain platforms. I believe that we do have it working on all platforms now.
