question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

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

See original GitHub issue

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?

Issue Analytics

  • State:closed
  • Created 4 years ago
  • Comments:5 (3 by maintainers)

github_iconTop GitHub Comments

2reactions
melanorecommented, Apr 3, 2020

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!

1reaction
cartermpcommented, Mar 22, 2020

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.

Read more comments on GitHub >

github_iconTop Results From Across the Web

NET Standard
NET Standard allows a library to use more APIs but means it can only be used on more ... NET Core 2.0 SDK...
Read more >
Please stop lying about .NET Standard 2.0 support!
In this post I have a bit of a rant about Microsoft's NuGet packages lying about supporting .NET Standard 2.0 when they kinda...
Read more >
General advice for legacy project migration to .NET ...
All legacy services (Framework 4.5.2) need to continue work. ... NET Membership there is a migration route tool to ASP.NET Identity.
Read more >
5x Lessons Learned from Migrating a Large Legacy to . ...
NET Standard 2.0 and didn't need to harness 2) or 3). .NET is converging years ... 3) Tooling can help anticipate most migration...
Read more >
The current .NET SDK does not support targeting . ...
NET Core 2.0 development tools" on the left menu. ... I presume this is because VS 2017 is still a x86 program and...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found