dotnet / fsharp

The F# compiler, F# core library, F# language service, and F# tooling integration for Visual Studio
https://dotnet.microsoft.com/languages/fsharp
MIT License
3.83k stars 773 forks source link

Consider deprecating desktop framework version of the F# compiler and FSI program #17195

Open KevinRansom opened 1 month ago

KevinRansom commented 1 month ago

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.

image

image

Disadvantages:

Advantages

smoothdeveloper commented 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:

FSharp.Data.SqlClient#373

KevinRansom commented 1 month ago

@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.

KevinRansom commented 1 month ago

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.

abelbraaksma commented 1 month ago

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 :).

KevinRansom commented 1 month ago

@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.

KevinRansom commented 1 month ago

@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.