Unity Future .NET Development Status

Not really? Even the official guidelines state:
“You can take our conventions as-is, or modify them to suit your team's needs.”

https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions

The page is even called common C# code conventions to highlight that different conventions are just… more rare.

That’s not to say that the Unity style can’t still be terrible, but it needs to be for a different reason than “doesn’t follow the common conventions”.

 

Hey @JoshPeterson

Xbox has certification requirements for data transmission. I'm learning that the Unity Mono .NET Runtime System.Net namespace (HttpClient/WebSockets) is disallowed. This is because it uses WinSock and not WinHTTP or XCurl. (public reference: https://learn.microsoft.com/en-us/gaming/gdk/_content/gc/policies/console/certification-requirements XR-134).

Looking to the future, do know which OS network stack the new Unity CoreCLR .NET runtime will use on Windows and Windows console platforms? Would this be the same networking stack as .NET Standard 2.1 Unity or a different one?

 

Since there are (currently) no plans to upgrade the C# language version until the .NET Core migration is completed, I decided to see how much work it would take to produce a tool to brute-force the upgrade. Turns out it was easier than I expected, and appears to work quite well.

I have made the tool available in this repository, but keep in mind that Unity does not endorse using this, and you should not expect them to provide any support for it. You effectively forfeit your ability to make valid bug reports while using this.

The tool works by making two changes to the Unity installation folder:

• Symbolically linking the

  DotNetSdkRoslyn

  and

  NetCoreRuntime

  directories to the most recent .NET SDK installed on your machine.
• Detecting the most recent version of the C# language supported by the version of Roslyn included in the aforementioned SDK, and patching the

  UnityEditor.Compilation.ScriptCompilerOptions

  constructor to use that instead of the current value of

  "9.0"

  .

Note that due to Unity (usually) being installed under Program Files, the tool requires administrative privileges in order to successfully patch the installation.

Contributions are welcome, in case anyone wishes to help improve the tool.

EDIT: As a cool bonus, the upgraded Roslyn enables newer source generators like PolySharp to work in Unity!

 

Hi @JoshPeterson. Looks like at Unity 2023 cycle deprecated AssemblyBuilder API and I can't use it anymore. I still need AssemblyBuilder to generate assembly for my use case. What's the replacement solution to get similar AssemblyBuilder result?

 

Second change can be replaces with csc.rcp file in Assets directory with content "-langversion:latest"
need nor administrative privileges no patching

 

An .rsp file will not affect the generated project files that are used in the IDE, so the development experience is much worse (among other problems). The .dll change works with the IDE integration plugins because they use the LanguageVersion property to determine what version number to present in the IDE experience.

 

I have use rsp for many years now and generated projects always have version equal to what in rsp file.
So dont know what you talking about

 

I just made a brand new project in Unity 2022.3.8f1, added a csc.rsp file containing

-langversion:latest

(I also tried with

-langversion:10

) in the Assets folder, and all of the generated .csproj files still have a LangVersion of 9.0. Are you sure you don't have some other code that is manually post-processing the .csproj files? Many earlier attempts at bumping the language version would do that.

 

This already exists / existed for quite a while: https://github.com/mob-sakai/CSharpCompilerSettingsForUnity

 

As far as I know, this package has issues on Unity 2021.x and above (correct me if I'm wrong), and only supports up to C# 10. My intention was to create a tool that only updated Roslyn and the language version, and did so in a similar manner to how it would (presumably) be done officially.

 

@TheZombieKiller s tool actually gave me an idea for a request the other way around:

@JoshPeterson will you make sure to enable .csproj to specify language versions? I’m a package creator, and need to think about backwards compatibility and lowest-allowed Unity version. I’ve set up a system where I can work on packages while working on games, but I always have to go back to check compatibility. It would be A-MA-ZING if I could work from, say Unity 2028.1, but keep my package pinned down to a .NET version from 3 years ago.

I already have no doubt that the improved language stability will make huge strides in allowing package development to become more stable as well, but this would knock it out of the park for me.

 

with the .net migration complete, you would just specify the language version in the csproj as you request anyway

 

Just test it. on empty project and it works
May be this is because I have use rider as IDE and it smart enough in generating csproj files because csc.rsp is file where you can define many project specific options about warinigs, nullability, additional referenced aassembiles or delete referenced assembiles etc. So dont taking it into account when generate csproj is just smell of bad tool but rider is pretty good tool so it just works as expected

Before rider there was UnityVS and we really have csproj preprocessor for it because it was sucks

 

Yeah, it sounds like the Rider integration plugin just looks for a response file and uses that to tweak the generated project. If you ask me, that's just another reason that the .dll patch is a better approach, because it's propagated throughout the whole pipeline, it doesn't require special casing in the IDE integration plugins.

 

@JoshPeterson is there any alpha build/nightly build that we can "try", or a demo with `dotnet run`?

 

The answer is most likely no.
As long as they won't publish any information about the progress of the project, then there won't be a demo either...

 

I remember that some years ago in the forum special builds were published (outside the normal flow of alpha, beta, ...) let's call it "pre-alpha" to get feedback as soon as possible and have different builds faster without waiting for the normal release bureaucracy.

It would be interesting to have something like that but of course I understand that it's not a good practice to skip flows / processes so maybe this was only done before when Unity as a company was smaller.

 

After some experimentation and testing, I've put together a list of new language features introduced in C# 10/11 and their current status in Unity.

 

I spent some more time experimenting, and managed to figure out why Unity can't detect

MonoBehaviour

classes when they are defined using a file-scoped namespace. Starting from Unity 2022 (I assume?), Unity added a new

Unity.SourceGenerators

assembly which is responsible for discovering these classes. However, the code inside it only looks for

NamespaceDeclarationSyntax

, instead of

BaseNamespaceDeclarationSyntax

. This causes it to fail when it encounters

FileScopedNamespaceDeclarationSyntax

. I just added some additional functionality to UnityRoslynUpdater to patch this, and now file-scoped namespaces function exactly as you'd expect.

 

.NET has been using SocketsHttpHandler (which is based on sockets) for HttpClient for a few years already, you can however force WinHttpHandler to be used by doing this: new HttpClient(OperatingSystem.IsWindows() ? new WinHttpHandler() : new SocketsHttpHandler());. The issue is that IIRC last time I've tried to use it in Unity, IL2CPP crashed when using it.

 

Thank you PetrisPeper! This is a terrific solution for Xbox! You wouldn't happen to know if a similar switch exists for WebSockets? I'll DM you with results on whether it works for a PC build and Xbox build.

 

Because this fix only works for Unity 2022 and above, I decided to look into how I could get file-scoped namespaces working properly in Unity 2021 as well. It took a lot of messing around, but I managed to create an extremely experimental patch that replaces the native C# file parsing code in the editor with a Roslyn-based solution (compiled via NativeAOT). It might work in Unity 2020 as well, but I have not tested with it. (And naturally, you should not install this patch into Unity 2022 or above -- it will break).

The patch comes in the form of two .dll files (

version.dll

and

CSharpHelper.dll

) that get placed next to the editor executable. Keep in mind that this patch has NOT been thoroughly tested, so remove those files if you start to encounter crashes.

With this patch and UnityRoslynUpdater, it's now possible to use C# 10 and C# 11 (in an unsupported manner) in all current LTS versions of Unity.

 

You’re over engineering the hell out of it: respect

 

I admit I might have been having a bit too much fun with it

 

At the dawn of .NET Core, Microsoft tried to migrate to JSON (Project.json instead of Project.csproj). I remember the massive outcry from .NET developers, which forced Microsoft to back off and switch back to XML/csproj in .NET Core 1.0 Preview 3 (or 4). It was fun times...

 

.NET developers really are their own worst enemies

 

Well again, I'm not an advocate of JSON either...
It definitely is better than XML imo, but honestly TOML is really the most readable/structured as well as just being storage space efficient...

Welp, it doesn't matter anyways now

 

I didn't actually know about that. *shrug*
well imo that looks way more noisy than the xml version, so i'm not too much of a fan of it.
toml might have been an interesting substitute for it, but....toml gets really messy with lots of list-like elements,
so i'd be more an advocate for yaml than toml.

nevertheless, the .csproj xml structure has excellent intellisense and autocomplete, so i still think everyone who hasn't even tried it yet overblows the complexity quite a bit

 

Am I the only one who thinks

package.json

vs

package.csproj

is not such a big deal? I’m still gonna Google what my options are and get the right syntax for it either way.

 

@JoshPeterson have the team considered replacing UPM with nuget packages that have content files? With content files author can distribute Assets, and raw source code too, which would still allow for custom compilations with platform specific preprocessor directives witouth having to use tfm for every platform

 

I mean if the build tool migration is done nothing should technically stop developers from doing this with for example a custom props/target file?

 

An amazing read:

https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-8/

Looking forward to being able to use .NET 8+ in Unity.

 

I know we aren't supposed to talk about this anywhere except in the mega-thread.
But I still want to say how sorry I'm feeling for the team and @JoshPeterson who still have to show the happy face while all their hard work could have been in vain.

Was holding out in hope for the .NET rework done by the team, seriously considering that decision now. Wanted to say thank you anyway and all the best, we know it's not your fault!

 

yeah I meant it as a joke lol

 

Now that .NET 8 has entered release candidate status, the version of Roslyn that comes bundled with it will report 12.0 as the latest C# version.

This means you can now use C# 12 in Unity through UnityRoslynUpdater. Keep in mind that the Visual Studio integration package has not yet been updated for this. So while C# 12 code will compile, you will get errors in the Visual Studio IDE.

You can fix this manually in

Editor\VisualStudioForWindowsInstallation.cs

by adding

new VersionPair(17,8, /* => */ 12,0),

under the

// VisualStudio 2022

comment inside the

WindowsVersionTable

array.

 

Also, .Net8 is adding

[UnsafeAccessor]

, which Roslyn actually supports (unlike

[IgnoreAccessChecksTo]

).

 

Oh, got a link to something so i can read more about it?

 

https://github.com/dotnet/runtime/issues/81741

 

Note that

UnsafeAccessorAttribute

is mainly intended for source generators (so that they are able to access implementation details of a type they are generating code for, without forcing you to mark members with

internal

), and currently does not work with static classes or types you don't already have access to. If your use case fulfills its requirements though, it's very ideal -- it works with trimming, it doesn't involve runtime reflection, it can be inlined (unlike dynamically generated methods), etc.

 

Def good to see some familiar faces in the discussion tho. Like yourself.

 

And also generics.

 

Just want to let you know that amid the broken trust and the lowest point of Unity era, .NET update is still the one thing that I genuinely care and want to see being completed. keep up the good work team!