This project is read-only.

Success displaying progress and in large compression. Follow these tips.

Jan 21, 2014 at 3:43 AM
Dear Friends:

I have been developing with the SevenZipLibrary for a number of months. I ran into some issues, but most I was able to resolve. I am writing you to encourage your own development with the library and to explain a major shortcoming in what is actually the documentation of the library.

In the FormMain.cs, which is the primary sample code available on the product, progress for compressions is presented as being accomplished with these lines of code:

cmp.FileCompressionStarted += new EventHandler<FileNameEventArgs>(cmp_FileCompressionStarted);

void cmp_FileCompressionStarted(object sender, FileNameEventArgs e)
l_CompressProgress.Text = String.Format("Compressing \"{0}\"", e.FileName);

Today, such approaches are totally unworkable. This sample code was written for .Net Framework 2.0. Since then Microsoft new releases of the .Net vastly changed the security system of .Net. The sample code was never updated.

Specifically, Microsoft DOES NOT want programmers running long running programs and displaying progress directly. Microsoft has deliberately coded .Net so that these types of approaches fail and fail badly. Progress done immediately in today’s .Net will (a) freeze the program so you can not even move the form, (b) produce exceptions such that the progress you are showing will simply cease to show, and (c) there is even a more nasty .Net exception that will kill the processing of the library itself. There are reports on the internet of developers claiming (a) that the SevenZipLibrary fails in showing progress and (b) that the library simply fails to compress large archives. These bad approaches in using the SevenZipLibrary have discredited the product to a degree.

The good news is that none of these harsh findings are correct. The library is fine, but you as a developer must implement this library in a totally different way to (a) avoid locking the main program, and (b) to avoid failures in compressing large archives.

The approach that will work without failure is that you must instead – as Microsoft forcefully recommends and now demands – run your compressions within a thread by itself. When you run that compression within that thread and the “cmp_FileCompressionStarted” event occurs, that thread should then send this information back to the main form via a delegate as a message. When the main form has the delegate message fired within it, the method called can then display detailed progress however you wish (a) without locking the program, and (b) even for very large compressions, all without failure whatsoever.

To be successful in your use of SevenZipLibrary, please follow this guidance for your programming without exception.


Pastor Burt, .Net Developer
Programmer for over 40 Years