Portable Compression is now stable

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

Microsoft.Bcl.Compression

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

Compression streams (Deflate & gzip)
Reading and writing ZIP archives

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.