File Zipping in .NET

March 30, 2015 - .NET, C#, Programming

We have had a lot of different options for creating Zip Files in .NET Applications for some time. .NET 4.5 has added built-in framework-based support for Zip files, which is a very valuable tool. The absence of built-in ZIP support meant there have been several useful libraries that provided that capability. In this post I will be comparing three such alternatives- DotNetZip, SharpZipLib, and the built-in .NET Framework 4.5 implementation.

In particular I am focusing on ease of use- how much code does it take to create a zip file? Libraries that provide these capabilities often fall into categories- libraries which make something possible, and libraries which make it easy.

First, we should look at the “testing framework” that will be used. The idea is straightforward- we want to simply have each one zip up a given folder to a given zip file, with different implementations. an Interface is the obvious choice:

A single-method interface. We’ll create an implementation for each of the selected libraries implementations, then test each one. Though performance is not the primary focus, we’ll go ahead and try to implement a basic average/total framework over 100 runs:

Nothing fancy- just as described above. A short helper will ensure the folder exists and the target zip does not when running one of the instances, simply so we don’t need to implement it in every single one.


DotNetZip is the one I was most familiar with before this particular experiment, having used it in a few projects.

Incredibly straightforward, overall- create a new Zip File, add the directory to it, and save the zipfile.


I don’t remember using SharpZipLib but I do remember discounting it over DotNetZip for some reason when I was originally looking for a ZIP tool. I was reacquainted with my reasoning in the process of writing the implementation here, which should be fairly obvious:

This is just plain silly- this I suppose falls into the category of a library that makes something possible but doesn’t make a big effort to make it easy, or leaves out higher-level capabilities. Effectively when using SharpZipLib you’ll need to deal with the insertion of each ZipEntry yourself, or create your own wrappers for it. The wrappers are not super difficult to make but if you already have a zip task you want to write simply that is more overhead that needs to be considered.

Framework 4.5’s System.IO.Compression

The Framework implementation is as I mentioned a great addition to the framework. It’s usage is also surprisingly easy:

If you include a reference to System.IO.Compression.FileSystems, you get access to some helper capabilities such as the ZipFile class, which I use here- the method is literally identical the interface method I defined myself.

I think the built-in .NET Version is the clear winner here, but DotNetZip is certainly a better alternative if using the 4.5 Framework has it’s other considerations. SharpZipLib is surprisingly unfluent and requires a lot of boilerplate to be used well, but it is an excellent low-level library for compression overall. Additionally, we have the performance considerations. After a single run, the program emitted the following results. I was testing with a reasonable set of files including a number of PNG images, text files, source code, and other data.

DotNetZip comes in first, with the Framework lagging just behind. SharpZipLib executed a full second longer with each execution, which may be due to the lack of optimization within the program itself (Debug mode) since more of the processing was actually taking place within the code in the project. Unfortunately, this turned out to not be the case- setting the configuration to release did not significantly improve the performance of the SharpZipLib implementation, though it may simply be a less-than-optimal implementation. However if so, that does raise the further point that having to write your own boilerplate means you may not write the most effective and optimal boilerplate for a given task.

Have something to say about this post? Comment!

Tags: ,