Unity C# 8 support

Damn right they do. And we're back to "they should have started much earlier". .NET Core should replace Mono on all platforms it supports — Windows, MacOS, and Linux —, no questions asked, including the editor. Mono should be upgraded for platforms that .NET Core doesn't support.

Put it this way: A .NET Core migration and DOTS are both very core things, but the objectively better one can't happen immediately because the less important one is already too big to fail and is taking a good chunk of the core engineers.
Stadia support, though, it doesn't look like it's maybe taking more than a few engineers away from either of the core things above — it's just a side project in comparison.

 

Unity is a big piece of software, has many teams and many developers, there are roadmaps, promises (Unity has a hard time complying with them anyway). In the end, focusing on just one thing and leaving something else behind can throw the entire Unity development back. You don't do something like this if it's not absolutely necessary. There are already enough developers who already rely on DOTS, also productive, and they would not be happy if you suddenly pulled the developers out of there.

So it was with Angular, the Angular Material team helped the main team to finalize version 9, but a feature that I've been waiting for has been postponed.

 

So editor performance in your mind is nowhere near the top of the priority list of things that desperately need fixing?

Maybe they shouldn't have started DOTS before runtime updates in the first place. Oh, look at that, we're back to "they should have done it sooner".

This isn't a small thing that a few people have been waiting for — it's essential, and final builds aren't even the most important thing here: how much time is wasted because the editor is cripplingly slow on anything remotely big? Domain reloads, anyone? Another essential thing: Several editor workflow improvements, some of which, like ReorderableList, SerializableDictionary, and list view for dropdowns, are small yet inexcusably never happened.

 

The problem with this that it is a non-constructive argument.
Yes, we all know.
They know.

And now what? How do we change the past? We don't. We have to cook with whatever we have right now. Unity as well.

Repeating this BS over and over on the forum does not add any value to the conversation only deteriorates it.

Besides, I think you throw the statements like "inexcusable" too easily.
Unity is still a great and quite capable engine.
Are they making some mistakes? Sure.
Are those mistakes sometimes annoying? Sure.

But inexcusable? Oh come on, it's not nuclear power plant.

 

Sure, let's stop these. What about the rest?

 

There is nothing "rest". They're working on it. Period.

You cast your vote a couple of times over multiple topics on the forum that you wish for more fast delivery of the new core. I think at this point everyone and their grandma' knows that it is important for you.

What else do you want? Do you want an answer from Riccitello himself that he's working on it? Or what?

Or do you plan pointlessly flood all the forums with your wish for more quick delivery of a feature you like?

 

I see that capturing context isn't your strongsuit.

No, he's about the last person I want an answer from.

Yeah, it's clear this isn't going anywhere.

 

Okay, will try to describe for you why there is no 'rest'.
You clearly have no experience in software development with very broad and heterogeneous user-base.
What you're asking for (halting development in favor of one feature) is dangerous, unnecessary and go against every single rule of commercial software development.

It simply doesn't work like that. And there are multiple reasons.

- if they did that, it would be (maybe further) alienate those people who are waiting for said features
- yes, maybe it would make you and three other guys happy (I seriously doubt it, you would find other reasons to throw the stones, like your "inexcusable" things from the "pain-thread"), but from the company's point of view, does it worth to please you? no...
- if you choose to halt all other development and tell all the engineer personnel to start work on the core migration, what is happening?
-- the original project leader probably commits hara-kiri on the first day, he or she gets multiple dozens of fresh engineers who has no clue what and where and why (there are exceptions, but in software development the exception means something went extremely wrong)
-- let's say over a month or so, the project can ramp up a couple of dozen people to work with them, great! yay! right? no.
---- maybe they can add some value, but not great value as they would stay on the original project
---- because they're always asking questions (nature of the beast when you're a newbie on a field)
---- because you can do some minor tasks, while the original core team is working on "the real thing"
---- some of the redirected engineers starts to be impatient and may leave the company or demand to get back to the features/part of the software they really like
---- some of them will make mistakes, because originally it is not the feature they were working on
Throwing new people on an ongoing urgent (and you want to go for urgency in this case) project in 90% of the cases not just doesn't help the problem, but it makes it worse.

Having a giant mass of software developers/engineers does not mean you can put them wherever you like.

Disclaimer: my day job is Software Engineering Manager. I'm responsible for a couple dozens of people and the work they do. I actually do this for a living.

 

Nope, this is where I bail. This is what, the third time? Although you have some good points, you're clearly ignoring the importance of the thing to prolong the discussion.

 

Because this "importance" is only in your head. In the real world, the truth is: it is a good to have feature, it would make the engine better, faster (in SOME cases - ops, it's really not that important already), but the engine is working without it for the time being.
So it is a P2 feature request.
(Priority 5 is the yeah, well, nice feature request, we probably will never do it, Priority 2 is the normal, we work on it as soon as it is feasible, P1 - problem actually hinders a sizable group of users, P0 - showstopper, most of the users are blocked from using the software).

 

Wrong, the modern C# is very clever with memory and puts often used items together in memory so it reduces cache misses.

We are going to go back and forth about dots, if you write object orientated code properly you can reach the same performance as DOTS, this is a well known truth by experienced programmers in the field.

and at @Lurking-Ninja although you have good points about software development, and I also work professionaly in the field for many years, in this specific case I think you are not fully right.

The people that work on Burst are the best engineers Unity has, the top guys, that have a Lot of knowledge about C#, about the engine, and all the systems involved, they are sadly working on things that are not used by most of the customers. And from talking to other professional game developers using Unity, most are not jumping into the DOTS/ECS/Burst boat. because of many reasons you can find on this forum or to talk to people that use it.

This stuff is basically in development, and probably will be for another few years. and it sucks for people that put their business on the line for the golden promises that Unity made about DOTS.

The fact of the matter is that if they would fix up their core engine, and move to .net core. with the latest and greatest C# and Memory management, All projects, EVERYBODY using unity will benefit MASSIVELY from the performance uplift, in actual game code we are talking of at least 2x code speed up with up to 10x in some cases.

The reason I want to see DOTS/ECS/Burst on hold is actually because it's progressing, slow, and not finished any time soon, and even if finished will be used by a select few, if any. However those same engineers, those top engineers, they could use their knowledge and experience to move the engine to the modern days of C#, and it would not take them long, as example XoofX who is on the Burst team already did a first stab on it, If you give those guys a few months things will progress fast.

I just wonder when Unity will officially dare to say that the Burst/Ecs project was a mistake. and that they give up, It is clear that the team working on it is burned out on it, the progress becomes slower, and they are already working on it for 4 years...

 

This is about C# 8 and what I'm about to clear up is off topic so I won't make it long. DOTS isn't a separate thing it's the new Unity Core, so it's not something that was decided on lightly and can be thrown away like that. Every tool/feature is being made/remade for DOTS. For example the new Input System is being transitioned to DOTS, the new Terrain System is being developed on DOTS, and everything else Unity is making for the Editor will be DOTS based. It's not just for coding it's the new Engine Core.

 

The ECS development starts in 2017 or probably earlier, at this point the .NET core was still version 1.1, maybe early 2.0. Back then that was an option for Unity.

Burst exists since over 2 years and ist already over one year out of preview. I find the development of ECS somewhat slow, but better slow than a quick shot. ECS core should leave preview this year. Was announced at least last year.

We come here of topic, c# 8 also works with a more modern mono.

 

Unity is used for a lot of game types. These include games that stick around for years, or even a decade. The biggest example I can think of is Hearthstone. Backwards compatibility is of great importance to these companies.

Now I am all for great progress and letting big companies figure out their own restructuring when the code base changes, but ask yourself: would big companies even 'consider' Unity for a long-term game if their engine didn't promise backwards compatibility?

Backwards compatibility is intrinsically not about progress but about trust. As annoying as it is, these are valid concerns that any tech change needs to consider.

Now before you say it: no, I have no idea what's going on internally at Unity so I cannot make these claims, but so can't you dude. All I'm asking for is a little perspective.

 

I think the frustration stems from the heavy focus on DOTS with all of its associated incompatibilities, lack of editor and asset support, etc. and seemingly no focus on updating the core .NET runtime that would immediately benefit everyone. Just to be abundantly clear I'm talking about appearances only.

 

Runtime upgrade to .NET Core will have huge impact:
- better performance, RyuJIT
- modern GC
- native support for Span<T>
- easy runtime upgrades (probably)
- collectible assemblies

Collectible assemblies might allow much faster editor code reloads, because it won't be necessary to tear down and create new AppDomain, it will be enough to unload old scripting assembly and load new.

But I understand that this is huge change, which would require a lot of resources.
A lot of things must be changed:
- how Unity calls .NET code
- how it places arguments on the stack
- how it tracks references to objects
- support cooperative GC (that's why Unity still uses old "dumb" Boehm GC and not newer SGen)
- and support it on all current platforms

And these changes are not trivial, this means rewriting some core parts of the engine and probably long experimental period before they fix all the bugs. It's a very risky change, because it requires modification of core things that are in engine for a decade. On the other hand a risk associated with DOTS is only resources put into developing it.

As mentioned several times in this thread, .NET Core / RyuJIT won't magically solve all issues with GameObjects, it's components and references all over the memory. It will still be very slow compared to DOTS with Burst. Instantiating complex objects during play will still spike, there's no way around it in GameObject world.

DOD is incredibly useful for games and anyone can use it with or without DOTS. It's been successfully used by many games. Oldest game I remember was Dungeon Siege (2002) and from recent big games for example Overwatch.

I'm very happy that Unity is providing framework for DOD, which will make things easier for us.
Also looking forward to day when Unity is released with .NET Core runtime support.

 

Probably it's you who missed the point

When you modernize runtime, standard library and language — everyone will have this advantage.

When you contribute significant amount of resources to DOTS — only imaginary billion-agents game prototypes and cherry-picked synthetic benchmarks will show observable boost. Not average real existing games.

 

In 2020.2.0a13, I type some C#8 construct and let Resharper enable it for the project, it works but then, when projects gets reloaded by Unity, C#8 syntax is not supported anymore giving compilation errors !

How exactly can we enable it ?

Thanks

 

Well, I was about to update my post !

Currently, Unity does not complain, it compiles fine,

But VS does, when you rebuild the project:

Code (CSharp):

1. error CS8370: Feature 'using declarations' is not available in C# 7.3. Please use language version 8.0 or greater.

I have also tried to add a csc.rsp file with -langversion:8.0 but that didn't change anything.

 

Also, if you check the .csproj, it's still 7.3:

Code (CSharp):

1. <?xml version="1.0" encoding="utf-8"?>
2. <Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
3.   <PropertyGroup>
4.     <LangVersion>7.3</LangVersion>

 

I'm using Unity 2020.2.0a12 and have the same .csproj, "Regenerate Project files" doesn't fix. Api compatiblity Level ".Net standart 2.0".

 

I am using latest version of 2019 which is 16.6.1

 

Alright guys, until this gets fixed, here's a fix that sets all projects to C# version 8.0 !

Code (CSharp):

1. using System;
2. using System.IO;
3. using System.Linq;
4. using System.Text;
5. using System.Xml.Linq;
6. using UnityEditor;
7.  
8. internal sealed class EnsureCSharp8Postprocessor : AssetPostprocessor
9. {
10.     private static string OnGeneratedCSProject(string path, string content)
11.     {
12.         var document = XDocument.Parse(content);
13.  
14.         var root = document.Root;
15.         if (root is null)
16.             throw new ArgumentNullException(nameof(root));
17.  
18.         var ns = root.GetDefaultNamespace();
19.  
20.         var element = root.Descendants(ns + "LangVersion").SingleOrDefault();
21.         if (element == null)
22.             throw new ArgumentNullException(nameof(element));
23.  
24.         element.Value = "8.0";
25.  
26.         using (var writer = new Utf8StringWriter())
27.         {
28.             document.Save(writer);
29.  
30.             content = writer.ToString();
31.         }
32.  
33.         return content;
34.     }
35.  
36.     private sealed class Utf8StringWriter : StringWriter
37.     {
38.         public override Encoding Encoding => Encoding.UTF8;
39.     }
40. }

 

Anybody manage to get C# 8 features working properly? Using the script above I still run into errors. On 2020.2.0a15 and VS2019

https://i.imgur.com/NC4o0E5.png

edit: filed a bug report.

 

Although i haven't tried the new version yet, but i suppose that although unity now supports c#8 it does not support .net standard 2.1, just 2.0, so the actual types needed for this feature are not there. If this is the case, then you just need to add those types. You can use this as a nuget package https://github.com/bgrainger/IndexRange or just copy the source to your unity project. This is not an official microsoft package, but you can follow the issue here: https://github.com/dotnet/runtime/issues/28285 .You can verify if unity has those types, by trying to instantiate them through their classes like new System.Range

 

Do you guys have a roadmap publicly available for .net standard 2.1 / core/ .net 5 ? Or anything for supporting the new csproj format, or nuget packages?

 

I submited a bug report and was said
"As a potential fix in Unity Package Manager downgrade Visual Studio Editor to 2.0.0 (try upgrading to 2.0.2 too)."
Downgrading fixed the issue.

 

So, I updated to Unity 2020.2.0a15, and immediately wrote a switch expression and it worked. Nice!

The feature I wanted MOST from C# 8, though, was nullable ref types. Clearing all those superfluous null checks out of my code would be wonderful. Looking it up, I figured out how to enable it by editing the project file (see here: https://docs.microsoft.com/en-us/do...llable-references#upgrade-the-projects-to-c-8), and it worked! I suddenly got a couple hundred warnings throughout my code base about using things that might be null.

Sadly, editing the .csproj isn't a great option, because Unity auto-generates this file, and will overwrite my edit the next time it does so. So really, Unity needs a new option, presumably next to the ones that lets you select the scripting backend and API compatibility level, that will add this flag when it auto-generates the project files. Any chance we might get such an option soon? (Or, does it already exist, somewhere that I haven't thought to look?)

(Edit: I know I can put

#nullable enable

at the top of a file to enable this feature for that file. And that's what I'm doing for now. But would much prefer to just have it automatically on for all files in my codebase at all times.)

 

There is already an option for this — Directory.Build.props file:
https://docs.microsoft.com/en-us/visualstudio/msbuild/customize-your-build?view=vs-2019
Just put this MSBuild-file next to generated projects, and it will be implicitly merged to them (and won't be touched by Unity):

Code (csharp):

1. <Project>
2.   <PropertyGroup>
3.     <LangVersion>8.0</LangVersion>
4.     <Nullable>enable</Nullable>
5.     <NullableContextOptions>enable</NullableContextOptions>
6.   </PropertyGroup>
7. </Project>

 

You're in luck! Sort of, anyways. I think you can do something like this:

Code (CSharp):

1.  
2. using UnityEditor;
3. using SyntaxTree.VisualStudio.Unity.Bridge;
4. using System.Text.RegularExpressions;
5.  
6. [InitializeOnLoad]
7. public class ReferenceRemovalProjectHook {
8.    static ReferenceRemovalProjectHook () {
9.        Regex references = new Regex(@"\s*(<Reference Include=.(Boo.Lang|UnityScript.Lang).).*\s*.*\s*(<\/Reference>)");
10.  
11.        ProjectFilesGenerator.ProjectFileGeneration += (string name, string content) =>
12.            references.Replace (content, "");
13.    }
14. }
15.  

Obviously, this isn't the code that you want to do, but I used this to strip some references from the .csproj file. You may be able to use it to add your changes to the file as well.

 

Thank you! This worked perfectly.

And is quite preferable to adding a hook to Unity that does a regex replace on the completed project file, though I do appreciate the suggestion, sand_lantern.

 

Wait, I take that back... I did this, and started updating a bunch of my files to use nullable references where I actually want nullability, and then Unity hit me with a ton of warnings in the form:

So apparently, Unity is going to be actively unhappy unless I put the

#nullable enable

at the top of every file. I guess I'll have to go back to doing that for now.

Josh Peterson: Any chance we'll get an option soon to allow Unity to just have nullability turned on universally?

 

Does the Unity implementation of C# 8 support default interface implementations?

 

Can we get any idea of an ETA? Even if it's preview, this is a game changer. Thanks

 

Default interface implementation requires .NET runtime update.

To support that, it's likely that this needs to be done:
1) Use version of mono which supports that or use different runtime (.NET Core)
2) Add support for that into IL2CPP

Nice under-the-hood article:
https://mattwarren.org/2020/02/19/Under-the-hood-of-Default-Interface-Methods/

 

It's unlikely that they will shift runtime to .NET Core when they will have to shift again to .NET 5 after November, would be nice if we can get the feature ahead of .NET 5 support though. Should be supported under a .NET Standard 2.1 runtime if we get that uplift from 2.0

 

@JoshPeterson Are there any plans to introduce Nuget support? I'm constantly in dll hell in Unity for literally no reason. Having to manually resolve dependencies is a massive pain point for a lot of developers.

 

I'm aware of this package, it however breaks Unity when a package has a dependency on a package that comes as part of Unity, effectively because you will then have 2 versions of that assembly. Mainly happens with dependent System packages.