Update to .NET 6 ?

[Numpsy]

Description

Spin off from comments in #603 -

As it stands:

1. global.json is set to require a .NET 5 SDK to build
2. The command line tool is built as a .NET 5 application.

But - .NET 5 is out of support.
So -

What are the thoughts on

1. Updating the SDK version used in the build

and/or

2. Retargetting the build to .NET 6 ?

I'm not sure offhand if everything will work as .NET 6 without changes or if anything else would need updating, but I think it is the case that some of the supporting libraries have started dropping support for .NET 5 and needing 6+ so that update might be a pre-requisite of other updates.

[baronfel]

I'd advocate for going right to .NET 8, even if this tool keeps targeting the net6.0 TFM.

[Numpsy]

fwiw, I tried building with the .NET 8 RC2 SDK and immediately fell over that issue with dotnet tool restore being broken, but it's at least only a couple of weeks till the RTM version

[knocte]

I'd advocate for going right to .NET 8, even if this tool keeps targeting the net6.0 TFM.

Sorry, what do you exactly mean with this? Do you mean use .NET8 in CI but have net6 as a value of the <TargetFramework> tag?

[Numpsy]

You could possibly make the command line tool .NET 6, but use the version 8 SDK for builds (which could give you the benefits of any other improvements in the build tooling whilst still allowing users to run it just with 6).

Fwiw, I tried building it with the .NET 7 SDK and fell over fsprojects/FAKE#2748 so MSBuild.StructuredLogger probably needs to be updated in the CI builds

[knocte]

You could possibly make the command line tool .NET 6, but use the version 8 SDK for builds (which could give you the
benefits of any other improvements in the build tooling whilst still allowing users to run it just with 6).

TBH I'm not sure what this means. I guess I need to see a diff to understand it.
But my cautious mentality would be asking to upgrade step by step, first everything to .NET6 in one PR, then we make a release, and then we upgrade to .NET8 like you say here in a subsequent PR, whose changes would land in the next release. This way, in case there are any issues, we can ask users what version they are on, and rollback to a previous version (or update to latest) to see if it fixes their problem.

[baronfel]

The SDK allows building and running applications that are on an 'earlier' TFM. This has always been supported. What this means is that you can have a version of the SDK in your global.json like '8.0.100', but your projects would still use a TargetFramework of 'net6.0'. This will all work, and all tooling will support it.

Generally speaking we want folks to be on the newest SDK possible so that they get all of the most recent tooling fixes - regardless of the runtime their apps target.

[Numpsy]

Created #605 as a starter

[Numpsy]

Another go at updating everything to .NET 6 all at once at #606

[knocte]

Fixed by e8d2697 . If anyone wants to test this, you can grab our prerelease: https://www.nuget.org/packages/dotnet-fsharplint/0.23.1--date20231228-0934.git-e8d2697