Bump SDK to 8.0.100 or greater

[Smaug123]

This is a prerequisite to my proposed replacement of Paket with central package version management (see https://github.com/fscheck/FsCheck/compare/master...Smaug123:rem-paket?expand=1 for details of what that might look like).

[kurtschelfthout]

I am all for that plan of replacing paket! You may be in for a rabbit hole though.

Here the problem seems to be that fake wants a .NET 6 runtime. It's possible updating fake helps with this? Although their last release seems to be a year ago...or maybe it has an override or something.

Finished (Success) 'DotNet:version' in 00:00:03.7407079
Performance:
 - Cli parsing: 397 milliseconds
 - Packages: 131 milliseconds
   - Creating Runtime Graph: 54 milliseconds
   - Retrieve Assembly List: 5 seconds
 - Script analyzing: 331 milliseconds
 - Runtime: 7 seconds
There was a problem while setting up the environment:
-> Could not find a suitable .NET 6 runtime version matching SDK version: 8.0.100
Hint: If you just upgraded the fake-runner you can try to remove the .fake directory and try again.
Command exited with code 1

[Smaug123]

Sigh, maybe this should all land at once! I've torn out Paket on my branch; maybe I should tear out Fake at the same time, and let the whole thing land together.

[Smaug123]

@kurtschelfthout How would you feel about me doing a massive rejig to the CI?

• Move to GitHub Actions
• Run on Linux
• Run a shell script

FAKE is also a hurdle new contributors have to jump over, and in fact it looks like I can't even run it without installing a lower .NET runtime (sigh, .NET tools were a mistake, about 50% of the time I have to use one I end up having to work around their non-self-contained nature).

[kurtschelfthout]

Yes, fake has turned out to be a pain as well. I'd be happy to see the back of it. The fewer dependencies the better. But that is a big lift! I definitely don't want to lose the ability to easily release (with uploads to github) and docs (also upload to github...and use fsformatting). I mean, introducing bigger thresholds for me to release is not going to improve my already low maintenance ability....

Anyway, Perhaps fake is mostly in the way if you use the api too call .NET actions (e.g. Dotnet.build) and in an intermediate state, we keep fake and replace those with command line invocations of dotnet build? I'm just thinking of this because I tried it just now and dotnet build FsCheck.sln works fine while fake gives me some MSBuild error at that step.

I would like to keep running tests on windows though. But happy to deal with AppVeyor part if things are otherwise working.

[kurtschelfthout]

In short, I think:

• removing fake
• removing paket

either or both, would be a massive step forward.

I have nothing against using GH actions but am pretty neutral vs which CI to use in general.

Finally thanks much for looking at this at all! I appreciate the effort.

[Smaug123]

Yeah, I don't intend removing any of these things, just putting them somewhere else. I may have to write this stuff in Powershell to keep it cross-platform 🤦

[kurtschelfthout]

I'll see if I can deal with the fake problem somewhere this weekend. I wanted to do a much-needed docs release just now but it's actually not working currently...sigh. Anyway, that may get you over this hump as well.

[Smaug123]

I've just started rewriting the fsx script to just make Grug-brained process calls rather than using Fake - I expect to finish that today, so no pressure on my account.