Publish F# 4.6 FSharp.Compiler.Tools package about fsharp HOT 16 CLOSED

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.

from fsharp.

@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)?

from fsharp.

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

from fsharp.

Ok, VS 2019 is released...

from fsharp.

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.

from fsharp.

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

from fsharp.

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

from fsharp.

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.

from fsharp.

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.

from fsharp.

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?

from fsharp.

@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 :(

from fsharp.

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

from fsharp.

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

from fsharp.

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.

from fsharp.

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.

from fsharp.

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

from fsharp.