NetStandard 2.1 support

[yigitgursoy]

Describe the project you are working on:
A game project which uses gRPC client-server communication

Describe the problem or limitation you are having in your project:
I'm unable to use NuGet packages that require .NETStandard 2.1 compatibility such as Grpc.Net.Client. Godot currently is compatible with .NETFramework,Version=v4.5. which is unable to support this version.

.NETStandard compatibility is key to having a good c# ecosystem.

Describe how this feature / enhancement will help you overcome this problem or limitation:
Mono 6.4 comes with .NETStandard 2.1 compatibility. A better option would be to use .Net Core 3.0 which also supports .NETStandard 2.1. Unity is planning to switch to .NET 5 when it comes out next year. Having .Net Core 3.0 support would make this kind of upgrade easier for Godot.

Show a mock-up screenshots/video or a flow diagram explaining how your proposal will work:

Describe implementation detail for your proposal (in code), if possible:
N/A

If this enhancement will not be used often, can it be worked around with a few lines of script?:
There isn't a workaround that I know of.

Is there a reason why this should be core and not an add-on in the asset library?:
This is a proposal to upgrade core functionality.

[neikeq]

From #315:

I plan to switch both to project SDKs and to .NET Standard 2.1 sometime Q1 2020.

There isn't enough information about .NET 5 yet for me to make any decision on it.

[dioptryk]

I've been developing in .NET for more than 15 years now, and greatly prefer GDScript to Mono, because of 1) MUCH faster startup, and 2) .csproj file regeneration after adding a script through Godot UI, which is a major PITA (exactly like in was/is in Unity). Dropping Mono in favor of .NET Core would deal with 2) at the very least.

[neikeq]

@dioptryk The csproj is not regenerated like in Unity. We just add the new include without touching anything else.
Also this is not about Mono vs CoreCLR. Mono supports project SDKs just fine, Godot simply isn't using them yet (this will change soon, see #315). If we weren't using Mono, we wouldn't be able to target Android, iOS nor WebAssembly.

[yigitgursoy]

I love that Godot isn't touching the sln file. I'm able to add class library projects to the solution without Godot overriding my changes. (Unity owns the solution file, which is really annoying.)

One small improvement though would be to be able to change the path of the sln file :)

[GeorgeS2019]

From issue

I plan to switch both to project SDKs and to .NET Standard 2.1 sometime Q1 2020.
We will use our on SDK on top of Microsoft.NET.Sdk.

There isn't enough information about .NET 5 yet for me to make any decision on it.

@neikeq To get a glimpse of .NET 5 and how mono will be shaped along with it, I recommend Miguel de Icaza's recent Sep2019 talk that "the .NET future he wishes for many years is finally here"

If I am not wrong, MONO will be split to TWO development track under .NET 5

• Mono for cross platform desktop (Linux, Windows, MacOS etc) and Web will focus on performance and Web-Assembly
• Mono-lite for mobile cross platform (Android, iOS etc)

Currently, I am blocked like @yigitgursoy ->

• we need to have assess to .NETStandards 2.1
• we need SDK project format

Please let us know what are you concern and I will try to lobby people to help. I know my limited skills :-)

[jasonswearingen]

switching to .NET Standard 2.1 wouldn't mean moving to .NET Core, or .Net 5.

@neikeq regarding .NET 2.1 support, isn't Godot already on Mono 6.4 and the new MSBuild? If so, then I would hope that switching from .NET 4.5 to .Net Standard 2.1 would be straight forward.

I also am semi-blocked by this. .Net Standard 2.1 represents a pretty big API change, see here: https://devblogs.microsoft.com/dotnet/announcing-net-standard-2-1/

Specifically, there is a lot of performance enhancements (Span, ValueTask) That will help game development scenarios.

[jasonswearingen]

I did some more research, and from a development standpoint, you can use a lot of nuget packages to emulate .NS2.1 features such as Span and ValueTask (though some, like SIMD can not). Still, there may be some heavy refactoring to convert your code to .NS2.1 once godot upgrades.

also, in case anyone is curious, Unity is still 2+ years out from upgrading, due to their heavy reliance on a .NET Framework 4 based codebase.

[GeorgeS2019]

@jasonswearingen I think the team has decided to upgrade to SDK project format and adopt .NETStandard 2.0 or 2.1 once the 3.2 is done. A few days back, there were 300+ issues. Now only less than 200 issues in 3.2

We need to start gathering developers who are keen on this .NETStandard

We may need to identify them through discord platform as well.
Some of them perhaps have experience compiling and we could exchange views on possible issues moving towards NS2.1

I am sure it is a question of WHEN.

The team is interested with good performance WebAssembly through mono 6.6 and this is the focus of .NET5 with AOT Mono.

FYI Before NOV 2020, we will keep using .NET Core 3.1, there is separation of Mono from .NET Core. By Nov 2020, .NET5 is expected to be official. There is no more .NET Core or Mono with AOT as both are merged into .NET 5.

As long as Godot depends on Mono and the goal of developing high performance AOT webassembly. .N2.1 and SDK project is inevitable. It is only a question of WHEN!

I think the team needs us to keep the discussion so the information serves as a good feedback.

So keep up with your research. :-)

[GeorgeS2019]

@jasonswearingen can you please check if I am correct. .netstandard2.1 is supported by mono 6.4 and above BUT not supported by any .NET framework So the godot csharp projects under mono may need to be upgraded from .NETFramework 4.5 to non .NETFramework (e.g. .NET Core 3.1)

[jasonswearingen]

correct regarding .NS2.1 not supported by .NF4.5:

.NS2.1 changes all the coreclr API's to support Span and Memory, which is actually of MOST benefit to game developers (ie: godot!) because these are all improvements for performance.

If this change can occur, it'd be very exciting! It would allow future changes to godot's api to support high performance in a "managed" way:

• expose the unmanaged location/physics via something like Span<Matrix>
• passing Span<Char> to avoid string object generation)

incorrect regarding the godot mono project "upgrading" to .NC3.1:

The godot project would want to be changed to a .NS2.1 "library". This would allow it to be run on mono or .NC3.1 . If the godot project targeted .NC3.1 it wouldn't be mono compatible.

[GeorgeS2019]

@jasonswearingen Here are the cSharp projects for DLL need to be in [GodotMono.exe-RootDir]\GodotSharp\Tools
Can someone feedback? Do these DLLs all need to be in .NETStandard2.1. If so, not sure it is possible to compile GodotTools.ProjectEditor.dll to .NETstandard 2.1 due to dependency issues.

Please check, perhaps I am wrong

[jasonswearingen]

All associated dependencies would need to be built using .NS2.1, you can't link a .NF4.5 library from a .NS2.1 project.

Sorry I don't have a godot build (I'm just using the prebuilt binaries) so I can't play with recompiling.

[GeorgeS2019]

==> netstandard2.0 Log -- It crashes and I am trying to figure out WHY.
==> I will update this next few days.
==> First testing with netstandards2.0 first because some of the dependencies dll e.g. microsoft.build does not support .netstandard2.0.
==> it is not that trivial. However, I think I have a better ideas what challenges ahead, we need to discuss what paths to take.

Prepared to set up assembly 'GodotSharp' (C:\godot\bin/GodotSharp/Api/Debug/GodotSharp.dll) (in domain Mono, info)
Assembly GodotSharp[0000022E10861F80] added to domain GodotEngine.Domain.Scripts, ref_count=1 (in domain Mono, info)
Loading reference 0 of C:\godot\bin/GodotSharp/Api/Debug/GodotSharp.dll asmctx DEFAULT, looking for netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51 (in domain Mono, info)
Config attempting to parse: ''. (in domain Mono, info)
Image addref netstandard[0000022E10862EB0] (asmctx DEFAULT) -> C:\godot\bin/GodotSharp/Mono/lib/mono/4.5/Facades/netstandard.dll[0000022E10A73790]: 2 (in domain Mono, info)
Prepared to set up assembly 'netstandard' (C:\godot\bin/GodotSharp/Mono/lib/mono/4.5/Facades/netstandard.dll) (in domain Mono, info)

[jasonswearingen]

@GeorgeS2019 any progress on this?

From your last comment, FYI everything needs to be switched to .NS2.1. Anything referencing mono 4.5 is going to fail. .net (any version) only supports up to .NS2.0. The last line "netstandard.dll facade) is a .NS2.0 facade used by the .NF

[GeorgeS2019]

@jasonswearingen please see candidate-godot-3-2-rc-3 in particularly Mono: Default to net47 for new projects (GH-35473) by @neikeq

It seems according the neikeq, only 6 files need to be modified moving from net4.5 to net4.7

I have tried changing to net4.7.2 to support .netstandard2.0 according to the link below

2 The versions listed here represent the rules used by NuGet to determine whether an existing .NET Standard library is applicable. Although NuGet sees the . NET standards 1.5 through 2.0 are supported by the .NET Framework 4.6.1, but there are several issues with using .NET Standard libraries created for these versions from .NET Framework 4.6.1 projects. For .NET Framework projects that rely on these libraries, we recommend that you upgrade the project to the target platform .NET Framework 4.7.2 or later.

[jasonswearingen]

That change is really just cosmetic. you could always change your game's project to .NF4.7 manually, and everything would work. (That's what I did)

From a runtime perspective, there isn't much difference between libraries that are .NS2.0 .NF4.7. They all will run the same.

However, there is a huge difference between a .NS2.0 and a .NS2.1 library. They are runtime incompatible due to a completely rebuilt BCL (core standard library)

[jasonswearingen]

@neikeq is there any work being done to move to .Net Standard 2.1, or if not, could you please outline any known challenges such an attempt would face? I wouldn't mind giving this a try, but if theres already a roadmap for it in place I would rather not duplicate the effort.

[neikeq]

I plan to make this happen after 3.2 stable is released. Right now, I'm focusing on my current roadmap tasks and fixing the remaining 3.2 issues.

[GeorgeS2019]

@jasonswearingen It is great you are pushing .NET standard 2.1 and certainly it is too of high priority from my side and I believe too for many c# developers.. Could you share any thinking from your side what is needed to plan a path towards .NET standard 2.1? We may be able to move faster if we pool our thinking hats together and learning from each other.

[GeorgeS2019]

@jasonswearingen

Anything referencing mono 4.5 is going to fail. .net (any version) only supports up to .NS2.0.

Have you check how [mono 6.4 and above ] (used by Godot3.2) support .NETStandard2.1?

[jasonswearingen]

The main benefit that .NS2.1 provides is Span support integral to the .net core API's. Span is basically a struct wrapping an IntPtr, Type, and length. So to take advantage of it godot would need to support workflows previously considered "Unsafe", allowing c# users to pass/get Span for high performance

@neikeq the following paragraph might be useful to think about (?? sorry to blah blah so much, I know you have a lot on your plate....)

Span based api's

Span<T> based overloads can be added without breaking current API's. The sensible approach is to determine high-performance scenarios to optimize firstly. For example, Vector3[] MultiMesh.TransformArray is a property. This requires copying the entire Vector3[] array from the managed heap to native every change (and if any instance moves, it could be every frame). If a Span<Vector3> MultiMesh.GetTransformSpan() function were added, it would allow the "high performance" c# code to modify the needed instances' transform directly in native memory, without the marshal roundtrip and array copy.

Have you check how [mono 6.4 and above ] (used by Godot3.2) support .NETStandard2.1?

@GeorgeS2019 Honestly I have been too busy learning gamedev+godot basics over the last few weeks, things like writing a basic camera and shaders. I want to get a credible tech demo working before I "demand" c# runtime /api improvements :)

[GeorgeS2019]

@jasonswearingen Please just keep on feedback whatever you think could be of interest, no matter how small it is. Every feedback keeps the godot community "food for thought" how to improve.

I had a brief chat with @neikeq and he gave me good tips.

[GeorgeS2019]

FYI Will Unity3D support .NETStandard 2.1 status Oct2019

I will not be surprise that the challenges faced Unity3D to support .NETStandard 2.1 may not be too different from us :-) because there are a few moving parts that needed to be sorted out first.

It will be great to have SDK style project with this feature.

[evelant]

I just ran into this as a new user unfamiliar with the .net ecosystem. I found a nuget package I'd like to use with Godot but it requires .NETStandard 2.1. Is this something where most nuget packages aren't going to work with Godot until an upgrade happens or is it only a small subset of things that won't work? If lots/most nuget packages won't work maybe it's worth adding a note about this to the docs?

[neikeq]

@AndrewMorsillo This pages recommends to target .NET Standard 2.0 for the best compatibility. I don't know the real stats though.
We will be switching to .NET Standard 2.1 in Godot 4.0 (or to .NET 5, but it's too early to tell).

[GeorgeS2019]

@neikeq @Calinou @AndrewMorsillo With the recent merging of Visual Studio 2019 as an external IDE for 3.2.3 by neikeq, it is now possible to test many C# and .NET concepts not so easy before.

Currently, I am evaluating how to implement the .NETStandard 2.1 and the .NET5 SDK style project.

It is early stage. Good for learning GodotSharp Tools environment

Immediately, we need to ask if there is interest for the VS Solution to support more than ONE csproj projects and how we are going to arrange the Csharp files within the Godot projects.

Ideally, we have all csproj files within a root folder (e.g. Scripts). Within this Script directory, we have one folder for each of the csproj project. Within each csproj folder, we can then implement the SDK style csproj without listing all the csharp files associated with the SDK style csproj, to achieve one of the benefits of the SDK style projects.

REF Godot Proposal: Support multiple .NET5 SDK style projects per godot project