Aspnet-api-versioning: Version 4.1.1 is not compatible with netstandard2.1

[danielmeza]

When I try to install the 4.1.1 version in to a netstandard2.1 project the nuget packages says:

Severity Code Description Project File Line Suppression State Error NU1202 Package Microsoft.AspNetCore.Mvc.Versioning 4.1.1 is not compatible with netstandard2.1 (.NETStandard,Version=v2.1). Package Microsoft.AspNetCore.Mvc.Versioning 4.1.1 supports: netcoreapp3.1 (.NETCoreApp,Version=v3.1)

I know that this version remove the compatibility of asp.net core 2.x but it should be availiable in the netstandard2.1 since this target framework is made to work only with netcoreapp3.0+

[commonsensesoftware]

Not quite. ASP.NET Core 3.0/3.1 itself only targets netcoreapp3.0 and netcoreapp3.1 respectively. Since API versioning directly depends on ASP.NET Core, it has to follow the same TFMs. While it's true that a .NET Core 3.0+ application can reference .NET Standard 2.0/2.1, ASP.NET Core 3.0+ provides no such TFM. In fact, they don't even ship the individual packages anymore. Now there is only a _framework reference_.

I've spent many years using .NET Standard and multi-targeting with various methods. I'm not arbitrarily removing its support. ASP.NET Core simply no longer supports it if you are directly extending the framework.

There is a long discussion in #591 that articulates as much of these details as possible. I'm happy to be proven wrong and make it work, but thus far no one has been able to verify my assertions are incorrect.

I hope that helps

[danielmeza]

@commonsensesoftware you have right I have a miss conception here. Sorry for the issue and thanks for the clarification, I have not notice that ASP.NET Core 3.x was transform in a _framework reference_.
As a side note, I not see any troubles using the _framework reference_ I know that when we create libraries to extend the framework not need the entire sets of packages, at the end the library will be used in a application that use the entire framework, the only side effect I see is the payload for load all the reference but I suppose that the asp.net core team take that in account. Well I know that this is not the space for discus that.

Again thanks for you clarification and congratulations for this excellent tools.

[commonsensesoftware]

No problem. 591 discusses that in detail. Essentially, although you _reference_ the entire framework, the linker only binds the references that you actually use. My understanding is that the ASP.NET found that more people were having issues with not knowing which packages to reference or facing significant bloat from duplicate packages deployed on a single machine, so they decided to move to a singular _framework reference_. This is conceptually similar to a _meta package_ reference. It seems like that makes it harder to service bug fixes, but what I do I know? Maybe they feel it's stable enough that it's not a huge deal.

Long story short, .NET Core will become just .NET (5.0) by next year and will be the path forward. .NET Standard was always a bridge and it's unclear if it will still be needed or supported going forward. There's no plans to stop supporting it, but it may no longer be necessary. As it stands, if you support .NET Standard 2.0 (likely the most common), you can only go back to .NET 4.6.1 anyway. All of the new features and innovation will happen on what is currently .NET Core, primarily because everything is broken up. Many compiler tricks have been used or features deferred because they required changes to the CLR, which could not be shipped without a whole iteration of the full .NET Framework. Now will be able to do this things side-by-side in a comparatively lightweight manner. ;)