Publish F# 4.6 FSharp.Compiler.Tools package

[vasily-kirichenko]

Afaik the compiler is stable and will ship with VS 2019 RTM without changes, so it's time to publish FSharp.Compiler.Tools package as all editors already support F# 4.6, but lacking the compiler makes it impossible to use all the features.

[vasily-kirichenko]

Ok, VS 2019 is released...

[baronfel]

In order for this to happen we'd have to integrate the changes from VF# that have languished. I've tried this a few times, and keep running up against difficulties resolving conflicts in the build systems. I'd welcome any and all help in this area, as this is the same root cause of Mono's F# version languishing.

[vasily-kirichenko]

Yeah, I’m afraid we have to do it ourselves as Carter & Co said they don’t care. What a time to be alive.

[dsyme]

Integration is here: #890, needs to be updated and progressed

[baronfel]

Note that that integration is just for 15.9, there have been (a couple?) of releases since then. I was trying to do it in stages so that we'd have traceability between the different releases of VF# and releases of F.C.T.

[dsyme]

Yeah, I’m afraid we have to do it ourselves as Carter & Co said they don’t care. What a time to be alive.

The F# community has always been responsible for this package, the responsibilities have always been very clear - this is absolutely not a Microsoft responsibility. Given the existence of the .NET SDK it is also much, much less important than the past. It's even likely the package should be deprecated - the main thing is the delivery of fsi.exe as a standalone tool. Is that the reason you can't use the .NET SDK?

Mono update is here mono/mono#10919. @directhex has been looking into that but it is some very obscure problem with building the Mono package.

[dsyme]

Why close? It's a valid issue, we (the F# community) should indeed update the package. But it's no surprise we should have to do it ourselves.

[vasily-kirichenko]

@dsyme I cannot use .net sdk to build my solution because dotnet build fails on SqlClient type provider (at least). Is it possible to use the compiler shipped with the sdk without dotnet (targeting net462)?

[dsyme]

@dsyme I cannot use .net sdk to build my solution because dotnet build fails on SqlClient type provider (at least). Is it possible to use the compiler shipped with the sdk without dotnet (targeting net462)?

I see. No, the compiler in the SDK is a .NET Core program and only accepts type providers which have a .NET Standard or .NET Core App TPDTC component.

The type provider SDK template is up-to-date for creating type providers that have both .NET Framework 4.x and .NET Standard 2.x TPDTC components (a single type provider can have both).

Until the SqlClient type provider TPDTC is updated to be netstandard2.x or netcoreapp 2.x then you will need to use the existing F# .NET Framework compiler, whether by community FCT package or VS/Mono install. The FCT package is provided by the F# community, among other things it might lag behind F# releases via other packaging/delivery routes.

[smoothdeveloper]

Kind of connected, I'm recently worked around some issue I had after upgrading SqlClient to latest release (which uses new TP SDK), the TP is used in scripts and it wouldn't run with fsianycpu.exe from FCT nuget (+ updated FSharp.Core + large script graph may have an impact).

My current work around has been to use fsi that ships with vs2019, I'll be able to revert this work around once a new FCT ships.

@vasily-kirichenko is it possible that if you install msbuild tools (I assume there is a refresh released with vs2019) and set the PATH to have the location of fsi, the issue you are facing would be solved?

[vasily-kirichenko]

@smoothdeveloper I don't need fsi, I need fsc. Trying to made a 10.2.1.1 package out of 10.2.1 by replacing the content of tools dir with files from c:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\FSharp, but Paket does not see it as 10.2.1.1 :(

[vasily-kirichenko]

@smoothdeveloper Pinning the package version has solved the problem, I have F# 4.6 in my solution (FSharp.Configuration fails in one case tho, but backward compat is not a concern nowadays).

[vasily-kirichenko]

As the packages seems not be needed by anybody but me, feel free to close this issue.

[fldef]

As the packages seems not be needed by anybody but me...

I depend on fsc from the FSharp.Compiler.Tools package. If the package is not updated for the next F# version, is the expectation that I should change my workflow (such as it is) to run fsc from somewhere else?

FYI, I'm asking as someone with no serious stakes in this. Just a hobbyist.

[dsyme]

I depend on fsc from the FSharp.Compiler.Tools package. If the package is not updated for the next F# version, is the expectation that I should change my workflow (such as it is) to run fsc from somewhere else?

The choices will be

1. Wait. There's often no need to update if the current FCT is doing the job for you. Patience can make things simpler.

2. Contribute. Help update FCT, by helping @baronfel and others with the integrations and publishing. Being a part of the community core engineering is a great way of owning the story.

3. Switch to the .NET SDK (dotnet build etc.). Most CI systems support configurations which have known versions of this pre-installed.

[dsyme]

Closing as https://github.com/dotnet/fsharp is now the unified repository for F# work.