Godot: Update the target .NET version

Created on 25 Feb 2018  路  15Comments  路  Source: godotengine/godot

Godot version:
3.0.1rc

OS/device including version:
Windows

Issue description:
The Visual Studio solution created by Godot in Windows references the .NET framework 4.5. This causes issues when you want to reference libraries built with .NET 4.6+
As far as I can tell there's no reason not to set the target .NET framework version to 4.6.2.

Steps to reproduce:

  • Create a project
  • create a cs script
  • run the game
  • open the project solution
enhancement mono

Most helpful comment

Right now, the plan is to switch to .NET Standard before .NET 5 comes out.

All 15 comments

CC @neikeq

We are targeting .NET 4.5 for now. Nothing prevents you from editing your project file to change the target framework (Godot won't overwrite your changes), but only 4.5 is tested.
The plan is to either target .NET 4.6/4.7 or .NET Standard 2.0 by default in the future (this could be a good place to discuss which one to go with).

How is the discussion leaning? I believe it is most beneficial to target .NET Standard 2.0. MS will likely drop Mono support when .NET Core has more platform compatibility.

DISCLAIMER: please correct me if I am wrong. I am far from being a .NET guru, and with several versions of .NET Standard around it's hard to find definitive informations.

Choosing .NET Standard would have some obvious benefits:

  • Users could choose themselves which runtime to use
  • The format of the project files is a lot simpler in Standard (or Core) than in Mono or .NET Framework
  • .NET Core provides cross platform command line tools for creation and manipulation of .NET Standard projects

I find the last point especially interesting, since it would allow to delegate the project creation to a third party tool instead of having to create the project file from code. I was puzzled to find that there's no tool like msbuild in the .NET framework that would allow you to create a project from the command line.

This would not only simplify the Godot code base, but it would also make it less dependent on assumptions, because for example with the current solution it's unfeasible to use F# on any platform other than Windows, because you would have to get hold of an existing F# .NET framework project file (which has a different structure from a C# project but is about equally verbose) and then reference it by editing the C# project file while replacing the UUID in the copied F# project file.

On the other hand it's hard to tell what the downsides of .NET Standard are. All I can find is that .NET Standard is a subset of the newest specifications of .NET Framework, Core and Mono, and that it focuses on platform independent parts, so there is a chance that for example something like Windows Forms may be missing. I can't judge however if this is going to matter. Windows Forms for example is probably something no one is ever going to need inside a Godot application. And if they do it's probably still easy enough to change the Godot project manually from .NET Standard to Mono, or to have a Windows Forms app communicate with the Godot app.

@umbravi : I wouldn't be too sure about that. .NET Framework, Mono and .NET Core have distinct goals: the framework focuses on Windows, Core focuses on the platform independent parts of the library and Mono is meant to reimplement the whole framework in a multiplatform way. From what I can tell Windows Forms is missing from .NET Core for a reason and it sounds plausible that it will never become part of it.
If Mono was to be dropped that would mean that .NET Core would have to fulfill its role, and that would slow down the development of the framework and Core. With Mono in the middle you can pick the framework for up-to-date Windows projects, Core for up-to-date multiplatform projects or Mono for porting applications from Windows to other OSs, but then you'll have to accept if a feature you may require isn't available in Mono yet.

@neikeq it's okay to target whatever framework version you like yet, it's not okay that there are no links or guides on how to get the mono version of the engine to work properly for people that have little time to waste on crashes and non-compiling solutions. That's just my humble opinion after wasting half my Sunday morning without success. To be more specific:

I'm using 'Godot_v3.0.2-stable_mono_win64' I installed 'mono-5.4.1.7-x64-0' and replaced my previously up to date .net framework with 'dot Net 4.5' (an action that broke 3 other programs that I use daily) and it's still not working...

@KoukouStudios That's unrelated to targetting .NET 4.5, which is also provided by more recent versions of mono 5.x. The issue you're describing is a "simple" distribution issue, which is being worked on for 3.0.3 (it's simple in the concept, but not simple to fix properly when supporting many platforms as we do).

Please keep in mind that the current Mono binaries are alpha, have known bugs. There are many things to sort out to get a fully functional Mono distribution that will run everywhere, while being able to export games and pack in the relevant Mono DLLs, and such things take time (which is again why the Mono builds are labelled alpha).

@neikeq thanks for the reply.

I managed to solve both crashes and failed compiles by installing Visual Studio community and the ".Net desktop development" pack that comes with it. I don't know what's included that Godot requires but mono 5. and .net 4.5 as mentioned on the official website are certainly not the only ones.

It would be really nice if in the future Godot(mono) could direct you to the download pages of each required package after scanning your system and before it starts. That would certainly save the user a lot of troubleshooting time.

@KoukouStudios Visual Studio shouldn't be required after #18522 and #18561. Installing Build Tools for VS 2017 should be enough.
The reason there is no documentation for installing the right mono version for the engine to work properly is because you shouldn't need a specific version as long as it's not lower than the minimum supported one. Of course, that's not the case, but it's a bug not the intended behavior. It will be fixed by shipping Godot with a minimal mono installation.
We may as well ship with MSBuild and Roslyn, for compilation, but that's yet to be decided. It would be useful to avoid problems with the MSBuild packages on some distros.

Sadly, my time is very limited until mid June but, after that, I will put all my time into a stable version that works out of the box. That is the priority. You can read #18364 for more details.

Thank you very much for the detailed info @neikeq. Very appreciated.

Wouldn't it be wiser switching to .Net Core, given that Microsoft has stated that the Net Framework will stay in maintenance from 4.8 onwards which will be the last major release of the classic Net Framework?

https://devblogs.microsoft.com/dotnet/net-core-is-the-future-of-net/

Is there a possibility to target NET Standard 2.1? https://github.com/dotnet/standard/blob/master/docs/versions/netstandard2.1.md

Right now, the plan is to switch to .NET Standard before .NET 5 comes out.

Can someone update me what will happen to this decision at the end of version 3.2 and what will we target starting Version 4.0?

@neikeq Can someone decide to which milestone (3.2 or 4.0) this issue belongs?

Related issues closed and still open but could be closed but I am unclear of the decision

Can someone update me what will happen to this decision at the end of version 3.2 and what will we target starting Version 4.0?

@neikeq Can someone decide to which milestone (3.2 or 4.0) this issue belongs?

NET 5 is coming out somewhere Nov 2020 so I don't think it's necessary to pin this issue on an exact milestone. Besides that shouldn't this change be backported anyway since it just applies NET Standard compatibility?

With 3.2 we changed the default framework version for projects to .NET 4.7. With 4.0 we will be switching to new project SDKs and .NET Standard (can't say anything about .NET 5 yet as there isn't much info). The changes won't be backported to 3.2.x because they're too big.
I'm closing this issue as it was about upgrading to .NET 4.6+, which is already done. For .NET Standard we have godotengine/godot-proposals#339.

Was this page helpful?
0 / 5 - 0 ratings