Closed aggieben closed 3 years ago
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: https://github.com/fsprojects/OpenAPITypeProvider/issues/6#issuecomment-428900442)
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: https://github.com/dotnet/fsharp/issues/3303#issuecomment-499977412)
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: https://github.com/fsprojects/SQLProvider/issues/645#issuecomment-584702792)
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?
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.
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
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!
I will close this out as it is not required to use any legacy tooling. We do need to publish an updated template though.
In the README, the section on building a TPDTC targeting
netstandard2.0
states the following: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,