why neither "ASP.NET Core 2.1" nor ".NET Core + Platform Extensions 2.1"?

[springy76]

My task is to migrate a large solution (120+ projects) containing a ASP.NET Core 2.1 host -- which currently is targetting net472 and references all the other projects in the solution -- to target .NET Core 2.x so it could be run on Linux in the near future.

.NET Core 3.0 is both too far in future and -- even worse -- it is no indicator for Non-Windows compatibility because classes such as System.Windows.Media.Imaging.BitmapFrame are part of .NET Core 3.0 although not being supported on any other platform than Windows.

But using the existing options "ASP.NET Core 2.0" and ".NET Core + Platform Extensions 2.0" already flood the output with false-positive nonsense for code which already has been successfully converted to target "netstandard2.0" or "netcoreapp2.1" -- maybe still Windows specific at same rare places (I already use Microsoft.DotNet.Analyzers.Compatibility for this) -- but it already compiles fine. But flood of nonsense makes it nearly impossible to spot the real problems which need refactoring to either different dependencies or tranforming the code to optional platform specific plugins.

---

Now I tried with a much tinier solution which only contains some netstandard2.0 libs and 2 ASP.NET Core 2.1 sites already targetting netcoreapp2.1 created only 3 weeks ago by VS 2017 15.8.x using WebAPI templates and this already is frustating: 16 full pages of "problems" which just do not exist. The entire source code is more compact.

Submission Id 5204d6c6-7b0b-494f-8efc-95d75e7cdf19

[terrajobst]

Laziness. I'll take a look.

[springy76]

I'm very sorry to say this, but this tool -- in its current state -- is totally useless to me because 99.9% of the warnings are pure nonsense bullshit.

And the source of all problems is the inconsistency of how NuGet references are being treated. Some of them are associated with a "target platform": For example Microsoft.Extensions.Logging.Abstractions or Newtonsoft.Json seem to be related to ASP.NET core 2.0 and so every use on netstandard libraries fails. But in fact these NuGet packages are availabe since netstandard2.0 or even netstandard1.x.

But these flood of nonsense messages makes it impossible to spot the code parts which really have to be reworked -- this portability analyzer tool has to do ONE job and it just is not doing that job.

[twsouthwick]

I think there is a misunderstanding of the role this tool is supposed to play. It's goal is to help analyze and understand the risk in moving to .NET Core for user assemblies and their reliance on framework APIs, not 3rd party APIs. The tool only knows about the libraries you pass in and does not traverse any dependency graph via NuGet to determine if there are available libraries. We did look into that at one point but it quickly became very complicated. This tool was originally designed almost four years ago, and much has changed in the ecosystem and some static analysis that was very difficult then is more possible now, but it would require a rewrite of the tool.

That being said, the way this tool is effectively used is to:

1. Run the tool against all user assemblies (that is, code you own)
2. Mitigate any issues found in your own code for missing framework APIs to be able to target .NET Standard (if you are a library) or .NET Core (if it is an app)
3. Identify 3rd party libraries you bring in via NuGet and identify if they support .NET Standard or .NET Core. This can be done by going to NuGet.org and looking at the dependencies tab.

[springy76]

Fully agree for the usage. But IT IS throwing unnecessary errors for some NuGet packages which have been declared as being part of NETCORE or ASPNETCORE.

I'm repeating myself the 3rd time: I HAVE NO INTEREST IN ANY WARNING ABOUT Microsoft.Extensions.*, Newtonsoft.Json and such. They all are just plain netstand compatible libraries.

And that's the point: I'm checking any existing net4x library I own the code for and which I want to convert to netstandard2.x, and I get millions of false error messages for targetting these NuGet packages which just are not any problem for netstandard2.0 compatibility -- and so I don't see the real 2-3 problems which I have to solve (maybe by splitting the lib into a second MyFeature.WinOnly part).

[twsouthwick]

@terrajobst Are the Microsoft.Extensions.* and Newtonsoft.Json included in the catalog?

[springy76]

I just noticed that ".NET Standard + Platform Extensions,Version=v2.0" exists, which looks good so far 👍 Must be relatively new -- or I just did overlook it recently.

BTW: Is there a strong definition for the term "Platform Extensions" anywhere (on docs.microsoft)?

I wish that apisofnet website would give some hint about the NuGet packages where the assemblies are included. Example: https://apisof.net/catalog/System.DirectoryServices.DirectoryEntry How should I know that sometimes for System.DirectoryServices, Version=4.0.0.0 I need the NuGet package System.DirectoryServices in version 4.5.0??

[KirkMunro]

Laziness. I'll take a look.

@terrajobst: You never did come back with a response other than the quoted one above. Would it be much work to get ".NET Standard + Platform Extensions,Version=v2.1" added as one of the output options for this tool?

[terrajobst]

@Lxiamail

[Lxiamail]

@terrajobst ".NET Standard + Platform Extensions,Version=v2.1" isn't available in catalog.bin, that is why apiport tool doesn't have the option. @KirkMunro While we are following up why ".NET Standard + Platform Extensions,Version=v2.1" is missing in .net catalog, can you share more information about why you need ".NET Standard + Platform Extensions,Version=v2.1", would ".NET Core + Platform Extensions, version=3.1" serve your goal?

[KirkMunro]

@Lxiamail: I have the ".NET Core + Platform Extensions, version=3.1" output column enabled, and I'm using that already. I'm working through bringing a significant amount of legacy code forward to .NET Standard/.NET Core, and some of it cannot be brought directly into 3.1, so I'm trying for .NET Standard 2.0 or 2.1 to start. To be honest, I'm making do with what I have, and figuring out gaps by just trying to port projects over as I go, but I posted my question because I felt it would be easier if there was a ".NET Standard + Platform Extensions,Version 2.1" column so that I could more easily assess portability to one of .NET Standard 2.0, .NET Standard 2.1, or .NET Core 3.1.

[terrajobst]

Closing as API Port was deprecated in favor of binary analysis in .NET Upgrade Assistant.