Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update the target .NET version #17010

Closed
Warlaan opened this issue Feb 25, 2018 · 16 comments
Closed

Update the target .NET version #17010

Warlaan opened this issue Feb 25, 2018 · 16 comments

Comments

@Warlaan
Copy link
Contributor

Warlaan commented Feb 25, 2018

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
@akien-mga
Copy link
Member

CC @neikeq

@neikeq
Copy link
Contributor

neikeq commented Mar 10, 2018

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).

@umbravi
Copy link

umbravi commented Mar 24, 2018

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.

@Warlaan
Copy link
Contributor Author

Warlaan commented Mar 24, 2018

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.

@ioannis-koukourakis
Copy link

@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...

@akien-mga
Copy link
Member

@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).

@ioannis-koukourakis
Copy link

@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.

@neikeq
Copy link
Contributor

neikeq commented May 8, 2018

@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.

@ioannis-koukourakis
Copy link

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

@akien-mga akien-mga removed this from the 3.1 milestone Dec 17, 2018
@oliverw
Copy link

oliverw commented May 21, 2019

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/

@zetashift
Copy link

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

@neikeq
Copy link
Contributor

neikeq commented Oct 5, 2019

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

@GeorgeS2019
Copy link

GeorgeS2019 commented Jan 9, 2020

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

@zetashift
Copy link

zetashift commented Mar 5, 2020

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?

@neikeq
Copy link
Contributor

neikeq commented Mar 5, 2020

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.

@neikeq neikeq closed this as completed Mar 5, 2020
@neikeq neikeq added this to the 3.2 milestone Mar 5, 2020
@BinToss
Copy link

BinToss commented Jun 30, 2021

.NET 6 is scheduled to have it first production release this November.
Several changes from .NET 5 show a focus on cross-platform support

  • .NET Core, Mono, and Xamarin have been unified into one base class library and SDK/toolchain.
  • Xamarin.Forms evolved to become MAUI, a multi-platform UI framework.
  • Windows-exclusive features are still cordoned to the .NET Desktop platform. Official support for MacOS and Linux desktop applications are still under consideration.
    ...and much more

.NET Runtime 6.0.0-preview.5

Supported Platforms Supported CPU Architectures
Linux Arm32 ; Arm64 ; Arm64 Alpine ; x64 ; x64 Alpine
MacOS Arm64 ; x64
Windows Arm64 ; x64 ; x86
Language Support
C# 9.0
F# 5.0
VB 16.0

See Download .NET 6.0 for more info.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants