Unity Future .NET Development Status

I guess even just the player runtime is not yet shipped at 2023.2 right?

 

I respect you don't want to share a date. Could you instead write a few lines about the progress?

For example:
How's going CoreCLR intergration?
What roadblocks you've encountered?
Is AssemblyLoadContext working well?
What remains to be implemented?

I love the work you're doing, both you specifically here in this thread and you as Unity in regards to CoreCLR.
For me it's the most exciting feature since PBR renderer.

 

I think at least one of these questions will be answered in the blog post (scheduled for September, see here).
This post also gives some information on what is going on (though it is already 1.5 months old, more work has probably been done since then).

 

Is there any plan to slowly port Unity C++ engine code to C# and even better burst compatible C# code in future after release CoreCLR?

 

I'm actually curious about how you evaluate if the code is working without having migrated all the code. Because well.....you can't have part of the engine running on CoreCLR and part of it on legacy......or how does that work?

 

Can I expect zero breaking changes for dots project when switched CoreCLR since dots project enabled enter player mode options by default?

Awesome. Hopefully can port more C++ to C# so it's much smoother to upgrade to each new .NET version release next time. And also seems like latest .NET performance is quite near or even better than C++ so less reason to C++ anymore. I would like to see the future where unity engine becomes full pure C# engine.

 

Will Unity use the official C# Coding guidelines going forward? I've seen quite a lot of code were naming conventions were not properly used (such as lowercase property names instead of camel-cased ones)

Also, as code is now moved to C# will you take certain actions to improve overall code quality? I have seen quite a few packages from Unity where the code quality is not up to par of what one would expect, also stuff like extensibility of the APIs come into mind.

One of the main things, would also be unit / integration tests for the C# packages (this could alleviate breakages such as seen recently for example with the Unity IAP package on Android)

 

@JoshPeterson Something to say about sdk style csproj + native nuget + dotnet sdk compilation?

Thanks!

 

Looking forward to that, love blog posts which go deep into the .NET. If it's anywhere close to Making AnimationEvent safe for the CoreCLR garbage collector it will be perfect.

 

Please don't...

Treat this as a breaking change, as a major release, as something that shouldn't be migrated to!
I hate this mentality and it is literally the whole reason why we still have deprecated references to components in MonoBehaviors.

Honestly if Unity could treat this release as a new slate, i.e. create actual breaking change (let's start with, for example, deleting every single obsolete/deprecated piece of code) that would be an achievement imo!

 

Like take Godot Engine as an example...
They are still supporting 3.x with bug fixes, security patches and try to cherry-pick certain PRs from the 4.x releases.
But their main focus is still 4.x and they created breaking changes as they knew some old code was becoming obsolete...

That is literally why it is called a major release! It should break stuff!

 

Yes please. Unity would really benefit from more mentality like this. Especially with the .net migration. While not everything might break, all deprecated and overruled code should absolutely break with every major release.

Or at least, in a 3 year cycle, which would be better adoptable even. But anything deprecated that is older than 3 years has to be completely removed.

 

I don't mind Unity strafing from the C# Guidelines, after all they're only guidelines, but I think it would benefit the community if Unity wrote their own guidelines that package / asset store developers can follow for consistent style. It wouldn't change any of the code, but it would settle some debates.

It would also be massively controversial so it's probably never gonna happen

Personally: "Oh no, why do I say that, I like naming all my private variables as

_myVariable

, I'm probably gonna have to put an

m

in there to please the guidelines..."

 

No i think Unity as one major .net framework should really be a good representative and go with the official guidelines.

 

I want Component.collider, light and friends to die out so bad

 

Thats what I'm saying! XD right?

 

You can be a good representative and not follow the official guidelines; besides there is too much code to bother with changing variables names, no company is gonna approve THAT much breaking changes over so little gain (styling?) so it's better to think realistically and suggest options that may happen one day, rather than resulting in a board of directors laughing their asses off.

It reads bad over text and with my sirius profile pic but I meant it jokingly bottomline I don't see Unity changing their style, that would be a world of pain.

 

Actually, even tho you said it jokingly, since some months ago there have already been official threads regarding code style changes.

 

I think the main idea was that Unity from now on should adhere to some guidelines.
This way new code will be stylistically correct as well as easier to read! (And old code hopefully removed/deprecated)

I agree that we shouldn't really care about this as much as we are currently, especially because Unity is starting to do exactly that!

I agree 100%! The main purpose of a naming convention is that it is some kind of guideline, that indicates for example the access modifier of a variable and not necessarily be stylistically "beautiful", but rather quick to read!

 

How promising exactly?

The thing I am most excited for, even more so than .NET 7 support, is not having to wait 10+ seconds for every domain reload T_T

On an empty test project, how long does reloading regularly take? If it’s anywhere below 2 seconds you made a happy man.

 

For a MUCH LONGER question, I recently read an article about why the Unity Editor can become slow, and some of the biggest culprits were, drumroll, domain reload and serialization. (Partly because of garbage collection needing to scrub for leaked data which is just… poor craftsmanship. Sins of the father.)

If you are personally interested, I would love to get your opinion on it! But it’s a really long read and I wouldn’t expect you to.

http://blog.s-schoener.com/2023-08-16-why-your-unity-project-is-slow/

 

I expect when official improves these two aspects i.e. script compilation and domain reload, I should get zero progress bar that no more staling at editor that I can freely do coding and compile at ide and do some work at editor simultaneously and also enter play mode should be much faster than the current editor with enabled enter play mode options. The current editor is already quite fast but I expect even faster speed. Btw reload script code separately should be not just UnityEngine code and .NET BCL code but also for all the packages no matter it's official package or third party package to achieve truly incremental code compilation that only spend time compile the code that actually change. For current editor I believe it just compile and reload all code no matter what.

 

How will MSBuild work with asmdefs? Will that still be a thing that Unity supports, or we'll have to move to modern csproj?

 

As far as I can tell from Unity's previous mentality, they will probably have them interop together...

But it is probably better if they created a system that automatically migrated an asmdef in a project, to their csproj equivalent and just removed the asmdef functionality altogether from the engine...

 

I think it is stated in this very thread somewhere that they will be moving to classical csproj and msbuild in replacement to asmdef.

 

You can watch the latest talk about the .net migration of Unity to have this answered.

asmdefs will still exist, but silently generate a modern csproj file that will be used. That also means you can have asmdefs and 'manual' csproj's in the same project and convert them in your own time.

(Though i would absolutely recommend to switch to the full csproj way quickly, and for Unity not to keep asmdefs around for too long)

 

Please keep asmdefs, idc about the underlying working, just keep them for their ease of use and function

Edit: The asmdefs could act as a front-end for csproj files if needed, but their presence contributes positively to the editor UX imo

 

Since dots is custom solution built by official I would expect zero breaking changes that official should able to upgrade the underlying core tech without pollute high level user facing API unless the API changes make it much simpler and nicer. Consider implement auto upgrader to auto upgrade most of the API and provide detailed upgrade documentation for the part that needs to upgrade manually.

 

What you are asking for is precisely the ballast Unity has had for a long time and prevents it from improving with more freedom.

In any software that uses SemVer as Unity should have breaking changes in major versions (2022.x vs 2023.x) and document these changes.

For requests like yours we still have from Unity 3.x the shortcuts to rigidBody etc from a MonoBehaviour.

Having everything work without requiring development changes is very convenient from a developer point of view but this is not free for Unity, it adds a lot of technical debt.

 

If you get into it, csproj is way simpler, cleaner, more descriptive, and consistent across .net.

 

The "best" part is, updating unity versions always break things, just not in the code, but everywhere else xD

Edit: well, actually, a lot of packages code does break cuz they don't have either backward nor forward compatibility.

 

You know what you're totally right I actually forgot!
But wouldn't it theoretically be just better if Unity forced you to change them? (Especially because there are not a lot of them, even in big projects, maybe max 100, but not more)

Normally I would agree, but for something this simple I find that Unity should easily be able to create a simple converter between these two formats and not allow opening a project in a newer version without using this converter.

I find that being explicit about the way that Unity is handling those files (Not converting them behind the scenes to csproj, but also creating an actual csproj and reflecting that change) is way better, don't you guys think?

Actually interested in your opinions about this...

 

I would be okay with it converting behind the scenes, but with a deprecation warning at the top of asmdef files with:

• A link to the documentation page about “how to convert”
• A Unity version 2 years in the future when asmdefs will be removed!!! We all know Unity’s track record with deprecation so they better have some date-of-removal to which the community can hold them accountable.

 

do csproj have an equivalent of

asmref

? I used them when I needed to access internals of packages without using reflection (e.g by injecting an

[assembly: InternalsVisibleTo("MyCode")]

in their assembly

if not,

asmdef

need to stay

 

No csproj does not.

There are much better ways to achieve this than asmref anyway, so asmdef should absolutely be removed.

 

Could you share these "much better ways to achieve this"?

 

If they are converting behind the scenes, I would hope they have a button that lets you replace your asmdef with a csproj file. Like a "Replace with csproj file" button inside the warning.

 

in csproj:

<Project>
<ItemGroup>
<InternalsVisibleTo Include="MyCode" />
</ItemGroup>
</Project>

I'm looking forward to removing asmdefs from my projects. Hopefully this year

 

@JoshPeterson Not completely unrelated to the upgrade, but will it become easier to use source generators? Currently there’s like 12 or so steps to get it working, none of which are particularly beginner friendly.

https://docs.unity3d.com/Manual/roslyn-analyzers.html

It made me hold off on source generators in a past project because time.

 

IDK, I managed to build and test my first Source Generator in less than an hour and it included a monstrosity like this:

Code (CSharp):

1. using UnityEditor;
2.  
3. namespace Plugins.LurkingNinja.Editor
4. {
5.     public class OnPostProcessDll : AssetPostprocessor
6.     {
7.         private static void OnPostprocessAllAssets(string[] importedAssets, string[] deletedAssets,
8.             string[] movedAssets, string[] movedFromAssetPaths)
9.         {
10.             foreach (var path in importedAssets)
11.             {
12.                 if (path != "Assets/[your-path-to-your-dll]/LurkingNinja.GameUtils.Codegen.dll") continue;
13.                 var dllImporter = AssetImporter.GetAtPath(path) as PluginImporter;
14.                 if (dllImporter is null) continue;
15.                 dllImporter.SetCompatibleWithEditor(false);
16.                 dllImporter.SetCompatibleWithAnyPlatform(false);
17.                 dllImporter.SetExcludeFromAnyPlatform("Any", true);
18.                 dllImporter.SetExcludeFromAnyPlatform("Editor", true);
19.                 dllImporter.SetExcludeFromAnyPlatform("Linux64", true);
20.                 dllImporter.SetExcludeFromAnyPlatform("OSXUniversal", true);
21.                 dllImporter.SetExcludeFromAnyPlatform("Win", true);
22.                 dllImporter.SetExcludeFromAnyPlatform("Win64", true);
23.                 AssetDatabase.SetLabels(AssetImporter.GetAtPath(path), new[]{"RoslynAnalyzer"});
24.                 dllImporter.SaveAndReimport();
25.             }
26.         }
27.     }
28. }

To be honest, I'm not familiar with importing DLLs, since I chose to do most things inside Unity so far, so if this can be simplified, someone please LMK.
I also set a command upon build in my SourceGenerator project to copy the output DLL into the path inside my unity project, so when I switch to Unity it reimports and the above script runs. I don't really get the DllImporter API and there is no documentation. If I exclude it from ANY platform, why am I doing this per platform? Anyway. It works. And obviously I have a version in another project with multiple dll paths obviously to process more, separate modules if needed.

ps: side note: you need Microsoft.CodeAnalysis.CSharp 3.8.0 package but despite the Unity docs, you can get away with using Microsoft.CodeAnalysis.Common 3.9.0. You will get warning because of mismatch version numbers, but it builds and more importantly it works in Unity 2023.1 (I haven't tested it in earlier).

 

You really don't need a script for this. You can also just do it manually, and since the import settings are saved in metadata, when you replace an old SourceGenerator dll with a new one, and they still have the same name, you don't need to make changes to the import settings.