Unity Future .NET Development Status

Engine sources are a purchaseable addon once you have Pro. The reasoning is probably that you would already be a paying customer with a support plan. You're not unnecessarily paying for source access with just a Pro subscription, so the general idea of "people who buy pro package" is irrelevant here.

 

There is not much "C#" side to Unity itself, that comes (almost entirely I think) in the form of packages.

The good news is that, on some of these packages, you can actually create your own PRs. At least as far as I'm aware, there's nothing against it. If you go to Unity's Repository Page and find the package you want to modify (basically anything that starts with com.unity), Fork it, embed it, and modify it, you can submit a PR with your changes and it should get reviewed.

The problem with this approach may be that there is no communication from Unity if this is actually supported, humored, or even accepted, but it works for Cinemachine so if you ask me it's really up to the package moderators with no internal policy saying no.

Edit:
And as @Kamyker stated some might just be downright stale bread.

 

I'm really sorry that you're displeased, but that part would be a deal breaker for me too. I fully agree with the .net team here and would rather stick with 'limited' source generators than to compromise intellisense performance.

Less hostility would be appreciated though. We're all hard working creatives wanting to better the industry.

 

My apologies. Yesterday was a rough day for me, due to stuff going on at work that was unrelated to this, and I reacted poorly to Mindstyler.

I should have simply ignored him. Everyone knows the old maxim, "don't feed the trolls." But I disregarded it yesterday. That's on me. I just hope you don't think that how I behaved on one bad day is who I am.

 

Not true, most of packages aren't on github or aren't updated anymore like https://github.com/Unity-Technologies/uGUI

Even ECS (mentioned in prev post https://unity.virtualeventsite.com/...-why-source-access-to-dots-is-a-game-changer/ ) isn't on github, imagine how much Stunlock could contribute if it was!

 

I have a question to the Unity Team...

The current implementation of the CoreCLR GC is using GCHandles right?

So if it is possible in the future to have Objects on the C# Side with no consequences can we then have common types like transform, name, tag, etc. directly built-in to the Managed Side of the engine so that unnecessary calls to the unmanaged side are avoided and performance is achieved?

Sorry if I am being dumb in advance

 

Are name and tag their own types? AFAIK name is just a string, and it looks like tag is simply a number. (Though some of the code related to tag management is probably implemented on the C++ side.)

 

No, no they AREN'T their own types but they're extern, meaning these types need to be taken from the C++ Side.
This will call the C++ Side unnecessarily and is way slower than you'd expect. That's how I understood Unity anyways...

So a tag is still a number and a name is a string, but it is returned from the engines side where smth like name probably wont be used, while we could use it extensively.

 

Yeah, having commonly-used stuff on the unmanaged side of the system is never fun.

Coming back around to what I was saying yesterday, community contributions have managed to bring some pretty notable gains to .NET Core by moving stuff out of the C++ side of the runtime and replacing it with native code. Sure would be nice if we had the same thing here on Unity!

 

There is many editor side I think it is C# and should be extended

- I wish we could to extend unity to support custom build platform. Especially build for dotnet. We might be able to use dotnet runtime directly, or maybe build the whole unity project with dotnet. I want that could use xamarin and wasm directly in unity, using dotnet build tools over unity while still using all other unity tools and library and many other feature such as cloud services

- Support generic natively in unity inspector and serialization. This is something that could be done if we allowed to rewrite inspector system

- Package importer is also very annoying that are not being package itself. The promise to import assetstore package as UPM are very much stale (nuget also stale but still see a glimpse in next year). We could just make it ourselves easily and many wish to do it

- Scene system. Such as scene script, world script, and single scene project. Also subscene

- GameObject and some of native component that unity has no time to extend

There was no impression that many of these kind of feature will become package, let alone allow PR. If unity editor itself become opensource and allow pull request along with build custom version from source into unity hub, it will expand the usage of unity and allow us to experiment on much more aspect than just package

 

@JoshPeterson the System.Serializable attribute is pretty often used to be able to edit custom classes inside the unity editor. Since that attribute is a relic of System.Runtime.Serialization.Formatters.Binary.BinaryFormatter, .net is going to obsolete that attribute relatively soon. How will Unity handle editor exposure of custom classes in the future?

 

This has been available since 2020.1: https://forum.unity.com/threads/generics-serialization.746300/

 

I hope they don't do it! Serializable and NonSerialized are key attributes in multiple serialization libraries, including Unity. It could be difficult to replace them with other attributes by Unity's Updater, because they might be needed by other serialization libraries.

Are you sure they will remove them? I read here that they might keep those attributes. I hope Unity devs can successfully lobby them to keep them. I mean, they are in the root System namespace; classes there should be considered sacred.

 

Natively they said, not include in both inspector, dictionary, or even UnityEvent<float> without derived class isn't it?

This is very scratchy. You can see people complaining in that thread you show me

If there is anything basic that still rely on ISerializeCallBackReceiver it still not a clean experience

 

It doesn't work with Dictionary (dictionaries aren't serializable), but it does work with UnityEvent<float>.

I don't see a lot of people complaining in that thread. I mean, people will always complain or request features when something new comes up, but it's been a while now. That feature works very well were it works; as long as your field type is serializable by Unity, and it's not marked with [SerializeReference], it can be generic. You can easily try it yourself; add public UnityEvent<float> field to some script and see what happens.

 

I see, thank you. I have seen the document still haven't even updated though

https://docs.unity3d.com/2022.2/Documentation/ScriptReference/Events.UnityEvent_1.html

 

Yeah... I've reported it, but I don't think they look at documentation error reports; I've almost never seen one of the documentation errors I've reported get fixed. I know this is now very unrelated to this topic, and I apologize for it, but if someone here knows someone in the Documentation Team, would you mind telling them about this?

 

Still serializing dictionary and tuple is very compelling reason to extend unity editor core

 

Honestly I've never understood why Dictionary isn't supported. Any type that implements

ICollection<T>

, (essentially

IEnumerable<T>

plus an

Add

method, plus a few other things that aren't relevant here,) should be trivially serializable by Unity as long as the type

T

is.

 

According to the current plan, it may be obsoleted as a warning in .NET 8: https://github.com/dotnet/designs/b...matter-obsoletion.md#new-obsoletions-in-net-8.

EDIT
There's a note at the end of the list that says: "(n.b. Obsoleting the [Serializable] and [NonSerialized] attributes may require additional thought. They are intricately tied to the legacy serialization infrastructure and cannot correctly be used outside of it, but there are many serializers in the wild which special-case only these two attributes and which don't understand the contract they have with the rest of the legacy serialization stack.)"

So hopefully they don't do it?

 

Sometimes it doesn't matter in what assembly attribute is located so a dirty quick fix is to place it even in Unity assemblies once it's removed from net.

That was the case with [UnmanagedCallersOnly] in old CoreRT:
https://github.com/dotnet/corert/tree/master/samples/NativeLibrary#exporting-methods

 

I'm not sure this would work for cases that need the attribute in the managed side; I guess it works in the unmanaged side because the attribute is identified by name.

They've extended the Obsolete attribute to add an ID to it. In theory, this allows people to ignore warnings of a specific obsoleted feature. So, as long as they don't actually remove those attributes, maybe another solution is to ignore their specific warnings? It still feels dirty to me, but not as much. That seems to be the intended new way to deal with obsoletion in .NET: https://github.com/dotnet/designs/blob/main/accepted/2020/better-obsoletion/better-obsoletion.md.

 

After the switch to .NET 7 is complete, perhaps this is a good excuse to rethink serialization in Unity entirely. Only serializing types that conform to a seemingly arbitrary set of rules (the only real reason I can think of is because those rules tie into the inspector window) is kinda dumb... perhaps it had its uses (compilation improvements?) but after the move it would be amazing to see this system rethought, this time with a focus on scripting first and editor UI second.

I guess this probably won't happen but I have to try.

 

Would actually love that as well.

 

I second this too. Please rework the serialization infrastructure. I would love to be able to edit readonly structs in the inspector without having to invent a companion type for that only purpose.

 

Not really, package would also be tied to engine version released in lockstep. Even without being able to "generate "glue code" in C++" it would be useful to be able to change C# source.

Wasn't talking about being able to change calls into the C++ but change source code of prebuilt packages.

About changing calls to C++:
1. Many calls are private/internal making them impossible to call without reflection overhead (even with all caching reflection optimizations).
2. Many calls use data types not supported by Burst (managed arrays) but no idea if that would be convertible to anything else:

Maybe Unity could generate additional bindings for all APIs using managed arrays to support Span or NativeArray for Burst?

 

Us end users have to do this frequently anyway. The only way we can do so right now is with Reflection. If I understand correctly, the request would effectively result in the same "We know we're using an API in a non-supported manner" except that it would be more performant.

There is a ton of value in that.

 

To be fair, i've often wished that internal / protected / private would work more like guidelines instead of hard limits in .net. There is already an InternalsVisibleTo() attribute which you can technically use to tell the compiler to bypass api layer safety for internal types. As a power user and when working on niche things I often find myself accessing private things and wishing there was a way to access them in a safe and performant way instead of reflection.

While the compiler should enforce access to the public api ('less often breaking') level as default, why is there no way to set a compiler flag or smth. to let developers access 'potentially often breaking' api levels when they really need to, and on their own responsibility.

 

There is no such thing as "on their own responsibility". The same thing will/would happen as it happened with Unity's experimental/preview packages in the package manager. People demanded support for them and whined about bugs in them and complained why they broke their whatever project in whatever Unity editor version.

People are incapable of using things responsibly. That's why we have these rules. They evolved for a reason.

(Whoever reads this obviously an exception under this rule as usual...)

 

Just because people are incompetent in knowing when to use what and knowing the risks without complaining, doesn't mean it's a simply dismissable point. I get what you're saying, but that's not a problem of the tech, it's an issue of the people's mediocre general mass.

 

What I can see is that it not a problem of existence of private or protected keyword or their behaviour. The actual problem is design flaw of API itself that not expose what it should. The correct fix is the architect who made it, not the language

 

If you're in an advanced scenario where you want to call a private or internal API from Unity, and don't want to use reflection, you can do that with a bit of effort. You need to make your own "dummy" UnityEngine library, and just expose the stuff that you need to access from it.

Then make a library that references this, and exposes those APIs through helper functions. You then need to mark the assembly with

[SecurityPermission(SecurityAction.RequestMinimum, SkipVerification = true)]

to avoid the runtime access checks (it would be a good idea to also use

IgnoresAccessChecksTo

for future-proofing, because the

SkipVerification

trick only works in Mono.)

The resulting .dll can be used in Unity and will allow you to access those APIs "for free" without any reflection or potential IL trimming problems.

For example, here's how you could access Renderer.GetMaterialCount:

UnityEngine:

Code (CSharp):

1. namespace UnityEngine;
2.  
3. public class Object
4. {
5. }
6.  
7. public class Component : Object
8. {
9. }
10.  
11. public class Renderer : Component
12. {
13.     public int GetMaterialCount() => throw null;
14. }

Helper:

Code (CSharp):

1. namespace System.Runtime.CompilerServices;
2.  
3. [AttributeUsage(AttributeTargets.Assembly, AllowMultiple = true)]
4. internal sealed class IgnoresAccessChecksToAttribute : Attribute
5. {
6.     public string AssemblyName { get; }
7.  
8.     public IgnoresAccessChecksToAttribute(string assemblyName)
9.     {
10.         AssemblyName = assemblyName;
11.     }
12. }

Code (CSharp):

1. using UnityEngine;
2. using System.Security.Permissions;
3. using System.Runtime.CompilerServices;
4.  
5. [assembly: IgnoresAccessChecksTo("UnityEngine")]
6. [assembly: IgnoresAccessChecksTo("UnityEngine.CoreModule")]
7.  
8. #pragma warning disable CS0618
9. [assembly: SecurityPermission(SecurityAction.RequestMinimum, SkipVerification = true)]
10.  
11. public static class RendererMarshal
12. {
13.     public static int GetMaterialCount(Renderer renderer)
14.     {
15.         return renderer.GetMaterialCount();
16.     }
17. }

I might publish a sample on how to do this later, if the above information isn't clear enough.

 

For my money though: with reflection at least you are communicating that you’re breaking the rules as opposed to providing your own dll.

There’s also been made massive improvements to reflection performance… in .Net 6 & 7, making it more viable, just not right this second. Reflection is the solution, “I want to bypass security without using reflection” well… you can’t, not without an amount of work that would ultimately defeat the purpose (no offense @TheZombieKiller )

 

Reflection comes with a large performance cost in comparison to direct calls even if you're on the latest .NET*, and it requires annotations to ensure that no code you are relying on is trimmed out. There are also certain kinds of APIs that cannot be invoked with reflection at this time (even in .NET 7!). But as I mentioned, the above is for advanced use cases where you have determined that reflection is too heavy, so I would not expect the average developer to throw that together.

* You can sometimes mitigate the performance cost by using IL emit (at the cost of no longer being able to AOT compile your code), but that still comes with costs -- the JIT won't be able to inline the method, for example.

 

To access Unity internals in "normal" performant way, I "misuse" existing

[InternalsVisibleTo]

attributes.

I've added to my project new asmdef named

Unity.InternalAPIEditorBridge.001

- this assembly has access to UnityEditor internals
- I can write any code with intellisense working for UnityEditor internals
- when something changes in UnityEditor internals, I get compile error - that's what I want
- I cannot access private members, only internal work (but that's enough for 99% of my cases)

I use similar approach for UnityEngine internals -

Unity.InternalAPIEngineBridge.001

All the "internal accessing" code is in one assembly and when something breaks, I can see that right away.
This is pretty close to optimal solution IMHO.

 

That's very cool, i'll definitely check that out and see if it works for non-unity projects as well. If that's the case that would be amazing.

Not sure if it works with private though.

 

IgnoresAccessChecksToAttribute works in regular .NET and applies to all accessibility types (including private), yeah. SecurityPermissionAttribute with SkipVerification set to true is the legacy Mono way (so using both makes your code work in .NET, .NET Mono and legacy/Unity Mono).

Also worth mentioning that if a project has unsafe code enabled, SecurityPermissionAttribute with SkipVerification is actually added automatically by the compiler.

Just note that IgnoresAccessChecksToAttribute is an "undocumented" attribute, so it's something you use at your own risk.

 

I'm not sure I follow. You seem to define this attribute above yourself. Additionally, the undocumented one is apparently for code gen stuff and doesn't work with the compiler's view of things. Can you expand upon this?

 

You have to define it yourself because it isn't actually defined anywhere by default, the runtime recognizes it based on the namespace + class name. It's similar to how you can define System.Index, System.Range, IsExternalInit, SkipLocalsInitAttribute, ModuleInitializerAttribute, etc. manually and then features related to them will work (though this attribute is unique because it's a runtime recognized attribute and not a C# compiler recognized one).

The "supported by the runtime, but not by the compiler" comment on that StackOverflow post is just talking about how the C# compiler won't let you access private or internal data directly when you use that attribute. That's why you need to define a "dummy" library with everything changed to public, and then you compile against that instead.

 

Editor getting ready for the NET Core

 

Oh comrade, my body trembles with anticipation.

 

Earlier in this thread there was a good discussion about Unity's source access, something I'd been thinking about awhile, so I made a thread to discuss the topic if anyone here is interested!

 

Tried it myself and seems like there's no way to get it alloc free?

async Awaitable Update

itself already creates garbage, 1k objects with.

Code (CSharp):

1. async Awaitable Update()
2. {
3.     await Awaitable.NextFrameAsync();
4. }

In UniTask

async UniTask Update

also allocates but there's easy workaround:

Code (CSharp):

1. void Update()
2. {
3.     Work();
4. }
5. async UniTaskVoid Work()
6. {
7.     await UniTask.NextFrame();
8. }

Here comes surprise: combining UniTask with Awaitable gives best results!

Code (CSharp):

1. void Update()
2. {
3.     Work();
4. }
5. async UniTaskVoid Work()
6. {
7.     await Awaitable.NextFrameAsync();
8. }

Also tried ValueTask (as ValueTask Update and ValueTask Work) but both tripled allocations compared to Awaitable.

For context here are coroutines - x8 slower with a lot of alloc (yield return null):

 

I would like to encourage you remake that thread to post again which have been locked while the stupid ones are already declare he is done with messing with us