CI for Linux editor builds with Mono installs .NET 6, but uses .NET 8

[YuriSizov]

Tested versions

N/a

System information

N/a

Issue description

Our CI setup for Linux editor builds with Mono has a step to install .NET 6:

      - name: Set up .NET Sdk
        uses: actions/setup-dotnet@v3
        if: ${{ matrix.build-mono }}
        with:
          dotnet-version: '6.0.x'

And it does do something. However, in the next step where we build .NET solutions, we don't actually use .NET 6. Logs suggest we're using MSBuild 17.8 which equals SDK 8.0.1xx:

MSBuild version 17.8.3+195e7f5a3 for .NET

See https://learn.microsoft.com/en-us/dotnet/core/porting/versioning-sdk-msbuild-vs. At the same time, on our build server we do actually use .NET 6 / C# 10.

Microsoft (R) Build Engine version 17.0.1+b177f8fa7 for .NET

This means that builds which pass the CI do not build on the actual build server we use for official distributions. It also means we can accidentally bump our minimum supported version of .NET requirement for our internal solutions. This happened with #82983 and #85975, which passed CI but failed on the build server.

---

We need to either decide to actually bump the version (and update the build server), or fix up the CI and be more careful in the future.

Steps to reproduce

N/a

Minimal reproduction project (MRP)

N/a

[YuriSizov]

Also it's strange that nothing in the build process caught that we were using a language feature not supported by C# 10. This should also be looked into.

[Repiteo]

This is incredibly strange. The GodotSharp .csproj files are all setup with <LangVersion>10</LangVersion>, which should mean that language features are constrained to C# 10

[raulsntos]

It looks like the LangVer check was removed for the extended nameof feature before shipping C# 11.

• Remove LangVer check from extended nameof binding dotnet/roslyn#62339

---

In CI we're using the image ubuntu-20.04 which, according to the GitHub Actions documentation, already includes the .NET SDK.

• godot/.github/workflows/linux_builds.yml

  Line 20 in 9d1cbab

  runs-on: "ubuntu-20.04"

• https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2004-Readme.md#net-tools

  .NET Core SDK: 6.0.417, 7.0.404, 8.0.100

---

In the build containers we are using fedora:39 and install the dotnet-sdk-6.0 package which seems to be 6.0.125.

• https://github.com/godotengine/build-containers/blob/83111b50c85aa49ccab5498218b8e378b51a28db/Dockerfile.base#L8-L10

[Repiteo]

It also seems to ship with the 6.0 SDK as well; I assume there's a way to specify which SDK gets used from the command line?

[raulsntos]

I assume there's a way to specify which SDK gets used from the command line?

I guess we could enforce the use of an older SDK with global.json. See Select the .NET version to use.

However, I'm not sure that's what we want. I think it may be preferable to change the build containers to use a newer SDK, specially since 6.0 will be out of support soon¹ and 8.0 is LTS.

Footnotes

1. .NET 6.0 ends support on November, 2024. See https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core. ↩

[akien-mga]

However, I'm not sure that's what we want. I think it may be preferable to change the build containers to use a newer SDK, specially since 6.0 will be out of support soon1 and 8.0 is LTS.

We can update the SDK version we use in build containers to 8.0, yes.

But the other question is whether we want to drop support for 6.0 already. If we don't have either official builds or CI testing .NET 6, we will introduce compat breakage as apparent from the PRs linked in the OP. If we're ok with making .NET 8 the minimum supported version, that's fine with me, but I don't know how reasonable it is in the .NET world to make the min version a release fresh out of the oven.

[Repiteo]

If it was an intermittent release (eg: .NET 7) then I could understand not wanting to jump on it, but I don't see any real reason to not just bump up to LTS for convenience. That upgrade is gonna happen sooner or later, especially with the prospective extension migration on the horizon, so I'm all for it happening now

[hhyyrylainen]

Now a few months later, I wouldn't consider .NET 8 to be a fresh release anymore. I'm not sure how other distros do it but for Fedora it seems to take from a few weeks to a couple of months after a new .NET release to get it into the official repos. So at this point .NET 8 has been easily available for many months and I'd assume most other distros also have a way to get it by now.

Also .NET 6 support ends already in just over 6 months.

[akien-mga]

Well this was fixed by #88671 already.

[hhyyrylainen]

That's good. I guess I'm really more interested in getting to use the new runtime in Godot, which seems to be a separate PR that hasn't progressed recently: #71241

Please let me know if there are any more up to date information on this topic / issue I should watch for updates. This and that one pull requests where the only places I could find discussing the updating of .NET.

[akien-mga]

You can already use .NET 8 for your project. IIRC you can set that in the .csproj file. Or are you running into specific issues?

[hhyyrylainen]

Thank you for getting me to double check this. I was sure that I had already checked this early on when I started porting my project to Godot 4, but when I now checked it just works when I specify <TargetFramework>net8.0</TargetFramework>. I thought that the limiting factor was the dotnet runtime that I assume is embedded in the Godot executable. Apparently that is not the case as I seem to be getting better performance and being able to access the new stuff that wasn't available in .NET 6. I'll need to investigate what I can now do further, but thank you, this should be a big help.