Open KevinRansom opened 1 month ago
Just in case the deprecation eventually turns into not shipping/no ability to select the compiler, this is a blocking ticket with no workaround: #10323
This also impacts compiling web application projects using "dotnet watch" (or any "dotnet" command), where I have to resort on to using a custom fsc.props:
@smoothdeveloper --- we would continue to ship a desktop compiler - though it would not be installed by default, however, it would be a frozen in time compiler at F# 8.0, and it would only take security fixes.
This would be similar to the FSharpSdk package for legacy FSharp.Cores and FSharp.Data that we ship, although they are still installed by default, we should probably not install them by default.
The dotnet sdk is unlikely to ever allow loading legacy desktop framework assemblies. So if there are type providers that have not migrated at least to netstandard2.0 we should work with the maintainers to upgrade them, or stop relying on them.
The compiler can still build desktop framework Apps, and consume for compilation purposes desktop framework libraries. dotnet fsi, however will not be able to consume them.
Should we run this through the fsharp-suggestions
repo and/or RFC it? It's quite a big change, after all. I think it's good, though. We should move on :).
@abelbraaksma It's not really a language thing, it's more a product thing so I think we can handle it here.
The only authorized way to get fsc.exe and fsi.exe these days is via Visual Studio, unless someone builds the repo here and redistributes it. Which would be a fairly strong incentive to keep building and testing it here. But I believe (with no real evidence) that the other tools that rely on the compiler get it via the Dotnet SDK. VS is most likely the outlier here relying on the desktop framework build.
@abelbraaksma to be honest about moving on ... the compatibility with existing projects is terrifying. We believe we can still build Silverlight apps, even though we haven't even tested it in 7 or 8 years. And we still install FSharp.Core dlls from 2015 in the latest VS. Even though I am keen to move on, it would take only a small bit of pushback for me to become a fraidy cat and not do anything.
The main purpose of this thread is to flesh out any compatibility fears we have not considered.
Visual Studio currently ships a desktop framework version of the F# compiler and F# interactive application in addition to the coreclr versions shipped with the Dotnet SDK.
By default Visual Studio compiles F# applications using a desktop build of the compiler: E.g. C:\Program Files\Microsoft Visual Studio\2022\Community/Common7/IDE/CommonExtensions/Microsoft/FSharp/Tools/fscAnyCpu.exe
Visual Studio ships 3 desktop compilers in every Visual Studio:
When bulding a solution or project from the command line the msbuild command also defaults to the desktop framework compilers above. There are Two project file settings which configures msbuild and Visual Studio to use the Dotnet SDK compiler. Also dotnet build and dotnet fsi default to the coreclr tooling.
By default Visual Studio uses the dotnet SDK version of FSI![image](https://github.com/dotnet/fsharp/assets/5175830/18f4debf-eb1a-4ea7-b191-0345fabf50e7)
There is a Visual Studio Setting to configure VS to use one of the desktop versions of VS
Disadvantages:
Advantages