Unity Future .NET Development Status

Now you have just made all code more verbose and clunky, and broken backwards compatibility. I don't quite know what you gained?

 

Another fun thing I recently came across, if all you have is an interface reference, you have to cast it to component to check it for null

Code (csharp):

1.  
2. IMyInterface? thing = GetThingSomehow();
3. Destroy(objectThatHasThing);
4. if (thing == null) ThisIsNotNull();
5. if (thing is Component component && component == null) ItsActuallyNull();
6.  

 

Ah, no I don't mean to replace GameObject, but to introduce a wrapper that does not do fake null for _its_ GameObject reference stored in actualObject. Since the wrapper is something the engine gives you it can just set the reference to true null on destruction of the GameObject/Behaviour.

 

Hey, maybe I'm asking something utterly stupid but, is there a definite technical reason why .NET doesn't allow overriding the implementation of the

is null 

/ coalescence operators?

If there's not, maybe Unity could 'just' talk Microsoft into allowing it? that way Unity can continue with its unique setup in a way consistent with the modern C# landscape

 

UnityEngine.Object is a wrapper already: it contains an internal reference to a C++ object, which is the thing that can be actually destroyed. What the null comparison and bool cast operators do is ask the C++ side if that reference is still valid (not null and not marked for destruction).

In terms of nullability, UnityEngine.Object types are similar to working with IDisposable types: just checking if the reference is null is not enough and you still need to deal with the possibility of references to disposed objects

 

The way the custom null check works is by overriding the comparison operator for UnityEngine.Object to other objects.

is null as well as ?? _cannot_ fall back on these operators as they are fundamentally doing something different, namely checking for true null.

Essentially the object is not true null and only due to the comparison operator returns true when compared to null. Its just a completely different concept. Is null as well as ?? are language keywords. Its the same as asking dotnet to implement custom switch statements for types.

In general its actually _good_ that you have a way to easily check for true null using "is null". The problem I see right now is that for example GetComponent returns a non-null value in Editor in weird circumstances.

 

In my opinion the Unity "fake" null and Nullable Reference Annotations are two different things.
But even if you thing about it as same things then you will find that it does not matter.


1. Unity "fake" null

The Unity "fake" null object is a real C# object, which does not have a reference to an internal native C++ object.
So you can access all members defined in C# (own script code) but you cannot access members which defines Unity (MissingReferenceException will be thrown).
Unity overloads operators `==` and `!=`. The result of these operators depends on existence the native C++ object.

If the native C++ object does not exist then there is not a reason to use the real C# object. For you, there is not difference between the real null and the Unity "fake" null object.
This is the reason why Unity overloads these operators.


2. Nullable Reference Annotations

See the declaration `public Component? GetComponent(Type type);`.

The declaration says that the `GetComponent` method returns null (real null) or a object which is instance of the type. The documentation says exactly that.
If you call the method with a type which the GameObject does not have, then the method returns null (real null) else the method returns a C# object.
The declaration says nothing about overloading operators of the object. Even if you overload operators that (object == null -> true) and (object != null -> true),
which is absolute nonsense, the contract `Component?` is still valid because the returned object is instance of the Component!
No matter if the object has or does not have a reference to a native C++ object.


3. Usage

Code (CSharp):

1. SampleMonoBehaviour com = null;
2.  
3. Debug.Log("GetComponent");
4. com = GetComponent<SampleMonoBehaviour>();
5.  
6. Debug.Log($"com == null: {com == null}"); // False
7. Debug.Log($"com != null: {com != null}"); // True
8. Debug.Log($"com is object: {com is object}"); // True
9.  
10. Debug.Log("Destroy");
11. DestroyImmediate(com);
12.  
13. Debug.Log($"com == null: {com == null}"); // True
14. Debug.Log($"com != null: {com != null}"); // False
15. Debug.Log($"com is object: {com is object}"); // True because com is the Unity "fake" null
16. // If you call com.GetComponent<Transform>() then MissingReferenceException will be thrown.
17.  
18. Debug.Log("Null");
19. com = null;
20.  
21. Debug.Log($"com == null: {com == null}"); // True
22. Debug.Log($"com != null: {com != null}"); // False
23. Debug.Log($"com is object: {com is object}"); // False because com is the real null
24. // If you call com.GetComponent<Transform>() then NullReferenceException will be thrown. Note difference with the Unity "fake" null.
25.  
26. Debug.Log("GetComponent");
27. com = GetComponent<SampleMonoBehaviour>();
28.  
29. Debug.Log($"com == null: {com == null}"); // True
30. Debug.Log($"com != null: {com != null}"); // False
31. Debug.Log($"com is object: {com is object}"); // False because com is the real null

As you can see, if the real C# object does not have a reference to a native C++ object then the `GetComponent` method returns real null.

Edit: If call GetComponent<MeshCollider>() on a Gameobject that does not have one attached _in the editor_ that is the important part. The methot returns the Unity "fake" null object!

But even the Unity "fake" null object will be returned, you still write if (com != null) ... and the result will be same.

 

If the returned object (non null) get's destroyed before you access it, and you then check with coaelescing or is null (because with nullable annotations you CAN NOT ask anyone to use the operator overloads for null checking), you will get exceptions.

 

Minor side note: TryGetComponent will never give you a fake null object, so you can use that to implement this method without paying the cost of an allocation in the editor.

 

yeah, TryGetComponent is different. That's why we don't have a custom 'override' for that one. Only for GetComponent

 

Hard to believe, I think majority of unity users aren't aware and aren't interested in being aware in something that pretty much only us try hards are interested. I'm more for an optional amsdef advocate for this because being backwards compatible with majority is more important to unity. And it also allows this behaviour to become different for people who need this and would take advantage of it.

 

Could you please give a code, where Component.GetComponent<T>() returns the Unity "fake" object? My test does not prove that. See my fifth post back.

Thanks

 

Just run GetComponent<MeshCollider>() on a Gameobject that does not have one attached _in the editor_ that is the important part.

Code (CSharp):

1. var nothing = GetComponent<MeshCollider>();
2. Debug.Log(nothing is null);
3. Debug.Log(nothing is not null);
4. Debug.Log(nothing == null);
5. Debug.Log(nothing != null);

And there is a difference between runtime and editor for the results of those debug statements.

 

If you ask me, users not being aware of it is part of the problem. They can run into the issues and either not understand what is wrong, or worse: not even notice the issue because they didn't hit the case during testing.

It's a fundamental design issue that makes a set of C# language features unsafe to use without any obvious explanation for why, and further separates the Unity development experience from the rest of the .NET ecosystem.

"x == null" to check for a destroyed object was never a good idea, it's counter to how null references function in C# and is not an obvious "is this destroyed" check unless you are already familiar with Unity -- other APIs rightfully do not do this because it's confusing.

I definitely understand the backwards compatibility argument but it doesn't need to be a hard break immediately, that's what a deprecation process is for.

 

Code (CSharp):

1.  
2. private void NullableFailure()
3.     {
4.         TestComponent? comp = GetComponent<TestComponent>();
5.  
6.         if (comp is not null)
7.         {
8.             comp.MyIntProperty = 10;
9.         }
10.  
11.         DoOtherStuff(comp);
12.  
13.         if (comp is null)
14.         {
15.             ThisBreaksNow();
16.         }
17.  
18.         return comp ?? ComponentInCaseOfNull; // this also breaks
19.  
20.         void DoOtherStuff(TestComponent? component)
21.         {
22.             Destroy(component);
23.         }
24.     }
25.  

 

It seems that the "is" language construct does not use the operator overloading. This is the same problem as the "??" operator and the construct cannot be used.

 

Exactly. It cannot be used as long as there is a custom operator overload for unity objects. That inherently makes nullability annotations pointless

 

It also would not break backwards compatibility. x == null would point to the system.object operator which also still return the expected boolean value

 

the operator overload breaks:
??
??=
unityObject?.Method() // ? suffix
is null
is not null
pattern matching

and this list will only get longer with new c# version releases

 

I disagree because the `Component?` contract is not broken. Moreover, it is clear that no other check except `com == null` or `(bool)com` can be used. It does not matter if the method returns true or fake null. In some cases returns true null in some returns fake null.

 

Then the annotation is pointless because that only matters for true null. If i still have to use == to check for null then having the annotation provides 0 benefit

 

Well, maybe the nullable effect is questionable with this method if you want to be notified that you have to check if the return value is null or not. I think a programmer should be notified about null check because true null can be returned! The programmer must use == when the nullable annotation is or is not and the nullable annotation does not change that.

But one method is not the whole Unity. Nullable annotations are not for one method.

The ==, is, ?? problem is for another discussion.

Edit:
If a method returns null (true null) then the method should say it. The GetComponent method says it in it's API description. And there are situations where real null is returned. If you do not check null and call some member the NullReferenceException will be thrown. The fact that Unity limits the use of null check does not change the fact that a null check is needed.
Declaration information (language construct) is always better then documentation information.
Nullable annotation warnings are optional.

 

Yea ultimately I agree, anyone writing c# should assume the most basic c# logic is the way youd expect to without having to guess or research. But backwards compatability would take priority for me so the deprecation process is pretty spot on. Unity should make an analyzer that points at places where a seemingly vanilla null check should be replaced with an `IsDestroyed` check instead (since not all cases of `is null` or `?` or `??` break). Also isn't there already a thread for this specific topic?

 

Is there a use case for this behavior? I mean, if is required the fake null object when the component has not been attached to the game object.

 

Just to chime in:
Whether or not the nullability behavior should change in unity, adding nullable annotations to the current API surface should be done. Just to stay with the current example: GetComponent<T> (and other overloads) should return T? . It does not matter which way you want to check for null the returned value should be checked for null (if you care about catching problems around objects being null).
Now the other problem is already solved: how do you enforce proper null checks in unity? The tooling needs to be better. Right now, the Microsoft.Unity.Analyzers analyzer (which is included by default when using the visual studio (code) package) already has warnings if you use unsupported nullability features with objects inheriting from UnityEngine.Object. Just as an example the other day I had an issue with this, reported it and it will be fixed in the next release https://github.com/microsoft/Microsoft.Unity.Analyzers/issues/204 . Also the Rider (resharper) unity plugin also warns you when use do something you should not. The problem is that analyzers like this should be provided by unity and not by third parties.

What I have encountered multiple times, which is a far worse consequence of the current null behavior: when you pass a component as an interface nothing will hint at using bad nullability check.

 

Obviously this would be waaaaay down the line, but once you have current .NET (6, 7, 8 or whatever) support and CoreCLR, it would be really cool if you could implement razor over your markup/stylesheet (UXML/USS) UI toolkit to effectively give us Blazor for Unity UI. This would be a game changer for most C# web developers working in the .NET ecosystem today.

 

If I'm not mistaken GDC is over. We still missing the blog post?
I despise this "event exclusibty" bullshit with all my soul. One of the many ugly faces of this industry.

Elaborate how is this possible with classic approach of single logic (single playerloop thread) thread? How do you see component getting destroyed right after a call to `GetComponent()` and you immediate nullcheck on the same stack frame? It can't be GC, because, even if skip everything else, we already have reference on the current loaded stack frame.

 

Let me highlight the quote for you.

 

Doesn't need to be razor. Can be a proprietary MVVM/MVC solution too.

 

Any news on this? Possibility of it coming to Unity 2022.1? Gonna have to resolve to hacky workarounds until covariance is supported.

 

This is a prime example for where source generators are a massive boon. The whole Razor ecosystem is scheduled to move towards them at some future point to massively reduce tooling required. You can already read in arbitrary files and create code behind for them, so this is just another step in that direction.

We already have some source generators working magic for us in the background (for various features), they aren't yet at the point where they are fit for public consumption but we might release a few at some point in the future that can help when working with Uxml files.

The main "blocker" right now is that uxml files aren't added to the AdditionalFiles but instead are added to the None group therefore you need to manually add them for them to be available to source generators. Making that configurable would make it easier to develop source generators for general uxml files.

 

Do you have any plan to integrate Unity with MAUI in .net 6?
I want to use Unity in part of my program
Since MAUI is still under development
Can you work with the MAUI team to enable the integration and use of Unity and its models in MAUI apps?

 

One has to keep in mind that unity is a c++ engine hosting .NET and not a standalone .NET application. The only thing I can think of is a MAUI application that uses Unity as a library.
However, MAUI only works on Windows, macOS, iOS and Android, no Linux and other platforms.
I also find it a bit difficult to implement MAUI in Unity, MAUI also manages windows and message loops and rendering, which would then collide with Unity and generate a lot of overhead.

The same would also apply to razor, for which Unity would need an integrated browser, again with overhead and larger installation sizes.

These platforms are also designed for websites or apps, not games. The performance could be excellent for their original use cases, but may not be sufficient for games (for example: GUI rendering 10ms in web or apps would be quite fast, but much too slow in games)

 

In the last 4 years I have been working as a unity developer but, I have not made a single game - I create business applications with it. Having a more competent UI system would be really beneficial for a lot of people. Also keep in mind that blazor is not browser only- the blazor renderimg engine could be used to outpu ugui element not just html

 

I am trying to use gRPC for .NET with Unity 2021.2.11f1.
After incorporating it by trial and error and communicating, an error occurred related to "HTTP / 2 Connection Preface".
When I checked the communication contents with Wireshark, it was not communicated with HTTP/2.

It seems that you should use SocketsHttpHandler instead of HttpClientHandler, but it doesn't seem to be implemented in Unity 2021.2.11f1?
It did not exist in netstandard (2.1.0.0) in the Visual Studio assembly browser.

Does that mean that Unity's SocketsHttpHandler implementation isn't in time?

 

Thanks for the reply.
Today, the design and building of applications have expanded and more 3D models are needed.
Currently with webview2 we can render and run Blazor in MAUI
This is a great option for web developers.
Which can use both html css or XAML for UI and C# or js with access to operating system api for logic

I do not know if it is possible to get WebGL output from Unity and run it in WebView2 or not?

On the other hand, Unity is limited in accessing the operating system api. While xamarin/maui is more advanced
Using Unity in MAUI can complement each other.

And keep in mind that Unity is not just for the game
Working the Unity team with the MAUI team can do amazing things.

(Tizen support will be added soon https://github.com/dotnet/maui/pull/2360
and Linux support is also set to be added by the community https://github.com/jsuarezruiz/maui-linux)

 

WebView2 is simple a wrapper for the OS buld-in browser, Edge on Windows, Safari on macOS/iOS. Theoretically it should be possible to display a webGL build in WebView2.

MAUI WebView was mainly made to make web technologies usable for native apps, and that's lighter than e.g. electron.Unity is already natively available for all platforms. And a MAUI integration with the way via webGL would not be the right way, maybe more similar to the current "Unity as Library", that would be more efficient.

But that would not work in any of the variants that you could use the models and API from Unity in MAUI and vice versa. Both applications ran independently and would only communicate with each other via an API interface.

 

After all, SocketsHttpHandler is not implemented.
Currently, HTTP/2 communication is not possible with gRPC for .NET.
Thank you.

 

@runner78
Yes, running it as a library can give us more access via API interface.
@JoshPeterson
What is your view on integrating and using Unity in MAUI in .net6/7/8 ?
This can be a huge option for .NET developers

 

I am a bigger fan of adopting widely used technology...why reinvent the wheel kind of thing. I don't think we need any more proprietary tech until everything else is sorted (CoreCLR, NET 6/7). And if past proprietary tech is anything to go off, the docs will be non-existent vs just going with the razor engine most people using C# have at least some knowledge of. As well as fitting with the general idea of bringing web devs into Unity.

I'm not sure when this was last brought up, but it would be super nice if Unity would just give us control of our project files instead of generating on every rebuild. They should be able to achieve anything the current generation achieves by just attaching some build targets to a csproj file that we provide.

Speaking from experience, the Unity workflow of throwing any dll's into Assets/ may have been cool before nuget, but it aged like milk in the sun. I don't care if this is an opt-in feature, but Unity can't really say they are part of the whole "One .NET" initiative when they don't even support the ecosystem used in the rest of .NET.

All my web C# dev friends that have been interested in Unity instantly recoil when the realise they can't pull in their bread and butter nuget packages along with dependency injection. I've been using MSBuild4Unity which brings things closer, it's just sad that products like this even have to exist.

Also multiple assembly errors on using packages that come in the editor is a big pain point, that's kind of a Unity implementation detail that we shouldn't know or care less about. Funnily enough using nuget for engine/editor code would solve this too, but guess I'm missing something.

I don't think it's too much to ask that I can create and maintain my own solution/projects, I'm a big boy.

 

Actually this has already been done fairly easily, take a look at Xamarin blazor bindings/MAUI blazor bindings. they effectively just mock a browser window and present it as a native component. Which is basically the same as the Unity UI toolkit if I'm not mistaken.

 

You have to use Grpc.Client.Web on the client and use Grpc.AspNetCore.Web on the server, this will allow the client to communicate over HTTP 1 which is needed in Unity. I just finished getting this working in a brand new 2022.1.0b13 project. I would recommend using a version of Unity that supports netstandard2.1 as this makes compatibility waaaaaaaaay easier. I'm not even entirely sure you would get it to run in netstandard2.0.

Also worth noting my server is a separate .NET 6 API that I just added a step at the end of every Unity build to also run MSBuild on the server.

 

Thank you.
I'm already doing HTTP/2 communication with gRPC C# core-library and gRPC-Go, and gRPC C# core-library doesn't support mac IL2CPP and console games, so I'm investigating the transition to gRPC for .NET.
I wait for Unity update.

 

As far as I know, the UI Toolkit doesn't. It renders the UI with meshes and shaders within the Unity graphics API. Otherwise Worldspace UI would be difficult in the future, since each Worldspace UI would then be an independent browser window/tab.

MAUI mocks no browser window, WebView2 is a browser window (in contrast to electron, which includes chromium, MAUI uses the OS integrated browser engine)

There is an experimental native Blazor binding, but as far as I know it's just a combination of Xamarin.Forms and the Blazor syntax, but as far as I know it's not part of the first MAUI release. So MAUI with Blazor needs MAUI itself, ASP.NET for the internal Blazor hosting and the external browser for the rendering, totally unsuitable for a GAME ui in my opinion.