Does .NET Standard 2.0 TPDTC still require legacy tooling support?
See original GitHub issueIn 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,
- Is the guidance here still applicable?
- What other advantages are there to splitting runtime/designtime into separate projects?
Issue Analytics
- State:
- Created 4 years ago
- Comments:5 (3 by maintainers)
Top GitHub Comments
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!
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.