Epic: Expand platform compat annotations to cover more configurations

[cathysull]

In .NET 5 we started with annotations for features and APIs which are not universally available everywhere. We picked Windows and browsers as the initial targets for the experience. To make the experience complete we need to continue annotating remaining platforms we support (e.g. Linux-specific APIs that we expect to add). It goes beyond this as well. It's certainly a "last mile" experience, but for example today you won't get any warnings if you try to use MemoryMappedFile.CreateNew(string, ...) with a non-null string path, even though only a null string path is supported on Linux and macOS. The current platform analyzer doesn't account for such possibilities, with annotations done to just say "if any usage of this API works on a platform, then consider it supported on that platform". We should look at what APIs fall into those partially-supported buckets and consider ways of improving the experience around them. This might be the next issue developers porting to .NET 5 get hung up on from a cross-platform perspective.

We also realized that the platform vertical is not the only limiting factor for APIs availability. There are others based primarily on workload limitations which should offer developers the same experience. We will expand compatibility annotations to cover configurations such as AOT, self-contained bundles and single file.

The projects which benefits most from the annotations are large scale solutions with many dependencies which are usually not available as a source code implementation. Exploring how to run the analysis on the final output would further improve the impact of tooling.

Work Items

• Windows developers get warnings when call APIs that aren't available on the OS version they want to target Windows developers get warnings when call APIs that aren't available on the OS version they want to target #45192
• Xamarin developers get warnings when they call APIs that aren't available on the OS version they target Xamarin developers get warnings when they call APIs that aren't available on the OS version they target #45193
• Blazor developers get warnings when they call APIs that aren't available on WebAssembly Blazor developers get warnings when they call APIs that aren't available on WebAssembly #42335
• Some of platform specific builds in runtime repo causing CA1416 Fix warnings caused from build attributes for TFM target platforms added by SDK  #44231
• Developers get warnings when they misuse [SupportedOSPlatform] or [UnsupportedOSPlatform] attributes Developers get warnings when they misuse [SupportedOSPlatform] or [UnsupportedOSPlatform] attributes #44914
• Analyzer for methods with PlatformNotSupportedException body but missing platform attributes Analyzer for methods with PlatformNotSupportedException body but missing platform attributes #42967
• Improve diagnostic messages [Platform Compatibility Analyzer] Indicate why the current code violates the rule roslyn-analyzers#4021
• Identify more places to apply [SupportedOSPlatform] and [UnsupportedOSPlatform] attributes for Windows and Linux Identify more places to apply [SupportedOSPlatform] and [UnsupportedOSPlatform] attributes for existing platforms #44916
• Flag diagnostics when unsupported types are used as generic type parameters Platform compatibility analyzer not warning for platform specific type parameter roslyn-analyzers#4362
• Developers can easily resolve Platform Compatibility warnings with a code fixer Developers can follow documentation to resolve Platform Compatibility warnings #44919
• Developers can verify their app NuGet dependencies compatibility against target platform Developers can verify their NuGet dependencies compatibility against specific target platform #44920
• Developers need more flexibility to annotate their code for platform supported/unsupported scenarios to reduce issues warnings noise Developers need more flexibility to annotate their code for platform supported/unsupported scenarios to reduce issues warnings noise #44922
• Flag platform specific constructor called implicitly in derived types Consider flag platform specific constructor called implicitly in derived types roslyn-analyzers#4404

[jeffhandley]

Can we also consider integrating the OSPlatform support attributes into the .NET Portability Analyzer so that the report can show the APIs that are available in .NET Core but have limited OSPlatform support?

[danmoseley]

@jeffhandley @cathysull we can mark this as Committed on the .NET 6.0 board, I guess? Note this is marked P1 but has P0 children (which by definition are committed).

[jeffhandley]

I'm closing the epic; there are only a couple of stories that remain, and they are being tracked individually and will soon close as well.