Microsoft has released a beta of a new portable library called Bcl.Compression that adds support for both zip archives and compress streams (i.e. deflate and gzip). The compression stream support is designed to work in conjunction with the Portable Http Client that went live last month, a feature they are referring to as “AutomaticDecompression”.
This library relies on the zlib library, which was included in .NET 4.5 and Windows Store. For Windows Phone 8, this library is exposed via ClrCompression.dll and the .NET wrapper, System.IO.Compression.dll.
This design can be somewhat problematic for Windows Phone 8 developers. The “Any CPU” build option is not supported by these libraries on Windows Phone. The project will need to be compiled as x86 for the emulator and ARM for actual devices. Portable libraries, as well as those that target .NET or Windows Store, do not suffer this limitation.
Developers working on Silverlight or Windows Phone 7.x cannot use this library at all. Since these platforms don’t support native libraries, there is no way to get the current code base to work. In theory Microsoft could port the libraries to a managed version, but Immo Landwerth of Microsoft says that is not currently planning on doing that.
Though the new compression library isn’t available for .NET 4.0, the AutomaticDecompression in the Portable Http Client will work. In this case it can fall back on the .NET 4.0 compression libraries.
A somewhat annoying design decision for this library is that decompression is not turned on by default. Each time you want to make an Http request you need to check the SupportsAutomaticDecompression property and then set the AutomaticDecompression property to “DecompressionMethods.GZip | DecompressionMethods.Deflate”. While the HttpClientHandler could be hidden behind a factory method, that won’t work for third-party libraries.
UPDATE
HttpClient no longer depends on Microsoft.Bcl.Compression.
Microsoft’s Base Class Library team has reconsidered its position and changed the design of HttpClient so that it no longer depends on the native libraries inside Microsoft.Bcl.Compression. Instead it will use decompression code written in a managed language, allowing its use on all platforms even with the “Any CPU” compiler setting.
Silverlight is still the odd man out. When using the Browser Stack, the AutomaticDecompression property is ignored and all HTTP requests support both gzip and deflate. When using the Client Stack the property is again ignored and requesting compression is not allowed. (In fact, the Client Stack will throw an exception if you try to manually set an Accept-Encoding header.)
Even stranger, this doesn’t mean you can’t use compression with the Client Stack. Immo Landwerth writes, “However, the Content-Encoding header will be honored when reading responses, i.e., responses are automatically decompressed using the algorithm specified by the Content-Encoding response header.”
Microsoft.Bcl.Compression remains unchanged and will continue to require native components.