Does .NET Standard 2.0 TPDTC still require legacy tooling support?

[aggieben]

In the README, the section on building a TPDTC targeting netstandard2.0 states the following:

It will be increasingly common to make type providers where the TPDTC is a .NET Standard 2.0 component. In the very simplest case, there will just be one happy .NET Standard 2.0 component MyTypeProvider.dll acting as both the TPDTC and TPRTC. Such a type provider will eventually be loadable into all F# tooling.

However, today, for a TPDTC to be .NET Standard 2.0, it must be loadable into host tools using .NET Framework 4.6.1 or Mono 5.x, the most common platforms for execution of F# tooling. Because .NET Framework 4.6.1 doesn't fully support .NET Standard 2.0, this can only be done if the TPDTC ships alongside some facade DLLs. Currently the following facade DLLs are needed alongside the TPDTC:

With VS2019 out, and .NET Core FSAC support in Ionide, do we still need to be concerned about this? The divided TPDTC/TPRTC projects is a source of complexity and confusion to me, and it seems to me that it would be advantageous to build a type provider in only a single project and focus on netstandard2.0. So, to restate,

1. Is the guidance here still applicable?
2. What other advantages are there to splitting runtime/designtime into separate projects?

[aggieben]

I've come across some other guidance online that speaks to this a bit also:

If you author type providers with dependencies you should use the exact structure used by the TPSDK template

dotnet new -i FSharp.TypeProviders.Templates
dotnet new typeprovider -n LemonadeProvider -lang F#

this has separate TPDTC and TPRTC
the nuget package is laid out correctly, including placing dependencies of the TPDTC into the TPDTC folder in the nuget
The magic flag is passed to allow dependency loading here > https://github.com/fsprojects/FSharp.TypeProviders.SDK/blob/master/templates/content/basic/src/MyProvider.DesignTime/MyProvider.DesignTime.fs#L20
(from @dsyme in 2018 here: fsprojects/OpenAPITypeProvider#6 (comment))

and

[at] patham9 it’s highly unlikely that this issue is the right place to report that error, as the mechanism to allow type providers to work on .NET Core has been shipped and stable for quite some time. I suspect your issue lies in the library, not this type provider mechanism.
(from @cartermp in 2019 here: dotnet/fsharp#3303 (comment))

and also

Type Providers have not needed mono to compile for quite a long time. There's no reason to require .NET Framework of any flavor unless you specifically require an API that has no alternative on .NET Standard.
(from @cartermp recently here: fsprojects/SQLProvider#645 (comment))

These comments leave me with the impression that we should be able able to build type providers without any .NET Framework tooling at all, but that there might still be reason to split the implementation of the TPDTC/TPRTCs. However, the template project still includes a netfx.props file that looks for Mono or façade assemblies. Is that only there for the case when a type provider project targets a net4x TFM? If we only target netstandard2.x, is any of that necessary?

[cartermp]

Such a type provider will eventually be loadable into all F# tooling.

This comment is now out of date; all supported f# tools can load this kind of type provider now. So I don't think this guidance is applicable anymore. @dsyme?

The only reason to multi-target today would be if you use windows/.NET Framework-specific APIs for only those targets. But I would consider that an edge case and all multi-TFM and all inclusion of .NET Framework or Mono-specific stuff should be removed from the template.

[dsyme]

But I would consider that an edge case and all multi-TFM and all inclusion of .NET Framework or Mono-specific stuff should be removed from the template.

Yes, I agree with this, we should remove all that from the template

[melanore]

https://github.com/demetrixbio/FSharp.Data.Npgsql works smoothly on Windows/Unix netstandard2.0 using 3.1.201 SDK. Thanks a lot for work on tooling and migrations suggestions @cartermp, @dsyme. That's an impressive milestone!

[cartermp]

I will close this out as it is not required to use any legacy tooling. We do need to publish an updated template though.