We wanted to let everyone on the forum know our future plans for the Mono runtime upgrade.
The Unity 2017.1 release will be available as a public beta soon. In this release, the Mono runtime upgrade feature will be an option. For a given project, you can choose to use the existing version of Mono in Unity (with .NET 3.5 support) or the new Mono runtime (with .NET 4.6 support). In Unity 2017.1, the default setting is to use the older version of Mono. Soon (maybe the 2017.2 release of Unity) we will make the new Mono runtime default, with the old runtime as an option. Later still, we will remove support for the old runtime. More details will be coming in a blog post soon, but we wanted to let everyone on this forum know first.
We really appreciate the time, effort, and feedback so many of you have provided to move this process forward. Our team is focused on shipping the Mono runtime upgrade to all of the Unity users without breaking things. The work you have put in to find many of the things that did break is invaluable.
At this point we are not planning to ship more experimental preview builds via this forum. Instead, we will move back into the standard Unity beta cycle. I know that our last preview build suffered from some unrelated bugs in the Unity beta version we used. I would encourage anyone who still wants to use the Mono runtime upgrade to try the 2017.1 beta when it is released. I suspect the bugs from the 5.6 beta we last used here will be corrected, but you’ll find new and different bugs in the 2017.1 beta.
Unity ships beta releases about once per week. Any changes we have to correct issues with the Mono runtime upgrade will ship via those releases instead of via custom installs posted on this forum.
Awesome news! Can’t wait for it!
Do you know what will happen to Mono.Evaluator? It’s not part of the “normal” .NET framework, but since 4.6 will be supported…
Also, did you guys come up with any new ideas regarding package management? Maybe have some sort of custom nu-get repository or something and a simple tool built-in in the editor?
I’m not specifically familiar with Mono.CSharp.Evaluator, but I don’t see why it won’t work.
Another team at Unity is working on this, but I don’t have details about how it will look or when it will be ready. It is not a part of the Mono runtime upgrade though.
Can you share the version of the Mono runtime being upgraded to?
Does this version of the Mono runtime support .Net Standard?
Can we expect more frequent upgrades to the Mono runtime going forward?
We are currently using a branch based off Mono 4.8.
We will support netstandard 2.0 once it is finalized.
Yes, we’re intending to update as frequently as it makes sense given Mono and Unity release cycles.
Mono 4.6 supports .Net Standard 1.0 through 1.6. Since this upgrade was forked off of Mono 4.8, does that mean Unity will support 1.0 through 1.6 sooner than 2.0?
Does the upgraded runtime support ‘common’ .NET profilers? As in, the memory/garbage profilers, performance profilers. It’s a pain that current Unity versions do not support these.
For the 2017.1 release, Unity will only support the full .NET 4.6 profile (at least initially, we could add more support later). We’re not planning .Net Standard 1.0 through 1.6 support, because those profiles have a number of important things missing. It looks like 2.0 will replace them soon, with much wider support. So our focus is on .Net standard 2.0. We’ll have more details in the announcement blog post that will be coming soon.
We’ve made no changes for the elvis operator now. The behavior of classes derived from MonoBehaviour will be the same with respect to the “odd null handling” as it is with the old Mono runtime.
Sorry my wording wasn’t clear. I meant:
Will the updated version of the evaluator (that supports compiling classes, not just statements) be part of unity? (just like when I install mono manually from the mono website)
Or in other words: Will all assemblies that are part of a normal mono installation be part of Unity as well? Or will some assemblies be left behind (in time) because of some incompatibilities?
Package management, netstandard, semantics of Elvis operator — what a lovely thread! Nice to know I’m not the only one who is interested in all these things.