Set RollForward on FSharpLint.Console to latestMajor

[Numpsy]

refs #687 , whereby it appears to not be able to process .NET 7 or 8 projects when running on .NET 6, and always using the latest version seems to help.

It looks like the current roll foward behaviour was added for #519 to fix issues where only a newer version than the tool was built with is available, but this change would make it just use the latest all the time (so for example, if you have 6 and 8 installed, then it will use 8 all the time).
I'm not sure if there is any potential to break anything that currently works though.

[knocte]

Hey @Numpsy thanks for the PR!

refs #687 , whereby it appears to not be able to process .NET 7 or 8 projects when running on .NET 6, and always using the latest version seems to help.

It looks like the current roll foward behaviour was added for #519 to fix issues where only a newer version than the tool was built with is available, but this change would make it just use the latest all the time (so for example, if you have 6 and 8 installed, then it will use 8 all the time).
I'm not sure if there is any potential to break anything that currently works though.

Can you please include all this great info in the commit message please? commit messages can have body, not just a title.

Also, can you bring this to your PR: #687 (comment) This way we know for sure if the bug is fixed or not.

[Numpsy]

I tried pulling in those other commits and the build failed with the error from #687 , but in the logs I saw

Which looks like it was downloading the artifact for the test 0.24.3 build, but then installing the 0.24.2 build from NuGet. I've tried to fix that by adding --prerelease to the install command in the test so that it installs the test build

[Numpsy]

Failure now looks like the testReleaseBinariesInWindows8 step needs to do a paket restore before running the tool?

[Numpsy]

Ok, so it now seems to be running the tool ok, but failing the build due to an error exit code, which is something i suppose:

[knocte]

Good progress Richard! But why would it throw this error here and not throw it in our SelfCheck CI step?

[Numpsy]

A bit of testing locally suggests that there is some difference in behavior depending on if the FSharplint.Core project has been built before linting than if it hasn't (and the additional test step here isn't doing a build, just a restore as it stands).

Possibly also related to the observation at #637 (comment) about different results when linting a single .fs file vs. doing the solution - If i run the 0.24.2 release against single files then I get the same warnings as the last CI build here got, whereas linting the built FSharplint.Core project has no warnings.

[xperiandri]

Could you rebase and update to .NET 9?

[xperiandri]

Probably we can remove this now?

[Numpsy]

Looks like it

[Numpsy]

Could you rebase and update to .NET 9?

I'll have a look (at this point, setting rollForward to latestMajor might make it roll onto .NET 10, so I'll see what happens when the .NET 10 preview build is installed)

[Numpsy]

Hmm, if I try to run the unit tests on the lastest source with the preview .NET 10 SDK installed then I get a few test failures with messages like this:

FSharpLint.FunctionalTest test failed with 9 error(s) (63.9s)
    S:\GitHubForks\FSharpLint\tests\FSharpLint.FunctionalTest\TestApi.fs(87): error TESTERROR:
      Lint multi-targeted project (1s 242ms): Error Message:   MSBuildFailedToLoadProjectFile
        ("S:\GitHubForks\FSharpLint\tests\FSharpLint.FunctionalTest.TestedProject\FSharpLint.FunctionalTest.TestedProject.NetCore\FSharpLint.FunctionalTest.TestedP
      roject.NetCore.fsproj",
         InvalidProjectFileMessage
           "GenericError
        ("S:\GitHubForks\FSharpLint\tests\FSharpLint.FunctionalTest.TestedProject\FSharpLint.FunctionalTest.TestedProject.NetCore\FSharpLint.FunctionalTest.TestedP
      roject.NetCore.fsproj",
         "SDK Resolver Failure: "The SDK resolver "Microsoft.DotNet.MSBuildWorkloadSdkResolver" failed while attempting to resolve the SDK "Microsoft.NET.SDK.Workl
      oadAutoImportPropsLocator". Exception: "System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime, Version=10.0.0.0, Culture=neutral,
      PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.
      File name: 'System.Runtime, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
         at Microsoft.NET.Sdk.WorkloadMSBuildSdkResolver.WorkloadSdkResolver.Resolve(SdkReference sdkReference, SdkResolverContext resolverContext, SdkResultFactor
      y factory)
         at Microsoft.Build.BackEnd.SdkResolution.SdkResolverService.TryResolveSdkUsingSpecifiedResolvers(IReadOnlyList`1 resolvers, Int32 submissionId, SdkReferen
      ce sdk, LoggingContext loggingContext, ElementLocation sdkReferenceLocation, String solutionPath, String projectPath, Boolean interactive, Boolean isRunningI
      nVisualStudio, SdkResult& sdkResult, IEnumerable`1& errors, IEnumerable`1& warnings)""  C:\Program Files\dotnet\sdk\10.0.100-preview.5.25277.114\Sdks\Microso
      ft.NET.Sdk\targets\Microsoft.NET.Sdk.ImportWorkloads.props")")
        Expected: True
        But was:  False

It seems ok if I set global.json to use the ,NET 9 SDK

Edit: Ah, setting DOTNET_ROLL_FORWARD_TO_PRERELEASE fixes those, I'd forgotten about that one

[xperiandri]

Now we can test with .NET 10, similar to #748

[knocte]

@Numpsy can you rename title of this PR to convey more clearly what it achieves? Seems the current title explains the what but not the why (it explains the solution, but not the problem).