Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
KevinRansom opened this issue May 21, 2024 · 6 comments

Comments

@KevinRansom
Copy link
Member

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:

  • 64Bit/32Bit - fscAnyCpu.exe
  • 32Bit - fsc.exe
  • Arm64 - fscArm64.exe

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

  • By default Visual Studio uses the dotnet SDK version of FSI
    image

  • There is a Visual Studio Setting to configure VS to use one of the desktop versions of VS

image

Disadvantages:

  • Start up time of the coreclr fsc is significantly slower than the desktop version. Hello World builds in 2 seconds rather than 1 second
  • NetSDK cannot load libraries targeting the desktop framework unless they are netstandard2.0
  • NetSDK F# compiler cannot use type providers targeting the desktop framework unless they are netstandard2.0

Advantages

  • simplify development and testing.
  • We would only build and test the compiler once on the NetSDK rather than twice on NetSDK and desktop plus there are 3 Desktop compilers apps to be built and deployed, 32-Bit, AnyCPU and Arm64.
  • Same for fsi.
  • Easier deployment, we would deploy F# only with the SDK and via nuget. VS would not require it's own compilers.
@smoothdeveloper
Copy link
Contributor

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
Copy link
Member Author

@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
Copy link
Member Author

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
Copy link
Contributor

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
Copy link
Member Author

@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
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: New
Development

No branches or pull requests

5 participants