Remove MinimalSampleFSharp.fsproj from sln

[halter73]

If you try to build MinimalSampleFsharp from within VS, you'll see the following error:

Severity    Code    Description    Project    File    Line    Suppression State
Error    FS3384    The .NET SDK for this script could not be determined. If the script is in a directory using a 'global.json' then ensure the relevant .NET SDK is installed. The output from 'C:\Program Files\dotnet\dotnet.exe --version' in the directory 'C:\Code\aspnetcore\src\Http\samples\MinimalSampleFSharp' was: 'Could not execute because the application was not found or a compatible .NET SDK is not installed.�Possible reasons for this include:�  * You intended to execute a .NET program:�      The application '--version' does not exist.�  * You intended to execute a .NET SDK command:�      A compatible installed .NET SDK for global.json version [6.0.100-preview.4.21222.6] from [C:\Code\aspnetcore\global.json] was not found.�      Install the [6.0.100-preview.4.21222.6] .NET SDK or update [C:\Code\aspnetcore\global.json] with an installed .NET SDK:' and the exit code was '-2147450735'.    MinimalSampleFSharp    C:\Code\aspnetcore\src\Http\samples\MinimalSampleFSharp\unknown    1    Active

It dotnet runs just fine for me. @dotnet/aspnet-build any ideas other than just removing it from the sln?

[Pilchie]

Also tagging @cartermp @KevinRansom @brettfo @TIHan

[halter73]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[cartermp]

That is super weird. Which VS version does this repro in? Can take a look

[KevinRansom]

@cartermp , @Pilchie my guess it's because that machine only has net6.0 on it, and our clumsy probing expects 5.0. I will prepare a fix in our repo. Probably a work around is to either ignore the failure or to install a net5.0.

[Pilchie]

Well, the repo requires a .NET 6 repo, and uses a repo local version (because it installs specific builds of the .NET Runtime too, and wants to be able to do that without admin privs. Using DOTNET_MULTILEVEL_LOOKUP=0 means it never sees the 5.0 SDK, even if you have one.

[KevinRansom]

@Pilchie , I dug into it a lot deeper last night, asp.net is obviously doing the right thing. F# obviously has a bug.

The net5.0 is a red-herring.

The F# Compiler has always done a thing that is pretty icky, that Roslyn doesn't really do. It was originally done for usability reasons to make the command line compile easy for developers to manage when typing fsc program.fs and also to make fsi.exe not require a bunch of #r "references" for framework assemblies.

When we originally did the coreclr port of fsc this behavior was omitted, but over time, much of it has crept back in.

The F# compiler tries to acquire the framework assemblies at the start in order to do that it has a bunch of horrible probing code. The xcopied coreclr + global.json scenario is just not consistently and well followed by fsc.exe and fsi.exe

What is going wrong in the case shown above is actually two bugs.

1. We appear to be finding the wrong dotnet.exe we are executing the global one from program files instead of the xcopied version.
2. Even if we got that correct (which we don't) a later step which then tries to get the contents of the pack directory would only examine packs from the global dotnet location rather than merging them with the xcopied packs folder in order to find the correct set of framework reference assemblies as specified by the global.json

So in short ... F# is buggy in the presence of an xcopied netsdk and global.json file.