Type provider design time component loading suitable for .NET Core tooling

[dsyme]

This implements F# Tooling RFC FST-1003 - Loading Type Provider Design-Time Components into F# Tooling, also discussed here. The overall aim of this work is to allow type providers to work with .NET Core-based F# tooling.

This means we support the creation of type provider packages (i.e. packages that contain TPDTCs) that can be used successfully regardless of whether the F# compiler is running using .NET Core (e.g. the F# compiler in the .NET SDK) or .NET Framework/Mono.

With this in place, and the F# support in the .NET SDK updated, and type providers adjusted and republished, then the workaround in #3303 will no longer be needed.

• Type Provider SDK updated
• RFC written
• Tests added for load paths
• Can create a single DLL ComboProvider.dll .netstandard 2.0 type provider and use it from both .NET Framework-hosted fsc.exe and .NET Core-hosted fsc.exe
• Can create a two DLL (BasicProvider.dll, BasicProvider.DesignTime.dll) type provider where different design time components are shipped for .NET Core and .NET Framework and use it from both .NET Framework-hosted fsc.exe and .NET Core-hosted fsc.exe

The only further item needed after this that I know of is this:

• Update F# support in .NET SDK
• Update VF# Tools and FSharp.Compiler.Service so Ionide etc. know of new loading rules
• Update various individual type providers to use the latest TPSDK, and either
  1. use a .NET Standard 2.0 design-time component, or
  2. include both a .NET Framework and a .NET CoreApp 2.0 design-time component, or
  3. report a good error if it not possible to use the type provider with .NET Core-based F# tooling because the design-time requirements are too stringent, in which case the workaround in [Obsolete] How to enable type providers with new-style .NET SDK project files, dotnet build, .NET Standard and .NET Core programming #3303 is still needed

[dsyme]

An example of authoring a type provider that will load into either .NET Framework or .NET Core-based F# tooling is here: https://github.com/dsyme/FSharp.TypeProviders.SDK/tree/tpload1/examples. This places the components in this shape under bin\Debug (for cross-project references)

BasicProvider.dll
typeproviders\fsharp41\net461\BasicProvider.DesignTime.dll
typeproviders\fsharp41\netcoreapp2.0\BasicProvider.DesignTime.dll

and in the nuget package they would be something like this:

lib\netstandard2.0\BasicProvider.dll
typeproviders\fsharp41\net461\BasicProvider.DesignTime.dll
typeproviders\fsharp41\netcoreapp2.0\BasicProvider.DesignTime.dll

Essentially all type providers would need to be updated to follow this pattern. In future iterations the layout could be:

lib\netstandard2.0\BasicProvider.dll
typeproviders\fsharp41\netstandard2.0\BasicProvider.DesignTime.dll

and possibly eventually

lib\netstandard2.0\BasicProvider.dll

where the design-time and runtime components are merged.

[dsyme]

@KevinRansom @cartermp @matthid This is ready. Please review the RFC, the implementation and testing

Testing has been included for the load locations for .NET Framework.

For .NET Core, I have validated by hand that we can now load and use type providers in fsc.exe when the compiler is running as a .NET Core 2.0 App. After a chat with @KevinRansom it turns out we don't have any automated tests yet for running in that configuration, so I did this by

build coreclr
xcopy /iy Tools\dotnet20\sdk\2.0.0-preview2-006502\FSharp Tools\dotnet20\sdk\2.0.0-preview2-006502\FSharpTest
xcopy /y release\coreclr\bin\* Tools\dotnet20\sdk\2.0.0-preview2-006502\FSharpTest

Then take these examples of type providers and adjust the lines here and here to use the freshly built F# compiler running on .NET Core 2.0. Then do

msbuild examples/ComboProvider.Tests/ComboProvider.Tests.fsproj
msbuild examples/BasicProvider.Tests/BasicProvider.Tests.fsproj

and in each case compilation succeeds. For example, in the case of BasicProvider we end up running the .NET Core hosted F# compiler like this:

Tools\dotnet20\sdk\2.0.0-preview2-006502\FSharpTest\RunFsc.cmd 
  -o:obj\Debug\net461\BasicProvider.Tests.dll 
  ...
  -r:C:\GitHub\dsyme\FSharp.TypeProviders.SDK\examples\BasicProvider\bin\Debug\net461\BasicProvider.dll
  ...

etc. This is generating code for .NET Framework (hence the reference to bin\Debug\net461\BasicProvider.dll), but the TPDTC that gets loaded into the .NET Core tooling is correctly from typeproviders\fsharp41\netcorepp2.0\BasicProvider.DesignTime.dll.

And in the case of ComboProvider we end up running

C:\GitHub\dsyme\visualfsharp\Tools\dotnet20\sdk\2.0.0-preview2-006502\FSharpTest\RunFsc.cmd -o:obj\Debug\net461\ComboProvider.Tests.dll
  -g ... -r:C:\GitHub\dsyme\FSharp.TypeProviders.SDK\examples\ComboProvider\bin\Debug\netstandard2.0\ComboProvider.dll

which is loading a single-dll .NET Standard 2.0 type provider into the .NET Core hosted F# compiler correctly.

[dsyme]

@dotnet-bot test Windows_NT Release_ci_part2 Build please

[KevinRansom]

@dsyme can we call the typeprovider folder 'compilertools' then that will align with an extensibility model.

[dsyme]

@dsyme can we call the typeprovider folder 'compilertools' then that will align with an extensibility model.

@KevinRansom See email I sent to you - perhaps just named subdirectories under "tools"?

[KevinRansom]

tools is okay, but it's going to be a bit overloaded. nuget used to use it for apps sucked into the build. global tools uses it for the 'global tool'

So in short I'm okay with tools, I have some fud, that there may be issues with all of the scenarios that people may use for tools.

[KevinRansom]

@dotnet-bot test this please

[KevinRansom]

I will pull this and propose a folder change with my extensibility PR.

[cartermp]

@dsyme just to get this on record for what we can do in 15.6:

use a .NET Standard 2.0 design-time component, or

This is the option to take.

[dsyme]

Hi @KevinRansom @cartermp,

Do you know if there is there an updated .NET SDK beta containing this? (People are asking about TP + .NET Core on the F# compiler office hours). Thanks!

don

[daniellittledev]

What version of fsharp did this land in?

[KevinRansom]

It's been in for absolutely ages. Certainly all dotnet sdks since 3.1.