[eiriktsarpalis]

Use C# extension-member polyfills to consolidate framework-compatibility code across src/libraries, following #136156. Call sites use framework API names while downlevel implementations remain in internal polyfill containers. Targets that already provide a member continue to bind to the framework implementation.

The cleanup extends beyond System.Text.Json and its source generator to CBOR, Metadata/NRBF, xxHash, Packaging, Dataflow, MEF2, DiagnosticSource, Server-Sent Events, and several Microsoft.Extensions libraries. It includes:

• Shared static-member and property polyfills for type and enum inspection, bit and endian conversions, multiplication, array limits, elapsed time, Unix epoch, and platform checks.
• Reuse of existing span, collection, stack, string, decimal, and uninitialized-object polyfills instead of local compatibility helpers and conditional branches.
• Standard argument guards in place of equivalent manual checks, preserving validation order and parameter names.
• The same consolidation in existing CBOR tests and shared assertion utilities, removing the paired CBOR test-helper files without adding test coverage.

The source generator's IsClosed helper is expressed as an extension property while retaining its existing Roslyn light-up and syntax-fallback behavior. There are no public API changes or new test cases.

Initial Release validation passed .\build.cmd libs -rc Release -lc Release /p:RunAnalyzersInBuild=true /p:RunILLinkInBuild=true, followed by targeted compatibility builds and existing test-suite runs on CoreCLR and .NET Framework. Subsequent review adjustments were covered by targeted rebuilds and tests.

Note

This pull request was generated with GitHub Copilot.

[dotnet-policy-service]

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

[eiriktsarpalis]

/ba-g test failure is unrelated.

[eiriktsarpalis]

/ba-g test failure is unrelated

[drieseng]

@eiriktsarpalis: I only had a very brief look at the changes, but it seems you're not conditionally including the polyfilld for those target(framework)s where they are effectively necessary. Does Roslyn automatically "filter" these out (hereby reducing code size)?

[jkotas]

@drieseng We minimize the maintenance burden for packages targeting .NET Framework and other older runtimes. As a result, these packages may include some unreachable polyfills. This is by design.

[eiriktsarpalis]

it seems you're not conditionally including the polyfilld for those target(framework)s where they are effectively necessary. Does Roslyn automatically "filter" these out (hereby reducing code size)?

Not sure what you mean by this, the polyfill source files are included conditionally.