Docfx: A more user-friendly way for multi-framework projects

Created on 19 Dec 2017  路  4Comments  路  Source: dotnet/docfx

Nowadays it is a common scenario that a csproj is targeting multiple frameworks. And it is not quite convenient for docfx to handle such case, it involves pretty much config changes and some are dependent on others.

Area-Metadata feature-request future v3

Most helpful comment

Until this issue is resolved docfx is ~kind of useless~ (I see I can at least specify one of them and get partial docs) for library authors.
Specially once Microsoft advised to add not only netstandard2.0 target but also a specific net461 to sort out some dependency resolution issues:

CONSIDER adding a target for net461 when you're offering a netstandard2.0 target.

Using .NET Standard 2.0 from .NET Framework has some issues that were addressed in .NET Framework 4.7.2. You can improve the experience for developers that are still on .NET Framework 4.6.1 - 4.7.1 by offering them a binary that is built for .NET Framework 4.6.1.

I see the issue just got a future tag. Is there any plan to get this fixed?

All 4 comments

Totally agree here. I'd like to see something similar to what Jon Skeet has implemented with NodaTime (source). Notice each item has an "Availability" section where the target frameworks are listed.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

NodaTime implements a tool to insert these information: https://github.com/nodatime/nodatime/commit/7e09297a98765c355a5f352773bc01585318ffa6

Until this issue is resolved docfx is ~kind of useless~ (I see I can at least specify one of them and get partial docs) for library authors.
Specially once Microsoft advised to add not only netstandard2.0 target but also a specific net461 to sort out some dependency resolution issues:

CONSIDER adding a target for net461 when you're offering a netstandard2.0 target.

Using .NET Standard 2.0 from .NET Framework has some issues that were addressed in .NET Framework 4.7.2. You can improve the experience for developers that are still on .NET Framework 4.6.1 - 4.7.1 by offering them a binary that is built for .NET Framework 4.6.1.

I see the issue just got a future tag. Is there any plan to get this fixed?

Was this page helpful?
0 / 5 - 0 ratings