.NET targets

[WildWeazel]

Spinning off of #246 because this seems to be a larger issue than I realized.

At the start we were under the impression that Godot only uses Mono but that's not the case. Even some of the official docs now suggest using .NET (Core) SDK. What's really not clear is the implications for building, running, and testing with various target frameworks in our project files. Our current net472 target somehow works with Mono 6.12, but not .NET 5/6. However Mono does not provide a practical way to run unit tests. I had in mind to switch to netstandard2.1 which is supported by both and supposed to be the framework independent way forward, but that didn't work for me. And @JimOfLeisure tells me xUnit doesn't work with it either. To further complicate things, we think Godot will always package the build with its internal Mono implementation for runtime, which means that if you're using any other SDK you'll be using different frameworks between build/test and run! I think we need to do some research about how this actually works, and maybe talk to some experienced Godot people (or even the developers) to find out how to handle all this. Maybe @TinaFemea can shed some light on the compatibility issues.

[TinaFemea]

I'm not sure I'm terribly qualified to answer this, but I'll give it a shot. I haven't used Mono/Godot for anything, really, just .net in general.

.net standard is an interface. .net 5/6, mono, etc are implementations of that interface. This answer: https://stackoverflow.com/a/58273939/203870 has a good overview. In a nutshell, you can't run unit tests without an implementation.

I agree, I'd talk to Godot people about this. But in general, if you target .netstandard, as long as the Mono that ships with Godot is compatible with that, it should work just fine. You should, in fact, be able to move seamlessly between the .net472 and mono implementation.

And the difference between theory and practice is that in theory there is no difference. :)

[WildWeazel]

Ok, so after going down this rabbit hole it's all still clear as mud but the tl;dr for .Net Standard seems to be that it's only intended for reusable libraries that can target any implementation, and while not deprecated it's not really useful or recommended in the world of .NET 5+. Definitely not applicable to us, which leaves us with the TFMs for Framework, Core, and .NET.

[WildWeazel]

I had a chat with someone on the Godot discord who seemed to know what they were talking about, and confirmed:
Mono is only the runtime and includes no build tools, hence the need to provide your own.
As Mono is outdated, .NET 6.0 is the currently recommended SDK, with Build Tool set to dotnet CLI
net472 or netstandard2.0 are supported targets regardless of SDK, with test frameworks also supporting net472
Regular C# unit tests are unaffected by SDK choice, but unit testing Godot takes some legwork. Splitting UI and game logic helps avoid this.

So given that advice, I see no reason not to adopt .NET SDK 6.0 and target net472 as our project standards.

[QuintillusCFC]

FWIW, if I run dotnet --version, I have version 6.0.201. I believe this means I am using the currently recommended SDK.

I also have the Build Tool set to dotnet CLI, and it's working.

I think this does answer the previously-unanswered question of, "what version of the dot net CLI should we set as our standard?"

Now as this related to #246 , and to VSStub (which is discussed there, although not modified there)... VSStub is required for debugging in Visual Studio 2019, and uses the old format for C# projects. I tested switching it to net472 just now, but unfortunately, Visual Studio 2019 cannot load it with net472 instead of v4.7.2. As @WildWeazel mentioned in #246 , v4.7.2 appears to be the Windows-specific .NET framework. What I can't fully explain is why I can build with Dot Net CLI (with VSStub as-is), and WW requires Mono or MSBuild, but it may well be a Windows vs Linux difference.

My proposal at this point is to deprecate Visual Studio 2019 as a development environment, while keeping info on how to use it on our Wiki to preserve knowledge. VSStub will be removed from Development, and the latest version linked from the Wiki. Anyone who wants to use Visual Studio 2019 can add it locally. Eventually, Godot will likely update their Visual Studio support to not require old C# project formats, and to support Visual Studio 2022, and I suspect things will play more nicely then.

This takes into account that Visual Studio 2019 was originally added in December when Lanzelot was attempting to use it, and that until February/March, we didn't have a supported VSCode debug configuration, which we do now. Rider support was also questionable in late February due to the situation in Ukraine, but at this point they've divested from Russia, so we have two supported debug configurations, including a powerful IDE, without having to support VS 2019 and the compatibility headaches that causes. Finally, although I used VS2019 in February/March, I don't think anyone is actually using it at this time. Getting rid of that pain point seems like the sensible way to go.

[QuintillusCFC]

Bumping due to Preview 2 build issues.

On May 7, WildWeazel wrote, So given that advice, I see no reason not to adopt .NET SDK 6.0 and target net472 as our project standards. I agree that makes sense. But in #257, while the netstandard2.0 projects were moved to net472, the test projects were moved to net6.0, seemingly not aligning with the May 7 statement.

The commit's message is Change test project targets to net6.0 so unit tests pass with .NET 6, implying they didn't pass with net472.

But when they are set to net6.0, the GitHub Action to build the project fails, producing a build that just has the blank background with a non-working "Select Civ3 Home" link. Switching the tests back to net472 fixes the problem, and, at least on Windows (and presumably the build server, which is likely Linux) does not cause the tests to fail.

I never really followed why the tests were on net6.0 when everything else was on net472, other than presumably it didn't work on Linux otherwise for some reason. But now that the build server has voted with Windows (only pickier about net6.0), we have a problem with the tests being net6.0 that we didn't have earlier.

The solution could be changing the build server config so it is happier with net6.0, but I'm still confused about why we aren't all-net472 or all-net6.0.

In the meantime I propose we build Preview 2 with the tests set to net472 so we don't delay it any more. Longer-term we should also make the build actually fail when it fails, and run on each merge commit, but that's another topic.

Edit: Are we using net472 instead of net6 because that's what plays nice with Godot?

[QuintillusCFC]

We're likely using net472 because we're using this Docker image: https://github.com/aBARICHELLO/godot-ci which uses Mono, which imitates net472.

[WildWeazel]

You are correct: Mono only "knows about" net472 so building with Mono requires it. But then .NET 6 recognizes it as the old Framework. After my initial advice to use net472 I found in #257 that doesn't work for unit tests specifically, not because of the target itself but because .NET 6 can't find the required assembly System.Runtime 4.0.0.0. I didn't look any deeper than that. So Mono can't build for the target net6.0, and .NET 6 can't build tests for the target net472... at least on Linux. Since we are (as recommended) standardizing on .NET 6, that would imply finding a .NET 6 image for CI going forward, which hopefully with obviate all this.

[WildWeazel]

I don't see an issue/card for Preview 2, but if this is the only pending issue it looks good to me.

[QuintillusCFC]

The "as recommended standardizing on .NET 6" is "as recommended by Microsoft", right? Or is there a recommendation closer to our level as well? Given that Godot implies Mono, and Mono implies net472 (I think those statements remain correct?), I want to make sure I understand where the recommendation is coming from.

One the Linux dev VM is up and ready, it could also be worth looking into if there's a work-around for .NET6 with tests on net472. It could not lead anywhere, but at this point it looks like a coin flip to me whether it wound be easier to get that working, or to find/build a .NET 6 CI image.

[WildWeazel]

As recommended by the Godot community, which suggests that surely there's a .NET 6 CI solution out there already.
Can you build the current (net472) test projects with .NET 6 on Windows?

[QuintillusCFC]

Ah, that would imply a .NET CLI solution would probably exist, then.

The net472 test projects do indeed work with .NET 6 on Windows:

But the net6.0 version also worked on Windows.

I also found an issue in the godot-ci issue tracker that mentions this problem and provides a work-around: abarichello/godot-ci#80

So that's an option. Or finding another Godot CI solution. I don't know if the one we are using is official, it just seems to be popular. In a 5-minute search, I found a few alternate solutions, but none that advertises net6.0 support. So if the CI side is the desired place for a solution, and no one wants to dig deep into this, TheOrioli's workaround seems like it may be the easiest solution to me.

[WildWeazel]

Revisiting this again now that the VM is ready (with 6.0). I don't know if this directly helps us, but Ubuntu just added .NET to its default repositories, meaning that you can just run apt install dotnet6 out of the box.
We are at least in a state now that seems to be working for everyone. As odd as it is to have build and test projects with different targets, that's a small price to pay. As far as CI, I see 4 options:

1. Use a Godot image and install dotnet6
2. Use a .NET image and install godot-mono
3. Roll our own godot-dotnet image
4. Wait it out, as this should be a common use case by 4.0 at least

[WildWeazel]

I believe this is all now irrelevant with Godot 4. They will be mandating a minimum .NET target version going forward, starting with 8 in 4.4 projects.