Unity Future .NET Development Status

Oh crap, I forgot about that :/

 

While that's cleaner, the IsNullOrX is more consistent with other APIs. And a static method would be more consistent with methods like Destroy(obj) and Instantiate(obj)

 

@DrummerB Static method like Destroy and Instantiate may only work in MonoBehaviour or else it need to be referenced with class name, and that would make inconsistence code when people start making helper class

Extension method can be copied anywhere

 

I'd prefer both:
1. Instance method (not extension method, maybe property if fast) gameObject.IsDestroyed() — like normal OOP.
2. Static method (not extension method) GameObject.IsNullOrDestroyed(gameObject) — like conventional string.IsNullOrEmpty(s).

No more implicit conversions, please.

3. Maybe also null-checking extension method gameObject.AliveOrDefault() which “converts” dead object to real null so it can then participate in null coalescing ?? or Elvis ?. — similar to FirstOrDefault() from Linq.

 

My understanding with AssemblyLoadContent after reading: https://docs.microsoft.com/en-us/dotnet/standard/assembly/unloadability - is that it only works if code is written to allow for it. So how would Unity Editor force this?

 

So, as far as I understand, they're pushing for "Hot Reload Everything" functionality in NET 6 starting with Preview 3 supporting ASP.NET and Blazor primarily: Announcing .NET 6 Preview 3 | .NET Blog (microsoft.com) . Right now it's just web pages but they expressed the desire to make this work for the live IL as well.

If this feature was expanded, would it be another avenue to achieving the required functionality? If so, what primarily would need to be added to it for it to work? Considering that Microsoft seems committed to helping Unity (at least in so far as expanding the influence of .NET for their own benefit), do you think they would be willing to put some weight behind making the .NET ecosystem work with Unity?

Also, your commitment to being transparent in this thread is being rewarded ; Unity Game Platform Details Plans for .NET and C# -- Visual Studio Magazine

 

Im not sure if the hot reload feature that ms provides with .NET 6 is suitable for the cases that Unity developers end up in. From the blog post they mention that not all code edits are supported, and it links to this page and it looks very very limiting. The .NET team would have to collaborate a lot with Unity on making the hot reload capabilities more open, not to mention that its aimed for blazor for now, so I feel like the effort to pull that off is better saved on shaping the assembly load contexts more as it seems more promising.

 

That's how it is now. Many .NET features evolved from a combination of desktop WinForms apps and older ASP technologies. Sure, there's much more in .NET now, including for game development. However, most features coming to .NET are not aimed at game development, they're aimed for business and enterprise. They also said their intention is to expand hot reload to support more than it does now. That's why I mentioned if Microsoft had any intentions of expanding their focus towards Unity in this regard.

Anywho, we'll just have to wait and see how it develops.

 

Here you go: https://docs.microsoft.com/en-us/uwp/api/Windows.Devices.Bluetooth

UWP APIs can normally be called from non-UWP applications¹. But, at least half a year ago, this is not possible with the Unity Editor or the Windows Standalone Build. And e.g. the Arduino Bluetooth Plugin² doesn't support BLE on Windows Standalone or in the Windows Unity Editor while it does support it on the UWP Build.
As workaround you can import dlls for BLE support. Exposing the above linked Bluetooth API would enable using Window's provided Bluetooth API without detours.

¹ https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-enhance
² https://assetstore.unity.com/packages/tools/input-management/arduino-bluetooth-plugin-98960

 

Happy to hear your guys exciting plan.
I installed unity 2021.2.a15,

Code (CSharp):

1. error CS0246: The type or namespace name 'Span<>' could not be found (are you missing a using directive or an assembly reference?)

span still not found. how to use "Span<>"?

 

Monoupgrade is not yet in the current alpha, I think that would be announced here.

 

@JoshPeterson I'm working on gRPC in .NET and a common user of gRPC are video games. Right now the Grpc.Net.Client library doesn't work on Unity because Unity doesn't support HTTP/2 with HttpClient.

Will the improvements you talked about include supporting SocketsHttpHandler and its HTTP/2 support? That will unlock gRPC usage on Unity.

 

Seeing a thread like this is really exciting me to work with Unity as a tool in the future. Would it be possible to start a thread on the above subject with the team working on it?
This is by far my biggest pet peeve and I hope I'm not alone on this.

Nevertheless, many thanks to your work! It is greatly Appreciated.

 

HTTP/2 support shipped with .NET Core 3.0 I believe. Preliminary support for HTTP/3 shipped with .NET 5.

 

U can use gRPC in unity by adding native libraries (at least on PC). I'm using the code first protobuf-net layer on top which handles the dependencies and wraps the entry points so I'm not sure if u need it or not but definitely possible.
You can find that project in github,

 

Does the mono update include updating the GC implementation being used? Or would that be a separate step?

 

@TieSKey There are plans to deprecate Grpc.Core which wraps the native implementation. Blog post with details: The future of gRPC in C# belongs to grpc-dotnet

That will leave grpc-dotnet as the gRPC client for .NET apps. For grpc-dotnet to work on Unity it will require HTTP/2 support in the underlying Unity implementation. That means it will need SocketsHttpHandler to be supported by Unity.

 

Oh, interesting. Well, it doesn't matter much for me but I can see how it's a serious impediment for companies looking to start a new project right now.

 

Sorry to get off topic for (hopefully) the last time.

I created said thread here and hope that you could get it the attention of some people from the Unity Team.
Also, to the users already commented on the '==' operator overload problem: please comment and discuss to give this thread some momentum and tell what I missed or should change over there.

Thank you!

 

I think I speak for everyone here that this is very much appreciated.

 

I've been curious, is it possible for Unity to make use of Native AOT (CoreRT) for native code gen purposes (alternative to IL2CPP)? dotnet/runtimelab at feature/NativeAOT (github.com)

The tl;dr is it basically takes the IL from RyuJIT and translates it to native code for the target platform. it's intended for usages where CoreCLR or other VMs aren't allowed/won't work.

This would be of course after Unity has moved to CoreCLR as a runtime.

 

@Peter77, changed your mind about the benchmarks?

 

Not really, but I can run the benchmark and post results if these changes are expected to affect performance. Would be interesting to see if and how much.

 

If there's no noticeable difference, then Unity seriously f♥♥♥ed up the fork update, because newer versions of Mono are indeed faster.

 

I guess we'll find out next weekend

 

C# hotloading in Source 2 by Facepunch https://twitter.com/garrynewman/status/1400850230678110214 (4th post)

 

It's nice that fp got hot reloading into gmod2 but I wonder what kind (it looks like regular EnC because html and their css files are also auto updating) because the one introduced by .NET 5 and 6 are based on EnC which have limitations as stated here roslyn/EnC-Supported-Edits.md at main · dotnet/roslyn (github.com). I still have doubts that the live hot reloading that MS provides is sufficient for the cases that programmers in Unity are used to and will expect. Though I could see it being a separate feature that can be enabled the same way that domain reload on play can be disabled, something that the Visual Studio package team will have to handle.

Also just an interesting fact, garry was given access to the source 2 repo by valve directly and fp ended up adding a lot of ux and later on c# support for end user modding in their own copy of source 2 for their gmod2 project (s&box)

 

Yes but they are "working to expand the set of supported edits". For me being able to just change method body would be really helpful.

I wish they'd do it for Unreal instead. Not sure if C# is the best idea for modding as it won't compile dynamically on all platforms but I guess they target Windows.

 

Does that mean that .NET Standard 2.1/Framework 4.8.x is also available? Or will that come later?

 

This is very exciting news! Looking forward to being able to remove System.Memory.dll from my projects.

 

@JoshPeterson I just want to say: thanks for keeping everyone here updated on your progress.
This stuff is super important to a lot of us, and with Unity being closed source there's often no way for users to get any development info. Your team is doing a great job in that regard.

 

On a side note, a more aggressive variant of this concept could be a c# interpreter in editor only (but compiled when built). This would allow for 0 second iteration times, I'm actually looking into this since I got lua integrated in one project and the development is stupid quick.

 

In editor you can do that with visual scripting, Bolt doesn't compile to c# but this does https://assetstore.unity.com/packages/tools/visual-scripting/unode-visual-scripting-101176.

I'm looking for interpreter that would also work in run-time on all platforms for modding but I don't think it exists.

 

@JoshPeterson that is great news!
Thank you and your team for all the work you are doing!

Assuming C#9 support won't make it into the 2021.2 release cycle (and thus not into 2021 LTS) would it still be possible to use C#9 function pointers in Unity?
I heard that C#9 function pointers don't require new/additional runtime support and thus should work in Unity.
However, I have yet to find out how one would use them in Unity.

 

Function pointers are already present in the current alpha. There was a bug which silently crashed the editor, but it is supossed to have been fixed since the issue was repported.
I did not have time to test the fix myself, though.

 

Free:
https://github.com/pjc0247/SlowSharp
https://github.com/pjc0247/UniScript (uses SlowSharp)

Commercial:
https://forum.unity.com/threads/released-roslyn-c-runtime-c-compiler.651505/page-5#post-6960836 (WIP)

(Haven't tested any of them yet, only bookmarked for later )

 

Also, this is even already supported in basic under .NET Core. It's used in Web Dev where we modify Route Controllers during live testing. The limitation right now is simple method edits but MS is expanding this function. Unity will eventually get this I assume, we'll see.

 

Its definitely better than it was before especially now that they arent compiling base every time. Hotreloading has opened my eyes and now restarting feels clunky