Skip to content

Annotate all DllImport/LibraryImport/UnmanagedCallersOnly with [SupportedOSPlatform] #132776

Open

Description

@pavelsavara

Summary

Annotate platform-specific DllImport / LibraryImport / UnmanagedCallersOnly declarations with [SupportedOSPlatform] / [UnsupportedOSPlatform].

Motivation

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.

Note

This issue was drafted with GitHub Copilot.

Activity

  1. self-assigned this
    on Aug 26, 2026
  2. dotnet-policy-service commented on Aug 26, 2026

    @dotnet-policy-service
    Contributor

    Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
    See info in area-owners.md if you want to be subscribed.

  3. dotnet-policy-service commented on Aug 26, 2026

    @dotnet-policy-service
    Contributor

    Tagging subscribers to this area: @dotnet/interop-contrib
    See info in area-owners.md if you want to be subscribed.

  4. added this to the 12.0.0 milestone on Aug 26, 2026
  5. dotnet-policy-service commented on Aug 26, 2026

    @dotnet-policy-service
    Contributor

    Tagging subscribers to this area: @dotnet/interop-contrib
    See info in area-owners.md if you want to be subscribed.

  6. jkoritzinsky commented on Aug 27, 2026

    @jkoritzinsky
    Member

    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).

  7. pavelsavara commented on Aug 27, 2026

    @pavelsavara
    MemberAuthor

    @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

  8. modified the milestones: 12.0.0, Future on Sep 7, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Type

No type

Projects

  • Status
    No status

Relationships

None yet

Development

No branches or pull requests

Issue actions