Portable Compression is now stable

Portable Compression is now stable

Rate This
  • Comments 8

Today we are happy to announce that our portable compression library is now available as a stable NuGet package.


Microsoft.Bcl.Compression provides the following APIs in a portable fashion:

It’s supported on the following platforms:

  • .NET Framework 4.5
  • .NET for Windows Store apps
  • Windows Phone 8
  • Portable Class Libraries targeting these platforms.

.NET 4.5 and .NET for Windows Store apps already ship compression with the platform itself, so applications for those platforms usually don’t need this package. However, if the application is consuming a library that uses this package then the application also needs to reference this package in order to ensure application and library code interoperate nicely.

Now let’s have quick look on how you would use this package in a phone application.

Consider an app that shows a random poem from a collection of poems. The poems are represented as text files. In order to keep the app small, we compressed all poems using gzip. Upon request the application startup, a random poem is selected and read from the application data. In order to decompress the contents of the poem, we use the GZipStream class.

    private static string ReadRandomPoem()
        int randomPoemNumber = 42; // Super random
        string poemName = string.Format("Poem{0}.txt.gz", randomPoemNumber);
        using (Stream stream = OpenApplicationFile(poemName))
        using (Stream decompressed = new GZipStream(stream, CompressionMode.Decompress))
        using (StreamReader reader = new StreamReader(decompressed))
            string text = reader.ReadToEnd();
            return text;

In the next version of the app we allow the user to select a form of poem, such as sonnet or haiku. To implement this, we decide to store all poems that share the same form in the same ZIP archive. To read a ZIP archive we use the ZipArchive class.

    private static string ReadRandomPoem()
        int randomPoemNumber = 42; // Still super random
        string poemName = string.Format("Poem{0}.txt", randomPoemNumber);
        using (Stream archiveStream = OpenApplicationFile("haikus.zip"))
        using (ZipArchive archive = new ZipArchive(archiveStream, ZipArchiveMode.Read))
            ZipArchiveEntry zipArchiveEntry = archive.GetEntry(poemName);
            using (Stream stream = zipArchiveEntry.Open())
            using (StreamReader reader = new StreamReader(stream))
                string text = reader.ReadToEnd();
                return text;


With the power of native code…

…comes great responsibility. Or at least the need to select the right architecture.

As explained in our original announcement, Microsoft.Bcl.Compression uses a deflate algorithm implemented in native code. This means that Microsoft.Bcl.Compression requires CPU-specific binaries to be deployed by the application.

.NET Framework 4.5 and .NET for Windows Store apps provide the CPU specific binaries with the operating system. However, if a phone application depends on Microsoft.Bcl.Compression you may receive the following error at compile time:

Phone Application: Project must install NuGet package Microsoft.Bcl.Compression.

This error is directing you to add the NuGet package to the phone project in order to ensure that the correct native dependencies can be packaged.

Also, for Windows Phone, the binary required depends on where the app is deployed, and using Microsoft.Bcl.Compression with AnyCPU is selected results in the following error:

Phone Application: Microsoft.Bcl.Compression does not support the currently selected platform of 'AnyCPU'. The supported platforms are 'x86' and 'ARM'.

The required architectures for Windows Phone are as follows:

  • x86 to deploy to Windows Phone Emulator
  • ARM to deploy to Windows Phone devices

By selecting the correct architecture for the deployment target, the application will package the required native dependencies.

See MSDN for more details on how to configure your solution.

Improved Package Restore

We also shipped an update to Microsoft.Bcl.Build that addresses some of the key issues with using NuGet’s package restore feature, specifically around the fact that projects using our packages will not load in Visual Studio until packages are restored. We fixed this by using an optional import and by adding a target that fails the build with an actionable error message in cases packages were restored in the same build.

We applied the same fix to Microsoft.Bcl.Compression. For more details, have a look at our announcement for Microsoft.Bcl.Build.


Microsoft.Bcl.Compression is now available as a stable release on NuGet which means you can start using it in production.

Please let us know what you think!

Leave a Comment
  • Please add 6 and 6 and type the answer here:
  • Post
  • Just a question, does this library support extracting  or even creating password protected Zip files?

    If yes - thanks!

    If not, do you plan to add this feature?

  • @Martin: unfortunately no. Our NuGet package provides a portable view across multiple platforms. However, on the platforms that support compression we still (have) to use the version that ships with it (due technical reasons). That means, we can't easily provide new features if this means touching existing binaries.  That being said, it may be possible to provide this feature on top but we haven't thought about this particular feature yet.

    It would help us if you would file a request on user voice. As promised in the following post, if you let us know via our Twitter handle @dotnet, we'll tweet it to make sure interested folks can vote on it as well. This allows us to prioritize this feature against other feature work. blogs.msdn.com/.../advise-the-net-framework-team.aspx


  • I don't need personally the support for password-protected zip files, but one developer I know had quite some troubles finding working library for WinRT supporting these archives. He solved it using SharpCompress.

  • Would you guys please convert tesseract-ocr project for Windows RT (x86 and ARM)? It requires zlib which can be compiled for Windows Store stackoverflow.com/.../863980..

  • @Nate: Our team is the .NET team which means that we provide managed APIs. It seems that tesseract-ocr is a native project, so it seems more appropriate to expose it as a native WinRT component; however since this isn't exactly part of our mission statement I don't think we would provide this functionality.

  • I ran into a quite unexpected behavior that I consider a bug. I first described it here in a blog post:


    And then I found an issue on Connect about that. Apparently it's an issue with .NET 4.5 (worked in 4.0): connect.microsoft.com/.../gzipstream-fails-to-write-to-memorystream-in-net-4-5

    Unfortunately, it's marked as "won't fix" - maybe that decision should be reconsidered as it is an issue that has the potential to go unnoticed at first and leave your data somewhat inconsistent/corrupted. A good compromise in my eyes would be to make Flush() actually do something and not just a no-op. That would allow for more obvious workarounds.



  • Switching between different architectures to run on Emulator vs Device is really annoying! is this going to be fixed?

  • @Mohammed Adenwala: Unfortunately there is nothing we can do to fix this -- besides fully re-implementing the compression algorithms in native code, which is very costly and thus there are no plan for doing so.

Page 1 of 1 (8 items)