JsonConvert getting reported as not supported on 4.7.2, .net Standard 2.0 and .net Core 2.1
Closed this issue · 7 comments
Whilst trying to use the Compatability Analyzer to convert a library from .net framework to .net standard 2.0 compliant, I have noticed that it is reporting JsonConvert SerializeObject and DeserializeObject as NOT being compatible with ANY of .net framework 4.7.2, .net core 2.1 or .net standard 2.0
This doesn't make any sense.
To reproduce:
-
Create a new .net Standard 2.0 class library.
-
Add NewtonSoft.Json nuget
-
In class1.cs add:
public class Class1
{
public void DoSomething()
{
const string data = "Hello";var json = JsonConvert.SerializeObject(data); }
}
-
Build and then run the Analyzer (v2.5.0)
The result on my machine (using VS 15.9.2) is:
Hey,
This tool focuses on APIs shipped by the .NET Framework (ie. System., Microsoft.). We don't currently take into consideration third party libraries like Newtonsoft.Json.
I hope this helps,
Connie
@conniey I've downloaded the code, compiled it and ran it again against the same test app, this time it comes back as 100% compatible for all platforms.
When you say "we don't currently take into consideration third party libraries" do you mean that the VS "extension/plugin" version doesn't but the console app has the ability to scan these 3rd party dependencies?
It's rather confusing as the extension results read to me that it knows Newtonsoft.json isn't compatible - wouldn't a question mark symbol be more appropriate for "i don't know about this library"?
i'm now trying to figure out why there's a difference between the VS extension and the commandline versions?
@terrajobst Looks like JSON.NET is in the catalog. Are 3rd party libraries like this marked in the catalog in a special way to filter out?
This looks similar to #702
@terrajobst Looks like JSON.NET is in the catalog. Are 3rd party libraries like this marked in the catalog in a special way to filter out?
Not systematically. Looking at JSON.NET it seems we added because ASP.NET Core depends on it.
We should probably filter those out I'm thinking. They aren't really helpful for the ApiPort scenarios