.NET 11 base library additions

Everything here was checked against SDK 11.0.100-rc.1 (runtime 11.0.0-rc.1), the Microsoft.NETCore.App.Ref packs for 10.0.12 and 11.0.0-rc.1, and probe apps run on both runtimes. Re-check after the final release. Default to net10.0;net11.0 targets (see dotnet-multi-targeting), so each API below needs a net10.0 fallback.

The Compat helper rule

Keep every #if NET11_0_OR_GREATER branch inside one small static class in a Compat/ folder. Both branches sit behind the same signature. Feature code calls the helper and never contains #if.

ZLibCompat.cs is a working example. Verified on both runtimes:

The truncated row is a real difference. If truncation matters on net10.0, compare the output length with a size you know, such as the expected row bytes of an image.

Span-based compression (new in .NET 11)

All of these are in System.IO.Compression. None exist on net10.0.

TryDecompress and TryCompress are static, so calling them on an instance is error CS0176. TryDecompress writes nothing and returns false when the destination is short, so use the instance Decompress when the output size is unknown.

Status results, measured:

After DestinationTooSmall you can continue with source[consumed..] and a destination starting at written without calling Reset(). A grow-and-retry loop with ArrayPool<byte> is therefore straightforward (see InflateToArray in the example).

Per-thread decoder, zero steady-state allocation

Create the decoder once per thread and call Reset() before each stream. 1000 decodes of an 8000-byte output allocated 0 bytes. A fresh new ZLibDecoder() per call allocated about 144 bytes each, plus native state.

[ThreadStatic]
private static ZLibDecoder? _decoder;

ZLibDecoder decoder = _decoder ??= new ZLibDecoder();
decoder.Reset();
OperationStatus status = decoder.Decompress(source, destination, out int consumed, out int written);

[ThreadStatic] instances are never disposed. That is acceptable for a long-lived worker thread; use a pool of decoders if threads come and go.

Zstandard has no mandated place in container formats such as PDF. Do not add it to a reader without a format reason.

In-memory streams

StringStream does not exist in 11.0.0-rc.1. Do not use it.

Small additions

Crypto notes

• MD5.HashData goes through the platform crypto library. On Linux with OpenSSL in FIPS mode MD5 can be refused. This is reported behaviour; this host does not run FIPS, so it was not reproduced. If a format mandates MD5 (PDF RC4 and AES-128 key derivation), use a managed implementation. ManagedMd5.cs is about 100 lines of RFC 1321, allocation-free in Release builds, and matched MD5.HashData on the RFC test strings and on random inputs of 0 to 599 bytes. Report a FIPS refusal as a clear error, not a crash.
• Compare password hashes and MACs with CryptographicOperations.FixedTimeEquals, never SequenceEqual.
• RC4 is not in the base library. Write it in managed code (about 30 lines).

Checklist

• Every #if NET11_0_OR_GREATER branch lives in a Compat/ helper with one signature for both branches
• Differences between the two branches are in the helper's doc comment and covered by tests on both TFMs
• Decoders and encoders are cached per thread and reset, not created per call
• Output size unknown: instance Decompress in a grow loop, not TryDecompress
• DestinationTooSmall, NeedMoreData and InvalidData handled as results, not exceptions
• No StringStream, and no BitArray span constructor on MSB-first data
• MD5 behind a managed fallback where FIPS systems are in scope