Developers can verify their NuGet dependencies compatibility against specific target platform

[jeffhandley]

AB#1255325
The Platform Compatibility Analyzer was introduced in .NET 5.0, raising new diagnostics when APIs are referenced that are unsupported on targeted platforms. At present, this analysis can only be performed as part of compilation, providing an experience for identifying unsupported API calls within the IDE or during a build.

The projects which benefit most from the annotations are large scale solutions with many dependencies which are usually not available as a source code implementation. If the same analysis performed by the Platform Compatibility Analyzer could be performed against binaries, we could further improve the impact of this tooling. The analysis could potentially be integrated with the .NET Portability Analyzer as well, helping those seeking to migrate from .NET Framework to identify not only which APIs are and are not available in .NET 5.0+, but which of those APIs were Windows-specific.

[jeffhandley]

@marek-safar and @bruno-garcia -- Do you have any specific scenarios in mind that can be used as acceptance criteria for this story? At present, this is vaguely defined and low-confidence; specific scenarios would help.

[marek-safar]

We have several major scenarios which would benefit from this support greatly and we could come up with more as this can have quite a broad impact.

A few major ones

• Blaze WASM developers
• ios/Android developers
• NativeAOT/SingleExe like scenarios

All of them would benefit from running compact analyzers for all pieces they deploy than for just parts they built from sources.

[jeffhandley]

In order to study this further, we need to define some concrete scenarios for usage and expectations.

1. What would the developer be analyzing?
   a. Their source, but analyzing into the NuGet package dependencies they have
   b. A DLL
   c. A NuGet package
2. Would this analysis happen inside or outside Visual Studio?
3. How far into NuGet package dependencies would we traverse for analysis?
4. What actions would we guide developers to take if a warning is discovered within a referenced assembly/package?
5. Is the ultimate intent to find netcoreapp APIs that are platform-specific, but used in NuGet packages that are platform agnostic?

@terrajobst @marek-safar -- @buyaa-n and I don't know the answers to these questions. Is the following what you had in mind, or were you thinking of something different?

1. If we're analyzing the developer's code inside Visual Studio
2. And the reference an API that comes from a NuGet package and that API does not have any [SupportedOSPlatform]/[UnsupportedOSPlatform] attributes applied
3. But we're able to inspect the API calls made within the API that is being called (recursively) down to netcoreapp (it is unknown how we could do this)
4. And we find [SupportedOSPlatform]/[UnsupportedOSPlatform] attributes applied that have not been handled by the intermediate NuGet package's API
5. Then we provide a warning to the developer that the API they are calling might not be supported on their platforms

[marek-safar]

There are multiple scenarios you could build on top of the original requirements. However, the core one is very simple.

A developer is building Blazor/Win/Apple/etc. app and adds a dependency to NuGet to help him solve some of his problems. The NuGet is added to the project and builds successfully. The developer keeps working on the code and after few more iterations, the app suddenly throws PNSE. After some time spent the developer finds out that NuGet is targetting net6.0 but it's not compatible with Blazor/Win/Apple target and has to remove the library and rewrite the code written to use a different library or approach.

[terrajobst]

@cathysull, FYI this is not gonna make the cut for .NET 6.