.Net 5 support

How would that work when using standard net api that accepts span<T>?

 

Hmm I was wrong, it can be done as follows:

Code (CSharp):

1. Span<byte> bytes;
2. unsafe
3. {  
4.     byte* tmp = stackalloc byte[length];  
5.     bytes = new Span<byte>(tmp, length);
6. }

 

This is a C# 7.2 feature, not C# 8. It just compiles down to a regular stackalloc which gets passed into the Span<T>(void *, int) constructor, so it works fine with the System.Memory package. C# 8 further expanded stackalloc to allow it to be used as an expression (which always returns a span).

The System.Memory package implements what's referred to as "slow span", which looks something like this:

Code (CSharp):

1. readonly ref struct Span<T>
2. {
3.     readonly Pinnable<T> pinnable;
4.     readonly IntPtr byteOffset;
5.     readonly int length;
6. }

This allows it to function perfectly fine without explicit runtime support (so it also works fine in Unity), at the expense of performance (and the ability to store a GC-tracked "ref").

 

Well then that's even worse and C# 7 isn't fully added to Unity. As I said missing packages that contain Span, ValueTask etc makes these features unsupported in Unity, right @JoshPeterson ? By unsupported I mean that any found bugs will be marked as postponed, by design etc.

 

Yeah, in a way. It's similar to how C# 8 technically isn't fully supported because we don't have the runtime changes needed for default interface implementations.

 

Span<T> is only a new Library Feature, not defined by the language. Default interface implementations is an language and runtime feature.

 

Span<T> is present in the C# specs and there's specific language support for stackalloc (among a few other things), which makes it part of the language as well.

 

Yes, C# 7.2 has a special case for Span<T>. But Span<T> is not included in .NET Standard 2.0 or any of .NET Framework versions. This is probably the first and last example when a new language version feature requires new type but the type is not included in the target framework.

All .NET Frameworks, .NET Standard 1.x, .NET Standard 2.0 and .NET Core 2.x use C# 7.3 as default language version. But only NET Core 2.1 and 2.2 have Span<T> included. All others require nuget package.

Similarly Unity require Span<T> from somewhere outside because it's support level is .NET Standard 2.0 or .NET Frameworks 4.x

 

NET Core 2.1+, NET Standard 2.1 and NET 5.0.

Seems like fast span was added to mono https://github.com/mono/mono/issues/7249 in 2018

#edit
Oh I've missed this one:

 

I count only Target framework that use C#7.3 by default and have Span<T>

 

I' not sure why are you quoting me here and in what way your response is relevant. If I wanted to go unsafe and into pointer madness I always could do that directly since early C#. The whole idea of span is that it was a fairly convenient, surprisingly good and low-overhead abstraction.

 

Have you read what you asked?

As

Span<byte> bytes = stackalloc byte[]; 

is C# 7.2 feature not C# 8, you send Span directly to the api, not sure what you asked about.

 

Have you? Let's see:

Where did I say otherwise? Where did I even talk about it?

It does not work out of the box, as Baste said:

To which I've asked:

and your response:

What unsafe context and pointers have ANYTHING to do with built in core .NET 5/Core libraries native Span abstraction implementation with stackalloc?

 

On another note, I think it's useful to mention that the default implementations of Stream.Read(Span<byte>) and Stream.Write(ReadOnlySpan<byte>) use ArrayPool and then call the regular managed array implementations. So even without .NET Standard 2.1 you can take advantage of them using extension methods:

Code (CSharp):

1. using System;
2. using System.IO;
3. using System.Buffers;
4.  
5. // Based on https://source.dot.net/#System.Private.CoreLib/Stream.cs
6. public static class SpanStreamExtensions
7. {
8.     public static int Read(this Stream @this, Span<byte> buffer)
9.     {
10.         byte[] sharedBuffer = ArrayPool<byte>.Shared.Rent(buffer.Length);
11.  
12.         try
13.         {
14.             int numRead = @this.Read(sharedBuffer, 0, buffer.Length);
15.  
16.             if ((uint)numRead > (uint)buffer.Length)
17.                 throw new IOException("Stream was too long.");
18.  
19.             new Span<byte>(sharedBuffer, 0, numRead).CopyTo(buffer);
20.             return numRead;
21.         }
22.         finally
23.         {
24.             ArrayPool<byte>.Shared.Return(sharedBuffer);
25.         }
26.     }
27.  
28.     public static void Write(this Stream @this, ReadOnlySpan<byte> buffer)
29.     {
30.         byte[] sharedBuffer = ArrayPool<byte>.Shared.Rent(buffer.Length);
31.  
32.         try
33.         {
34.             buffer.CopyTo(sharedBuffer);
35.             @this.Write(sharedBuffer, 0, buffer.Length);
36.         }
37.         finally
38.         {
39.             ArrayPool<byte>.Shared.Return(sharedBuffer);
40.         }
41.     }
42. }

You can't override these methods like you can with the real ones since they're extensions, but it's nice to be able to at least make use of them.

 

I'm done, you clearly don't know how to ask a question.

 

I'd just like to point out that a solution to bring .NET 5 C# to Unreal Engine exists in the form of a plugin.
https://github.com/nxrighthere/UnrealCLR
I'm looking into using it right now to see if it's usable, but first impressions look promising.
All in all, Unity is running far behind, but I don't think I need to tell you that. ^_^

 

You could theoretically do something similar to that in Unity by P/Invoking nethost/hostfxr, but I'd much rather have native support.

On that note, I wonder how feasible it'd be to have an open source Mono wrapper around .NET Core similar to what xoofx did here: https://xoofx.com/blog/2018/04/06/porting-unity-to-coreclr/

Unity's fork of Mono is open source, so if they've made any changes to existing APIs (or added new ones) then the details are known.

 

@JoshPeterson couldn't help but raise an eyebrow at this:

What exactly is keeping Unity from implementing breaking changes to the ecosystem? The primary reason that comes to my mind would be maintaining compatibility with in-production projects, but this is what long-term support releases are for, no? To my understanding, migrating projects across TECH cycles is generally discouraged, so why should developers expect their current projects to port smoothly from, say, 2020.3 LTS to 2021.1?

The only other reason I can think of is stopping breaking changes from happening to the engine itself and having to fix those in time for the next TECH cycle, but surely the team can plan more than one year ahead, right?

It just feels like Unity is trying to revamp and modernize very quickly while also treading as lightly as it can. The way I see it, these two goals are diametrically opposed.

 

May be they plan to move away from c# and mono/.net in future so that's why they dont want to bother?

 

No way they will do that. They removed unityscript to focus in C#, ditched the mono compiler in favor of Roslyn, and have designed Burst around making C# more performant.
There's no reason for them to suddenly abandon this path

 

they abandone .Net Core in favor of .Net 5

 

.NET 5 is an evolution of .NET Core, it's not like thy would suddenly drop everything and rewrite the engine in ruby or something.

 

Guys, follow unity devs' twitter to get more info about this directly. There is an interesting discussion about this particular subject last week.

 

Projects in production, Long Term Projects (KSP startet with Unity3.x, currently at 2019.2). Internal Unity code/packages. Asset store...

 

What about NET Standard 2.0 assemblies - are they compatible with NET 5? If they are then everyone should be aware of it as early as possible. Let everyone know to target NET Standard and if not possible prepare to recompile them for NET 5 in the future.

Would be interesting to see how many Asset Store assemblies target Net Framework - I guess this information should be clearly visible for every asset in the future to know if they're Net 5 compatible.

 

Okay fair point, honestly. Now what exactly do you mean by a "full solution"? Or perhaps a better question would be what still needs to be done with the engine internally for the team to consider the migration experience straightforward enough to be willing to make the jump to
.NET Core?

 

This is what the .NET Core Hosting API is for.

 

Another question that could be asked in a poll (and separate one directed to 100k$+ companies) is if they are even updating their projects to newer Unity versions. From my experience most of them were stuck to older Unity versions to avoid random bugs. Cross-project plugins were specifically made to work with all versions.

Looks like there's a tool that analyzes if dlls could be ported to net5 or standard without issues.

Sometimes it gives hints how to replace them:

I guess this means that AppDomain is kind of implemented in NET 5.


Running from project inside Unity:
Download https://github.com/microsoft/dotnet-apiport (ApiPort Download) and change pathToApiportExe below:

Code (CSharp):

1. using System.Collections.Generic;
2. using System.Diagnostics;
3. using System.IO;
4. using UnityEditor;
5. using UnityEngine;
6. using Debug = UnityEngine.Debug;
7.  
8. public static class AnalyzeProjectReportNet
9. {
10.     [MenuItem( "Tools/AnalyzeProjectReportNet" )]
11.     public static void AnalyzeProjectReportMethod()
12.     {
13.         string pathToApiportExe = "YOUR PATH HERE Downloads/Apiport.2.7.0/net461/ApiPort.exe";
14.  
15.         int safePath = 1;
16.         string reportPath = Path.Combine( Path.GetDirectoryName( Application.dataPath ), "AnalyzeProjectReport.html" );
17.         while ( File.Exists( reportPath ) )
18.         {
19.             reportPath = Path.Combine( Path.GetDirectoryName( Application.dataPath ), $"AnalyzeProjectReport{safePath}.html" );
20.             safePath++;
21.         }
22.         string command = $"{pathToApiportExe} analyze " +
23.             $"-f \"{Application.dataPath}\" " +
24.             $"-t \".NET\" " +
25.             $"-t \".NET + Platform Extensions\" " +
26.             $"-t \".NET Standard, Version = 2.0\" " +
27.             $"-t \".NET Standard + Platform Extensions, Version = 2.0\" " +
28.             $"-r HTML -o \"{reportPath}\"";
29.  
30.         RunCommands( new List<string> { command } );
31.     }
32.  
33.     public static void RunCommands( List<string> cmds, string workingDirectory = "" )
34.     {
35.         using ( var process = new Process() )
36.         {
37.             var psi = new ProcessStartInfo();
38.             psi.FileName = "cmd.exe";
39.             psi.RedirectStandardInput = true;
40.             psi.RedirectStandardOutput = true;
41.             psi.RedirectStandardError = true;
42.             psi.UseShellExecute = false;
43.             psi.WorkingDirectory = workingDirectory;
44.             process.StartInfo = psi;
45.             process.Start();
46.             process.OutputDataReceived += ( sender, e ) => { Debug.Log( e.Data ); };
47.             process.ErrorDataReceived += ( sender, e ) => { Debug.LogError( e.Data ); };
48.             process.BeginOutputReadLine();
49.             process.BeginErrorReadLine();
50.             using ( StreamWriter sw = process.StandardInput )
51.             {
52.                 foreach ( var cmd in cmds )
53.                 {
54.                     sw.WriteLine( cmd );
55.                 }
56.             }
57.             process.WaitForExit();
58.         }
59.     }
60. }
61.  

 

You could try CoreRT. I was able to compile System.Process to make it work in il2cpp that doesn't support it otherwise.

In my case I've made proxy C# library to few System.Process methods, compiled to native, used in Unity il2cpp with DllImport. I think it can also generate C++ instead.

 

It exists but I believe most of it is stubbed out and just throws. I recall reading that it's primarily there for compatibility with code that uses it to query loaded assemblies.

 

Yeah, I think there's a larger API surface you can access (although I forget the method), but even then there's other issues such as CoreCLR not supporting custom internal calls by default (which was mentioned in xoofx's article). Unity would need to reimplement that functionality or move things over to QCalls.

 

https://github.com/dotnet/runtime/issues/39798
"Advanced Embedding API in .NET5 like Mono"

There is an interesting issue.

 

so... is there any chance that we can get back a working Unity Analytics? Right now, the AnalyticsEventTracker is not exposed from the DLL and the editor is throwing errors on existing scripts.

care to share?

 

https://twitter.com/xoofx/status/1314510917221089281

 

Hmm... Maybe we don't need Burst to achieve C++ performance after all.

 

I have a question about update Roslyn version.
Unity seems to locate Roslyn compiler under "Editor/Data/Tools/Roslyn/".
I can easily use the latest preview C# compiler by replacing Roslyn compiler. (The runtime dependent feature cannot be used of course. I mainly use Target-Typed new, nint, and SkipLocalsInitAttribute.)

.NET 5 and the Roslyn compiler corresponding to C#9 will appear in November.
Are there any difficulties relating to update Roslyn?

 

I'm sorry. I would like to add a few things to what I wrote.
Is the Unity-Technologies' Roslyn update test a hard work?

 

The C#8 Roslyn compiler appeared in September 2019.
Unity-Technologies started using it on 28. May 2020(Unity2020.2.0a12 release date).
Unity-Technologies needs 8 months to update Roslyn.
I wonder how much the Roslyn update is difficult.

 

Thank you for the answer!
This is what I want to know!