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
System.IO.Compression.ZLibStream (added in .NET 6) had no polyfill for older target frameworks.
Implementation
Added ZLibStream as a type polyfill (PolyShim/Net60/ZLibStream.cs), enabled on .NET Framework 4.5+, .NET Standard 1.1+, and .NET Core/.NET below 6.0.
The real ZLibStream relies on an internal zlib window-bits constructor of DeflateStream that isn't publicly exposed, so it can't be wrapped directly. Instead, the polyfill wraps the public raw DeflateStream (headerless deflate) and manually frames the data as a standard zlib stream:
Writes the 2-byte zlib header (CMF/FLG) lazily on first write, computed from the requested CompressionLevel to match native zlib output exactly.
Tracks an Adler-32 checksum of the uncompressed data and appends it as the 4-byte trailer on dispose.
On decompression, reads and validates the 2-byte header before delegating the remaining bytes to a raw inflate DeflateStream.
Unsupported members (Seek, SetLength, Length, Position) throw NotSupportedException, matching the real type.
usingSystem.IO;usingSystem.IO.Compression;usingvarcompressed=newMemoryStream();using(varzlib=newZLibStream(compressed,CompressionLevel.Optimal,leaveOpen:true))zlib.Write(data,0,data.Length);// compressed now holds a standard zlib stream (0x78 0x9C header + deflate payload + Adler-32 trailer)
Tests
Added PolyShim.Tests/Net60/ZLibStreamTests.cs covering compression/decompression round-trips, header bytes per compression level, interop with DeflateStream-produced payloads, invalid header detection, and leaveOpen behavior.
❌ Patch coverage is 79.83871% with 50 lines in your changes missing coverage. Please review.
✅ Project coverage is 87.84%. Comparing base (37a7ea6) to head (cb3bb0c). ⚠️ Report is 1 commits behind head on prime.
All five review comments were valid, and I fixed them in the latest commit.
Adler-32 trailer: decompression now checks it. A small wrapper holds back the last 4 bytes of the source, and they are compared with the checksum of the data returned. Corrupted or truncated input now throws InvalidDataException.
Read/write arguments: the buffer range is checked before any framing. Zero-length reads and writes are no-ops, so they no longer consume or emit a header.
Disposal: the owned base stream is now closed in a finally block, after the deflate stream is finalized and the trailer is written.
Header validation: an empty source reads as an empty stream. A truncated header throws. A header with CINFO > 7 or FDICT set throws too.
I checked the changes with a standalone harness against .NET 8's native ZLibStream: round-trip, native interop, empty source, a corrupted trailer and a truncated stream. The existing 13 ZLibStream tests pass only on net10, where the polyfill isn't compiled, so they don't exercise this code. I didn't add tests for the new cases to the repo.
The .NET 6 ZLibStream API includes a public read-only BaseStream property. Omitting it makes code that accesses the underlying stream compile against the real type but fail on polyfill targets. Mirror the framework property through the wrapped DeflateStream.
This issue also appears in the following locations of the same file:
@copilot please regenerate Signatures.md to resolve conflicts
Ran ./GenerateSignatures.csx; it regenerated Signatures.md with 591 signatures, and the output matches the checked-in file, so there was no diff to commit.
@copilot please also merge in latest prime. Also, tests are failing for some reason.
Merged the latest prime in cb3bb0c, regenerated Signatures.md, and fixed the Windows compile failure by renaming the compression stream locals. Focused ZLibStream tests pass 7/7. The full suite had three unrelated network-dependent HttpClient failures in this environment.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
System.IO.Compression.ZLibStream(added in .NET 6) had no polyfill for older target frameworks.Implementation
ZLibStreamas a type polyfill (PolyShim/Net60/ZLibStream.cs), enabled on .NET Framework 4.5+, .NET Standard 1.1+, and .NET Core/.NET below 6.0.ZLibStreamrelies on an internal zlib window-bits constructor ofDeflateStreamthat isn't publicly exposed, so it can't be wrapped directly. Instead, the polyfill wraps the public rawDeflateStream(headerless deflate) and manually frames the data as a standard zlib stream:CMF/FLG) lazily on first write, computed from the requestedCompressionLevelto match native zlib output exactly.DeflateStream.Seek,SetLength,Length,Position) throwNotSupportedException, matching the real type.Tests
PolyShim.Tests/Net60/ZLibStreamTests.cscovering compression/decompression round-trips, header bytes per compression level, interop withDeflateStream-produced payloads, invalid header detection, andleaveOpenbehavior.