Registering experience of fresh build of FSharp.sln on fresh machine

[abelbraaksma]

I've had working installations of this repo for several years, but recently installed a new workstation and I was wondering how it would go.

It is a lot smoother than it was back in the day, but there are still some things that don't quite work as expected and/or could be improved. Mostly: doing as instructed won't "just work".

System:

• Windows latest
• Visual Studio RTM latest
• .NET 6.0 and .NET 8.0 SDKs.

First attempt

Trying to be naive:

1. Checkout main, run build.cmd --> success
2. Open FSharp.sln in Visual Studio
   • first time, asks for SDK and .NET Framework to be installed (as expected from instructions)
   • lot's of errors that .NET SDK cannot be found.
3. Build in Visual Studio: fails without showing details
4. Running dotnet tool restore in the root --> error: "The command could not be loaded" (I assume because of global.json)

Second attempt

A little less naive. I ran the following command to install .NET Preview (not in devguide.md, but there they do say you need a specific Preview version):

winget install Microsoft.DotNet.SDK.Preview

1. Open FSharp.sln in Visual Studio --> less errors
2. Ctrl-Shift-B (build all) in Visual Studio: fails three projects, something about resources missing (fsi, fsc and Compiler.Service.Tests). Sorry, forgot to copy the error.
3. Running dotnet tool restore in the root --> success

Then: closed Visual Studio, reopen it again, and recompile. This time success.

Error window shows 630 errors, all of them this:

---

All in all, not too bad. right? I can easily work with and work around these errors, and as mentioned, it is much better than in the (far) past. But I think we can still improve.

My proposal would be something like:

• auto-install the .NET version (there's an interactive Y/N question, so people can always deny it), if the requested version is not there. Unless this is considered too intrusive.
• fix the "This construct is deprecated: it is only for use in the F# library" error to pop up (I assume others see this too, no? Or is this a setting in the project or in Visual Studio? It does not prevent building the solution, though.

Still a little surprised though that building through build.cmd goes fine, but building through Visual Studio does not, and requires .NET SDK Preview to be installed globally. Esp because the logs clearly show this, suggesting that it has been installed successfully:

GET https://dotnet.microsoft.com/download/dotnet/scripts/v1/dotnet-install.ps1
  Attempting to install 'sdk v9.0.100-preview.3.24204.13' from public location.
dotnet-install: Remote file https://dotnetcli.azureedge.net/dotnet/Sdk/9.0.100-preview.3.24204.13/dotnet-sdk-9.0.100-preview.3.24204.13-win-x64.zip size is 309190459 bytes.dotnet-install: Downloaded file https://dotnetcli.azureedge.net/dotnet/Sdk/9.0.100-preview.3.24204.13/dotnet-sdk-9.0.100-preview.3.24204.13-win-x64.zip size is 309190459 bytes.
dotnet-install: The remote and local file sizes are equal.
dotnet-install: Extracting the archive.
dotnet-install: Adding to current process PATH: "D:\projects\OpenSource\fsharp\.dotnet\". Note: This change will not be visible if PowerShell was run as a child process.
dotnet-install: Note that the script does not resolve dependencies during installation.
dotnet-install: To check the list of dependencies, go to https://learn.microsoft.com/dotnet/core/install/windows#dependencies
dotnet-install: Installed version is 9.0.100-preview.3.24204.13
dotnet-install: Installation finished

[abelbraaksma]

After a few minutes waiting, I have 848 errors. I think somehow I have "warnings as errors". Looking at pars.fs is has:

#nowarn "1182"  // generated code has lots of unused "parseState"

but this compiler directive seems to be ignored. Which is a little odd, as I don't remember having that issue before.

While the "is not accessible from code location" error is a tad worrying, you can clearly see the many "value is unused" warnings here:

Could it be that the language server used in Visual Studio, when you open FSharp.sln should also be the latest version? I will install latest preview of VS, see if that helps.

[vzarytovskii]

VS requires SDK to be installed where it can discover it (either part of VS itself, or globally via installer/package manager). DEVGUIDE.md says that you need SDK installed here:

fsharp/DEVGUIDE.md

Line 52 in 75c3558

You will also need .NET SDK installed from [here](https://dotnet.microsoft.com/download/dotnet), exact version can be found in the global.json file in the root of the repository.

So, not much we can really do about it.

[abelbraaksma]

@vzarytovskii I have the SDK installed, but the errors are still there. It compiles fine, there are just 848 errors in the error window, and some files are almost entirely red underlined when opened.

If you open the current main branch and build FSharp.sln, does it also show these warnings as errors? And does it also ignore #nowarn in the code?

In addition, I saw some places where warning 42 and 44 were mixed up, I'll report that separately and/or open a PR.

[vzarytovskii]

If you open the current main branch and build FSharp.sln, does it also show these warnings as errors? And does it also ignore #nowarn in the code?

I don't use windows, so can't check it. Last time I did, VisualFSharp.sln worked fine. I don't think we use just FSharp.sln. It's either VS one or FCS one.

Also which vs version are you using ?

[abelbraaksma]

Also which vs version are you using ?

I tried both latest RTM and latest Preview.

In VSCode, you don't get the squigglies? If you were to open prim-types-prelude.fs for instance?

---

I just opened the VisualFSharp.sln, It shows the same issue as in the screenshot (btw, it has that error in many files).

NOTE: it does not show the errors unless the file is open. Does that hint at a possible cause?

In the VisualFSharp.sln are a bunch of other warnings as well, do these look familiar at all or shouldn't they be there? More to the point, shouldn't building or opening the solution be warning- and error-free?

[vzarytovskii]

Also which vs version are you using ?

I tried both latest RTM and latest Preview.

In VSCode, you don't get the squigglies? If you were to open prim-types-prelude.fs for instance?

I do get those. They are expected, been there forever, they are warnings for me though. If you know how to fix it, good, no need for separate issue for them though.

In the VisualFSharp.sln are a bunch of other warnings as well, do these look familiar at all or shouldn't they be there? More to the point, shouldn't building or opening the solution be warning- and error-free?

No, not necessary. Some of those are expected.

[abelbraaksma]

they are warnings for me though. If you know how to fix it, good, no need for separate issue for them though.

Ok. They flood the Error List window and show up as errors for me (even benign warnings like The value 'parseState' is unused), and as a result, they may hide actual errors. Also, #nowarn "42" has no effect in the mentioned file.

I'll see what I can do about them. While I can work around them, it may be confusing to first timers (or people who've been away from the source for a little while like myself).

While FS0042 is a warning, this one is not, can you confirm / deny that you see that one too, @vzarytovskii?

File: CompilerLocation.fs line 22
Errors:

• The value 'fsLanguageVersion' is not accessible from this code location
• The value 'BuildProperties' is not accessible from this code location

Again, not blocking the build though.

I believe it is an autogenerated type from this:

fsharp/FSharpBuild.Directory.Build.targets

Line 74 in 5a6f8b7

<_BuildPropertyLines Include="let fsProductVersion = &quot;$(FSPRODUCTVERSION)&quot;" />

[abelbraaksma]

A bit hidden away, but this comment by @cartermp: #10546 (comment) hints at this #nowarn not working. And your followup here: #10546 (comment)

I'll do some tests and see if it is easy to fix.