[Obsolete] How to enable type providers with new-style .NET SDK project files, dotnet build, .NET Standard and .NET Core programming

[dsyme]

This issue documents how to enable the use of type providers when using a .NET SDK 2.0 "new style" project file.

This also allows the use of cross-targeting type providers as part of .NET Core 2.0 app programming or .NET Standard 2.0 library programming.

If you don't follow one of the workarounds below you may get a silent failure or RunFsc.cmd failed from the F# compiler when executing dotnet build or "StackOverflowException", if your project references a type provider.

What you need to do

1. Install an F# Compiler that runs on .NET Framework or Mono, see Linux, Windows, OSX. It is likely you already have one installed.

2. Add the file fsc.props to the root of your project and import it into each of your project files that reference a type provider using something along the lines of: <Import Project="fsc.props" />,

The F# compiler will then run using .NET Framework and/or Mono.

Alternative Workaround

On Windows:

• Install Visual Studio 2017 15.3 or later
• Use "msbuild.exe" from a Visual Studio 2017 command line prompt to build the project instead of "dotnet build"

On Linux/OSX/Xamarin/Mono:

• Install Mono 5.0 or later
• Use "msbuild" to build the project instead of "dotnet build"

Explanation: when you compile your project using msbuild.exe the F# support in the .NET SDK will assume .NET Framework execution of the F# compiler is required. This workaround is also compatible with using an fsc.props file as mentioned above.

Examples where the problem occurs

Example 1 (building a .NET 4.6.1 application that uses FSharp.Data)

dotnet new console -o -lang F# --target-framework-override net461 app3
cd app3
dotnet add package FSharp.Data
dotnet restore
dotnet build

Example 2 (building a .NET Core 2.0 application that uses FSharp.Data)

dotnet new console -o -lang F# app4
cd app4
dotnet add package FSharp.Data
dotnet restore
dotnet build

Expected behaviour is compilation success, or at least nice error point to workaround. Actual behavior is a silent compilation failure, and dotnet build /v:d shows l Process is terminating due to StackOverflowException. Done executing task "Fsc" -- FAILED.

Explanation

As explained in this issue, type providers are not yet supported when the F# compiler runs using .NET Core. By default, the .NET SDK tooling runs the F# compiler using .NET Core.

The workaround is to have the .NET SDK tooling use an F# Compiler running on the .NET Framework or Mono, regardless of which version of .NET you're targeting. By doing this, the type provider is hosted and executed using the .NET Framework. This technique applies even if you are doing .NET Core programming (for cross-targeting type providers), or building a .NET Standard 2.0 library. The F# Compiler cross-generates code for the correct target regardless of how it executes.

Although this workaround may seem "wrong" if targeting .NET Core, it has advantages:

• the use of .NET Framework/Mono is only at compile-time
• the technique stress-tests the cross-targeting capabilities of the type provider
• the technique unblocks TP authors to test and adjust TPs to be cross-targeting

In the future, the plan of record is to allow .NET Standard 2.0 type providers to be used when the F# compiler is running on .NET Core. This is an interim workaround for those who wish to unblock the testing and use of type providers for .NET SDK project files and .NET Core/.NET Standard 2.0 programming.

[dsyme]

Note, I think we can have a better setting for FscToolPath which works on both Windows and Mono, though it needs a conditional to determine the right location

[larjo]

Thanks @dsyme!

The FscToolPath/FscToolExe workaround seems to work just fine even with SDK 1.0.4.

[dsyme]

@cartermp @KevinRansom As I've now documented in the issue description, it is possible to use the above technique to enable type providers for .NET Core programming, as long as the type providers have been written as a cross targeting type provider. The main cross-targeting type provider is FSharp.Data.

Here are the steps I used to verify that this can be used with .NET Core 2.0 programming:

• dotnet new console -o -lang F# tpapp2
• cd tpapp2
• dotnet add package FSharp.Data
• dotnet restore
• edit the .fs to contain

open System
open FSharp.Data

type NugetStats = HtmlProvider<"https://www.nuget.org/packages/FSharp.Data">

let rawStats = NugetStats().Tables.``Version History``

rawStats.Rows |> Seq.iter (printfn "row = %A")

• edit the tpapp2.fsproj to contain

    <FscToolPath>C:\Program Files (x86)\Microsoft SDKs\F#\4.1\Framework\v4.0</FscToolPath>
    <FscToolExe>fsc.exe</FscToolExe>

• dotnet build
• dotnet run

output:

row = ("F# Data 2.3.3 (this version)", 22954M, 10/04/2017 00:00:00)
...
row = ("FSharp.Data 1.0.2", 234M, 14/12/2012 00:00:00)
row = ("FSharp.Data 1.0.1", 187M, 14/12/2012 00:00:00)
row = ("FSharp.Data 1.0.0", 469M, 13/12/2012 00:00:00)

🎉🎉🎉🎉 we have used type providers for .NET Core programming for the first time :)

Notes:

• When using VSCode/Ionide you also get full intellisense:

• The above technique also works for .NET Standard 2.0 programming (dotnet new lib -lang F# tplib1). However at the time of writing you need an F# compiler that includes this fix, e.g. use Visual Studio 2017 preview 3, or use an F# compiler built from source. I tested with <FscToolPath>C:\GitHub\dsyme\visualfsharp\release\net40\bin</FscToolPath>

• You get some warnings because FSharp.Data for .NET 4.x is being used. However it should be possible to produce a fully compliant .NET Standard 2.0 version of FSharp.Data, that is TBD, and until then the .NET Framework version is not that likely to cause major problems since the surface area of FSharp.Dataa is relatively low