.Net 5 support

Any updates on .NET 5/CoreCLR?

On another note, the Mono team has put up issue and PR related to the current embedding API; It's getting deprecated!

User story about moving to modern .NET stack: https://github.com/dotnet/runtime/issues/47763
PR about embedding API deprecation: https://github.com/dotnet/runtime/pull/47715

Also for the curious one, here's some news about the state of AppDomain's in .NET 5 Mono, they are still there, but just for Mono. Old-ish blog but relevant information: https://www.mono-project.com/news/2020/08/24/native-loader-net5/

 

Do we have any update about these? At least, if the document would be updated, which page will be related to this issue?

 

Any update on the upgrade of moving to latest Mono master runtime?

 

Scripting: Update Roslyn to 5.0.102, Update NetCore to 5.0.2

From there: https://unity3d.com/unity/alpha/2021.2.0a6

 

That is for the Editor itself probably. My bet is that we won't get .NET 5 for the runtime, but NET6, and it will be in sometime 2022.

@JoshPeterson ?

 

2022? More like 2024 at best. Check a look the history of Unity

 

Go Josh!

I have nothing else ^_^

 

It's in 2021.2 alpha

EDIT: thanks @Lymdun -- it's not actually

 

No, they didn't updated the runtime, only the C# version, we're still (very) far from .Net 5/6 and stuck with an outdated Mono fork

 

*sad developer noises*

 

I wish unity would fork their editor source out as official repo for changing their scripting backend and build system to dotnet 5 ecosystem, put it in github, and let us contribute it

 

Unity is the only major game engine that doesn't allow its users to view and modify its source code. That, in my opinion, sucks ass

 

You can, as a premium-user

 

As a premium-premium-premium user.

 

Indeed. All that you have to do is privately negotiate a source code license, which will cost you about {nda}.

 

https://unity3d.com/unity/alpha/2021.2.0a12


Just to make sure, I guess this is about IL2CPP compiler only?

 

@JoshPeterson
Would it be possible to get some indication of where the progress of the runtime upgrade is at? For example, maybe a blog post every now and then just describing what's been done or what's left to do at the time? I can't speak for everyone but I know I'd be fine not having an ETA in exchange for progress reports that I could keep an eye out for. Even if the details of the process don't directly apply to users of the engine, it'd be greatly appreciated all the same as something tangible to show that it's being actively worked on.

 

Maybe just opensourcing what you have done to public repo is the solution (maybe sync once a week or 2 weeks, automatically)

This is not promising anything and provide the most transparent progress possible

 

Already the case for Mono upgrade: https://github.com/Unity-Technologies/mono/tree/unity-master-new-unitychanges

 

Sadly we don't want mono. We now want to have true dotnet 5 in unity for everything

 

I think what TheZombieKiller is proposing is not actually promising anything at all. Just sporadic blog posts stating what are u doing right now or what did u finish the day before. So, no promises, no etas, no dates, only stuff already in progress or done.

When you don't have any promises to fulfil (PR doesn't mess up), sometimes a simple post saying "yeah, slow week, still working on X" is all you need.

 

What I wish for the most now is using dotnet ecosystem for exporting unity. Mobile is one thing that I want to use xamarin codebase for ios/android but webassembly is the most I wish for. dotnet system has sophisicate interop system for dealing with js on its wasm export and that was the serious blocking issue using unity webgl for so long

I know it not unity fault but it was of IL2CPP and emscripten. But if we could switch to dotnet everything would be easier

 

Already here

https://forum.unity.com/threads/net-5-support.839890/page-4#post-6544471

but seem like there was no progress has been done at all since last year

There was also another comment about something already exist > https://forum.unity.com/threads/net-5-support.839890/page-4#post-6551857

But then I ask for more information there was no more response thereafter > https://forum.unity.com/threads/net-5-support.839890/page-4#post-6554983

And so why should reinventing the wheel though? dotnet ecosystem already have it and will be even better progressively in the future, while we just stuck with emscripten as a ceiling

Unity would also get benefit from having close relationship with dotnet. There would be many things that dotnet will solve for platform specific and unity engine could be just a framework that rely on those things

And so I want unity team to focus on this task instead of distract to webgl or anything that just already exist in dotnet

 

I don't know what can I write about that thread. It all just summed up to

Which I don't know what exactly what it is. It just vaguely mention and I don't even sure it would be satisfied my need. I want to know more about it too. And so we should have official sticky thread about this under > https://forum.unity.com/forums/webgl.84/ < shouldn't we?

I think, to introduce new build system, it should not need to be support old project. If we want to use new build system we should then start with new project. And keep legacy build system for the old project. I don't even mind that you might create a parallel version of unity completely separate from main version, name it unity.net or anything, as long as it could still be installed by hub

In fact it could be the same as unity tiny. Which completely throw everything legacy that not related to core system out of the way. We could do the same for pure dotnet build system and bypass IL2CPP or emscripten with this process. It could even be another option of project tiny and dots stack exporting. Unity tiny would be more attractive that it could use dotnet core library more easily

 

Writing regularly about stuff like this would be the main benefit of more regular blog posts as you mentioned above. Keep up the good work!

 

Sorry that I would like to say I felt totally opposite

If we have new project format available, we could start new project whenever we want a new project with the new format. And then we most likely stuck a project on a format that create it for eternity. So the quicker the new format was available, the more chance a new project can be start working on it

I don't have statistics number in my hand but I am very suspect that we can count by hand how many project that start off as old rendering system but then switch to URP system. I think normally people don't even migrate project from each year number. If a project was started from 2017 then they most likely still build that project in unity 2017 even in 2021. And people will start new project on newer unity instead

I even see some people don't migrate project. They will just start new project in newer version but then migrate only asset they want to that new project to continue on the same project. And so they leave the old repo intact

It was the traditionally engineering problem. The old project would grow too large and too delicate. Any change introduced leads to requirement of testing everything relate to it. Starting project anew would be easier to use new tech stack

I think unity should not focus on smooth process for migration of build system, it should not be the main concern. Instead make it more obvious that a change is required for using new system might even be better. So we could consider deprecation of some unused and incompatible more easily

 

As a user of the engine, and as one that works with different companies, I hear opinions opposite to @Thaina

There are companies with games older than 5 years that still make money, still get updates and runs on multiple platforms and stores.

You mentioned URP - the reason those projects prefer not to update to URP, is that it's a lot of work, and not a smooth thing for large projects, with lots of assets in assetbundles.
It also means that the users would have to re-download all the assets...

projects like those, do update Unity when possible - new LTS, new patch that solves a bug, importent platform/store update...

There are already too much configurations, that it's hard to find good solutions for different aspects of the engine.
DOTS, ECS, SRP, etc... etc...
Look at assets on the asset store, in the past it was "supports mobile and desktop".
Now assets need to support much more configurations, and it's hard to keep up. And confusing for the users

 

It sure get updates but I mean it would not upgrade the project to newer unity version

This, with the same thought process, unity version of the year are the same. Deprecated function, Breaking change and subtle change. Recently I have update from unity 2020 to 2021 and found out that facebook package are not compatible with 2021 networking because it still use `WWW` class for networking

I'm sure people updates their content and their project but don't really update their underlying system unless it really required

For what I mean unity version, I mean project that start in unity 2017.0 might be upgrade to 2017.1 or 2017.3 LTS eventually but I'm sure it would be hardly from 2017.3 to 2020.2, even the latter got LTS

A bit of agreeable but I would argue that most of asset we have in unity are completely separatable from changing build system anyway. Some that do are most likely the automate script that might have alternative in dotnet and/or xamarin

And if we launch the new format at first. After a while it become solid and old project system would be deprecated, we can then making conversion to amend it like unity always do

 

What breaking changes did you consider?

What comes to my mind:

• For regular c# code most folks write it should not mean any breaking change.
• Code relying on runtime specifics do need to be updated (build post processors for IL2CPP which emit IL maybe?) but that is to be expected on other runtime specific changes, so it is'nt really different from you current yearly lts updates.
• Stuff relying on the current project system: csproj placements, asmdef manipulation, csproj manipulation, stuff like this would just right out break, but theese usually are to solve the shortcomings of the c# project system unity uses, and most of it would just become not needed anymore, becouse you can version the csproj and sln files.
• UPM packages maybe? I mean I understand the reasons behind it, but you could create a mechanism which converts them to nuget packages. Also I understand how it might be more desirable to use UPM pacakages when you want to share many, big files (textures, meshes, etc), but if you would add nuget support code-only UPM packages would just make more sense to migrate to nuget.

So, I specifically can't see the blocking issues you mentined? Am I way off? What problems did you consider?

(Also I understand you might not be able to share any of the details I asked, but just a hot-warm-antarctic like answer would mean a lot to me, and potentially the community)

 

Do you know why people use prebuilt dlls? My guess would be because using Nuget packages and internal dependencies in unity is attthe moment is not a trivial task, and really cumbersome - becouse it does not utilizes the standard dotnet build system. If you would make that work, people would not need to use pre-built dlls, they could just use their dependencies as package/project references, and this also would make life easier for them.

On the load context: net 6 has preview on hot reload, wouldn't that make more sense than a custom system? Also couldn't you create an emulated version of the old system with a deprecation warning and phase it out a year later?

 

Correct me if I'm wrong, but I believe this could be solved by Unity shipping a compatibility mscorlib.dll which contains type forwarders leading to netstandard.dll or System.Private.CoreLib.dll.

 

Thanks for the in-depth replies!

 

Compilation speed is one reason - prebuilt dll's does not need to be compiled. Asmdef juggling solves the same problem, but may or may not be more complex to handle.

There's also a bunch of stuff that's generally distributed as dll's that's used in a lot of places. The Steam integration is a good example - every Steam game would have to have their Steam dll swapped.

Won't projects that support fast enter play mode not need to change, since fast enter play mode already requires you to handle the domain not reloading?

 

I'm not sure if this is really true. Correct me if I'm wrong.

.NET Core (at least from version 2.1) and .NET 5 includes mscorlib.dll. It has just forwarded types to other assemblies (not just System.Private.CoreLib.dll).

You even can use dlls compiled for .Net Framework in .NET Core app as long as they do not use some types that do not exist in .NET Core (and does not have type forward in mscorlib.dll)

Here some info about how its work
https://docs.microsoft.com/en-us/dotnet/standard/net-standard#net-framework-compatibility-mode
https://docs.microsoft.com/en-us/do...d-party-deps#net-framework-compatibility-mode