You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Annotate all DllImport/LibraryImport/UnmanagedCallersOnly with [SupportedOSPlatform] #132776
The wasm CoreCLR ManagedToNativeGenerator (src/tasks/WasmAppBuilder/coreclr/PInvokeCollector.cs) already skips P/Invokes and callbacks that are unsupported on the target OS, evaluating SupportedOSPlatform / UnsupportedOSPlatform at method → declaring-type → assembly scope against the target (browser / wasi).
However, most low-level Interop.* declarations are not annotated — e.g. Interop.Kernel32.GetCurrentProcess lives in the cross-platform System.Private.CoreLib with no platform attribute. As a result they flow into the scan and produce WASM0066 noise on browser/wasi (kernel32, ntdll, advapi32, …), and more generally they are invisible to platform-compatibility tooling.
Annotating these declarations would let the existing wasm platform-skip eliminate the noise at the source, and would improve CA1416 platform-compatibility analysis across the board.
The hard part — callers
Annotating the interop leaves is not enough; the callers must be solved too.
Adding [SupportedOSPlatform("windows")] (etc.) to the low-level interop will surface CA1416 on every caller. Many callers are already guarded (if (OperatingSystem.IsWindows())) and will be fine, but some are not, and cross-cutting annotation requires walking and annotating/guarding those call chains. This is the bulk of the work and must be scoped in — it cannot be done by annotating leaves alone.
Scope
src/libraries/Common/src/Interop/** and the per-assembly interop partials.
Coordinate with the platform-compatibility analyzer (CA1416) expectations.
Enables (and is complemented by) the wasm relink-gating work in the companion issue.
To limit the viral impact of this change, we may want to introduce a diagnostic suppressor for diagnostics in OS-specific files (sometimes we implement the same API in a .Windows.cs and a .Unix.cs file).
Alternatively, we can try updating the logic in our implementation assemblies (mainly CoreLib) to have SupportedOSPlatform on the assembly as a whole for the platform we are building for (this idea may come with its own problems with ref assemblies and existing OS support attributes).
Activity
dotnet-policy-service commentedon Aug 26, 2026
Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.
dotnet-policy-service commentedon Aug 26, 2026
Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.
dotnet-policy-service commentedon Aug 26, 2026
Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.
jkoritzinsky commentedon Aug 27, 2026
To limit the viral impact of this change, we may want to introduce a diagnostic suppressor for diagnostics in OS-specific files (sometimes we implement the same API in a .Windows.cs and a .Unix.cs file).
Alternatively, we can try updating the logic in our implementation assemblies (mainly CoreLib) to have SupportedOSPlatform on the assembly as a whole for the platform we are building for (this idea may come with its own problems with ref assemblies and existing OS support attributes).
pavelsavara commentedon Aug 27, 2026
@jkoritzinsky yes, I use the first strategy.
It's mechanical, but many files anyway.
I will split it by OS.
Windows is first chunk #132778