Unity Future .NET Development Status

Well old code will still work, no?
Don't refactor something that isn't broken per se...

 

Thank you for asking, but it’s not a big deal. It’s mainly some concerns because I’ve encountered similar situations before. Specifically, after Unity introduced support for the source code generator, I built a small framework for reading and serializing data specifically for entities (to facilitate interaction with the editor and non-entity parts). However, after working on it for months, DOTS 1.0 was released, which provided basic functionality that met my needs, putting me in a dilemma between “rewriting around the new DOTS features” and “continuing to improve my own imperfect framework.” But I believe this topic is not suitable for a detailed discussion in this thread, and I have already resolved the issue now.
So the main reason for the question above was just a general concern, especially considering that Unity will have native NuGet support in the future, and other frameworks will always be better than my own simple framework. However, since there is still a lot of work to be done for Unity Team, I don’t need to worry about this issue anymore. After all, it’s not practical to wait for years just to save some effort.

Makes sense. I think the best choice now is to do whatever needs to be done.

Thank you for the response. I understand the current situation now.

 

Ey, you don’t know that! You can be really special in how you approach a problem!

I come across a lot of monolithic code, where I express myself in really small objects with a lot of editor friendliness. There’s a place for that.

(Takes a S***ton of time tho XD)

 

Can you clarify if this would likely need some changes such as avoiding static state inside the editor? If so it would help us to slowly prepare our projects for this upcoming change.

 

How will this work with 3rd party libs? Sometimes its impossible to use the new enter play mode.

 

I have always thought about it and if Unity does not develop a Roslyn analyzer (if it is possible) that analyzes certain bad practices that contribute to not working with that mode, it is a difficult problem to solve.

And yet it is still a problem because even if there is such an analyzer, nothing prevents you to publish an asset / package violating those rules.

 

For open source libs I usually issue a feature request or prepare a PR in case it's simple to do that. The last resort would be working on my own fork.

 

So when you say “very similar behavior”, does that mean we still have to reset our static values inside of RuntimeInitializationMode.SubsystemRegistration? It would be amazing if the new solution could be more aware of statics and give us both worlds: no domain reloads, but auto-resetting statics on playmode enter/exit.

If that is impossible I would also love to know it! I’ll just continue using RuntimeInitializationMode.SubsystemRegistration no problem.

 

I tried the assembly load contexts with .Net7 and it seems they now properly reset static state:

Code (CSharp):

1.  
2. public class Program
3. {
4.     static void Main()
5.     {
6.         Proxy.X = 15;
7.         var alc = new System.Runtime.Loader.AssemblyLoadContext("MyTest", true);
8.         var asm = alc.LoadFromAssemblyPath(typeof(Program).Assembly.Location);
9.         var proxy = asm.CreateInstance(typeof(Proxy).FullName);
10.         Console.WriteLine(proxy.GetType().GetMethod("Increment").Invoke(null, null));
11.     }
12. }
13.  
14. class Proxy
15. {
16.     public static int X;
17.     public static int Increment() => ++X;
18. }
19.  

This outputs 1 (static state is reset!)

Also see: https://stackoverflow.com/questions/59019761/does-assemblyloadcontext-isolate-static-variables

 

@JoshPeterson could this mean statics will properly reset in Unity .NET7 as well?

 

Fck, this S*** may just be the most exciting stuff coming for Unity in a good while. Okay okay, DOTS wasn't too shabby either but this one here is a win for just about every single Unity user. Keep it up guys.

Approach of taking Unity internal DLLs out of domain reloads (whatever their name will be in the new mode) sounds great. Even just the getting the entire editor out of there sounds like a massive win.

This would be awesome. Especially for package devs.

 

Please prioritize day one hot-reload support so we can do some iteration without entering/exiting play mode.
Write and debug code by using Hot Reload - Visual Studio (Windows) | Microsoft Learn

 

I would actually not prioritize this. I would much rather have latest .NET version asap, and replacement of Assembly Definition for .csproj not far behind. Once the compilation is tightly integrated with .NET, we already get a lot of free benefits. After that, it will also be much easier to define a clear path towards hot-reload.

While the link you posted is great, it wouldn’t work like that for Unity- why was somewhere pages and pages back in this thread and unfortunately I forgot, but I remember it was discussed and shelved for good reason.

 

The fact is, if Unity can't keep up with C# then it is completely useless.

 

It still can't even do 6 and 7 is almost finished. It's pretty bad...

 

This thread has been 2 years ongoing about this exact thing. The team is pretty transparent about the monumental tasks ahead of them and how they are making steady progress. There exists proof of their progress in the changelogs of new Unity versions, mostly in alpha and beta.

@JoshPeterson , the lead engineer on this (from what I gather) has amassed such a reputation in this thread that he could post “I’m going to kill this puppy” tomorrow and it would still get 6 likes.

You’re in good hands, unfortunately “due to historic reasons” it just takes a while.

 

They are working on a foundation to accomodate this need of everyone. But that foundation is just huge and requires that much time. I can understand if you are new to this thread. But unfortunately your complain doesn't bring anything new nor useful to the table since they have already been working on it for a while. You have to wait, like everyone else here.

 

Seems like you can't keep up as well. .net 7 has been fully released almost a year ago. .net 8 is almost ready by now.
Stop throwing around nonsense and read this thread first! They have been hard working on the .net migration for years now.

 

That's a massive False Dilemma fallacy. Just because Unity doesn't support the latest C# version at this very moment doesn't automatically mean that what it does support is therefore useless. You have arbitrarily excluded the middle ground position that the current C# support is good, but could be better. The fact that there are lots of people making products using the Unity engine, and making money from them, doesn't line up with your claim that the scripting API those products depend on is "completely useless".

As for your error, the problem is on your end. I just created a new Unity project and made a script that invokes two of BitConverter's methods. I had no errors at all, let alone the one in your screenshot. So that error is because you broke something and have no one but yourself to blame.

 

No, it's because i wrote it in .Net 7, I lowered to the old 4.8 with the exact same code and it works. this is 100% false.

EDIT: I tried .net 5, 6 & 7. no go, only works in 4.8 or lower.

 

You can't write in Unity with .net 7.
This is only possible if you write it seperately and import it as a pluging in the .dll format.

If you did this and it fails it's still your very own fault and not Unity's.
Furthermore, it is your fault for not knowing the tools you work with.

 

Are you saying that you compiled a DLL against those frameworks outside Unity, then tried to use them in your Unity project as-is? If so, this is expected behaviour. A C# DLL needs to run in an environment that is compatible with the framework it was compiled against.

Why are you trying to do this though? Why not just place the source code for the DLL in your project and let Unity handle compiling it? Also, are you aware that the latest framework Unity currently supports is Standard 2.1, not Framework 4.8?

Regardless though, my main point still stands. Just because Unity doesn't support the latest C# version at this very moment doesn't automatically mean that what it does support is therefore useless.

 

in 2023 preview you can do both and both don't work.
2.1 should support 7 but for some reason it doesn't:
.NET Standard | Microsoft Learn
.NET and .NET Core 3.0, 3.1, 5.0, 6.0, 7.0
so, in 2023 preview you can pick 2.1 but it actually isn't 2.1??

 

I've got to be missing something or unity is lying. So hopefully I am just missing something. That would be a better result for everyone lol

 

@Ziron999 You have it backwards. .Net 7.0 supports .Net Standard 2.1. Not the other way around.

 

I figured it out, the dll location has changed. I can now run my own dedicated server with my own code with .net 7 and unity works with it finally!!!! this is very good. This maximizes performance and multithreading by a large margin. I hope unity keeps up with this because it is very important if they are going to stick with c# being the main language.

 

You don't seem to comprehend what the words you're using mean.
.NET Standard 2.1 is a baseline set of APIs that can be relied on and targeted as a pseudo-framework for assemblies that all the actual frameworks that implement that version of .NET Standard can load and use.
Unity uses a Mono version that supports this .NET Standard 2.1 API level, but does not have the BCL for .NET 7.
.NET Standard 2.1 includes a wide breadth of APIs that are quite good for games development (including handy things like the Span<T> memory abstraction for performance-sensitive code).
You need to use assemblies that specifically target .NET Standard 2.1 or some lower .NET Standard level to ensure compatibility with Unity. That, or again, compile code with Unity itself. This shouldn't be that big of an issue, Unity uses the same Roslyn compiler technology as mainline .NET does, you're limited by the current supported C# level and API surface area from .NET Standard 2.1.
Word to the wise, even though .NET Framework 4.8 may be newer by release date, it does not include parts of .NET Standard 2.1 and is therefore not defined to implement .NET Standard 2.1. The APIs available in .NET Framework 4.8 that aren't available in .NET Standard 2.1 could be considered less useful for most games, generally platform-specific things such as WinForms. It is advisable to use .NET Standard for the current set of functionality that makes it useful as well as the easier transition to whatever .NET version Unity lands on in the future.

 

weird, my code works in both directions now after finding the new location for the dll needed. the funny thing is, i really don't even need the dll anymore. everything can just become bytes, ints, floats, etc in the end anyway lol.
it's really just for lazyness.

 

So… everyone was right, it was your fault, and again Unity is already keeping up with this it just takes time.

Look there is no shame in making a mistake, as programmers that’s 90% of our job, but be humble enough to say it.

“If they are going to stick with c# being the main language”? …yah …I think they will.

Can’t imagine how it maximizes performance unless you're using massive amounts of reflection or System.Linq, otherwise it’s not Unity where that performance is suddenly coming from. Those were 2 of the biggest .NET 7 improvements I think.

 

Just wanted to check in to see if this is still the case? The C#11 static abstract interface operators for numeric types would be a heckin *blessing* to all my (admittedly math heavy) projects (along with the buckets of QOL changes), especially if implemented across unity's vector types so that we can do generic algebra with operators and all across multiple dimensions like:

Code (CSharp):

1. // Assuming the new C#11 numerics/operator interfaces
2. // are implemented in Vector2/Vector3/Vector4:
3. public V Lerp<V,S>( V a, V b, S t )
4.    where V : IAdditionOperators<V, V, V>
5.    where V : IMultiplyOperators<S, V, V>
6. {
7.    return ( 1 - t ) * a + t * b;
8. }

This one method would allow:

Code (CSharp):

1. Lerp( float, float, float )
2. Lerp( float, float, float )
3. Lerp( Vector2, Vector2, float )
4. Lerp( Vector3, Vector3, float )
5. Lerp( Vector4, Vector4, float )
6. Lerp( Vector4, Vector4, int )
7. Lerp( Vector4, Vector4, double )
8. Lerp( Vector4, Vector4, decimal )
9. // and many more

This would make a generic lerp method that you could use for all unity's VectorX types, in addition to almost all built-in types for a 1D lerp (float, double, Decimal, etc.)

short snippets like lerp is easy enough to work around, but as soon as it grows into something much larger and complex you end up either having to duplicate a ton of code (which is a nightmare to manage) or use code generation (which makes editing/iterating hard) or sacrifice performance (by using runtime type checking). I've ended up having to make code generators for things like this multiple times now, having this would save so much work

 

This will ABSOLUTELY NOT come before the .net transition, since this is NOT a C# feature, but requires actual runtime changes.
Furthermore, Unity will have to add those interfaces to their types retrospectively after the transition, and this is not something that 'happens automatically'. But i'd rather they do the transition first without adding these interfaces to their types, since that will give us the transition sooner.

 

woah okay I'm so sorry for requesting support for C#11 which is apparently not a C# feature lol, idk why you're being so aggressive

first, there's no dichotomy between doing one or the other "first", unity is more than one person, and could do both C#11 and CoreCLR and finish them in whatever order, there's no dependency between them as far as I know, and I'm just asking if it's still the case that they plan on finishing CoreCLR first, especially since the CoreCLR move is significantly more work than upgrading to C#11

secondly, as for Unity making use of C#11 interface operators in their existing vector types - it would be nice! but it wouldn't be a dealbreaker if I had to that part myself, if Unity doesn't have the resources/care/priority to. As far as I know, adding those interfaces wouldn't incur any breaking changes or changes to runtime code, only add the possibility to type constrain them using the new C#11 numeric operator interfaces. It's just a matter of adding those interfaces to the class definition, that's all you need for basic support.

 

I'm not aggressive. Just highlighting the important points.
Abstract static interface members are not a pure C# syntax feature. They require runtime support to work, which is what i said.
Btw, those interfaces are absolutely binary breaking.

 

I still don't see why that should prevent unity from upgrading to C#11, again they could work on both, there's no need to wait until the CoreCLR move is done (as far as I know), it's just what they've decided back then, and I'm just wondering if that's still the case

 

They could work on C# 11, but they would not be able to get all features of C# 11 to work. To support all C# 11 features, such as abstract static interface members, they need CoreCLR. Why should they put effort into a subset of C# 11 that will become obsolete anyway once they do the full transition? Especially since C# 11 did not add features you couldn't do without for a little bit longer.

 

oh, alright! I was under the impression it would be possible to upgrade to C#11 without doing the CoreCLR move

 

No that's what i'm telling you the whole time. Some features of C# 11 require changes in the runtime, aka they require CoreCLR.

 

yeah, sorry that wasn't clear to me

 

alright! is it still slated for 2024? (from what I read in a 2022 unity blog)

 

its ok you can dm me I won't tell anyone

 

That's what everyone says . I wouldn't dig too deep for a year number or date estimation, they will tell us when it's getting near. The status updates here provide us with quite a lot of information of what is happening behind the scenes. There will also be a blog post in autumn I think where they explain more stuff.