I am ecstatic that Unity is planning to move to modern .NET tooling, as described in this blog post. However, I’m worried that this will be yet another instance where Unity deprecates a feature while its replacement is still unfinished (or still in preview). The Unity team has a history of doing this, and it’s been annoying. As the saying goes, “Unity has two ways of solving any problem, but one is deprecated, and the other is experimental”.
If Unity continues this pattern with the C# scripting engine, it will be more than just an annoyance; it will undermine the very foundation of the engine. Please, Unity. Do not deprecate the Mono backend until its replacement is finished. That means:
It has feature parity with the existing runtime
It is at least as bug-free as the existing runtime
It is at least as thoroughly documented as the existing runtime
It is officially out of preview
Until all of those criteria are met, Mono must remain a first-class citizen. Do not mark it as deprecated. Do not put warning labels on it, scaring people out of using it. Do not treat it like UNet.
As far as I can tell from the blog, they do not plan to force to change the way we program. What exactly are you fearing? removal/restructuring of the the standard “event” methods like Update, OnCollission etc.?
It sounds way more like a change in the background like when you switch to ll2cpp.
They are actually fully unrelated?
I always thought it was called that because Unity was initially way closer tied to Mono framework before ll2cpp existed and they kept the name to not break people’s code.
There is probably much misunderstanding about where C# ends and Unity begins for newcomers. Monobehaviour is just a base class with added ‘special functionality’ via named functions, inspector variables etc. Even the documentation is confusing! :
MonoBehaviour is the base class from which every Unity script derives.
When you use C#, you must explicitly derive from MonoBehaviour.
Well that depends on your definition of a script - a C# file added to the scene must be a MonoBehaviour. You can write loads of plain C# classes (not derived from MonoBehaviour) in as many .cs files as you like that are not in the scene though, yet used by your Game/Project. Many classes may have no link to ‘Unity & MonoBehaviours’, but by this documentation a beginner might (& some have) inherit from Monobehaviour for every C# class, yet it would be wrong!
@falconfetus8 We are very aware of Unity’s history in this regard - removing or not supporting existing solutions before the new solution is actually ready to replace it. We’re trying to change that.
We absolutely will not deprecate/remove the Mono scripting backend until the CoreCLR scripting backend is ready as a complete replacement. Ensure that Unity projects continue to work across this transition to a .NET Core-based ecosystem is key to our philosophy for this project.
The documentation for MonoBehaviour is pretty funny, because if you open the 5.2 version of the same docs page, you can clearly see what happened.
5.1:
“Using Javascript every script automatically derives from MonoBehaviour. When using C# or Boo you have to explicitly derive from MonoBehaviour”
5.6 (Boo got removed from the docs):
“When you use C#, you must explicitly derive from MonoBehaviour. When you use UnityScript (a type of JavaScript), you do not have to explicitly derive from MonoBehaviour.”
2019 (UnityScript got removed from the docs):
“When you use C#, you must explicitly derive from MonoBehaviour.”
So they removed parts of the sentence until it meant something different, and didn’t notice.
@JoshPeterson somebody probably ought to look at it. If Unity had a documentation workflow that, uh, functioned, you could just fix it, but I assume you instead have to let the Documentation team know so they can never do anything about it.
Thanks for explaining this because Monobehaviour and Mono do sound the same for people like me who don’t fully understand the differences.
I just passed more than 1 million downloads across iOS and android so I have quite an investment in the code base.
Im more an artist than a coders and I have years of code written for my open world games in C# (which I had to learn when Unity dropped Javascript support) so I was very stressed that somehow this was going to impact my code.
Is there any ways in which this change is going to affect legacy projects and code? Anything at all that anyone thinks will need to be rewritten? I dont use .dlls specifically so everything is pure code based.
As far as we know, things will stay the same. If you depend on using the newest Unity version in a timely fashion (for example due to console support) it is of course always a good idea to plan some migration time for that since changes just do happen when an engine progresses.
If you have spare capacity right now for preparations (since you worry about something in the distant future) you could invest that in better automated test coverage. That reduces the manual testing effort and risk of stress due to missed bugs after a significant change greatly. Bugfixing in general is easier with tests.
Unity has some solid tools for that nowadays.
Btw. wonder if they consider providing an optional alias to MonoBehavior with this and make that the default. Something like “UnityBehavior” or “GameloopComponent” to be descriptive since there’s nothing of original “Mono” in the software anymore.
The first thing you can do to prepare is to switch the framework to .NET Standard 2.1 (Unity 2021.3+), as it is certainly compatible with future versions (except for Unity API changes). The first iteration of CoreCLR is only support Standard 2.1, and .NET 6+ at a later point.
Now im worried. because many asset store assets ask us to use .Net 4.x framework. And im wondering if they will work with the new standard. I had assumed until this moment that 4 would be better than 2. Im using Unity 2019 but I will definitely test my game projects using 2.1 standard in a higher Unity version as soon as I can. Thank you for the information.
Naming the .NET world is difficult. .NET Framework 4.x is actually older than .NET Standard 2.1. They have overlapping API sets as well.
Most of what is in .NET Framework 4.x is in .NET Standard 2.1, so I suspect many assets targeting it will work. Those that don’t work should at least fail with meaningful errors.
