This project is read-only.

Sfx file is HUGE compared to zip

Apr 4, 2011 at 7:50 PM

I am not sure what is normal for DotNetZip, but I'm a little disappointed in the size discrepancy.  We used to use a console version of WinZip that we licensed to created self-extracting zip files.  We are extracting a 1kb config file to a specific location on a PC.  In upgrading our toolset, we decided that DotNetZip was worth looking at, and works great except for the self-extracting zip part.  Here's what I have:


string zipFile = Path.Combine(_stagingDir, clientName.ToLower().Replace(" ", "_"));
using (var zip = new ZipFile(zipFile + ".zip"))
    zip.CompressionLevel = Ionic.Zlib.CompressionLevel.BestCompression;
    zip.AddFile(theFile, "/");

CreateSfx(new ZipFile(zipFile + ".zip"), zipFile + ".exe");

This part works great - it generates at 1kb zip file, as expected.  Love it.  Then I want to create the exe ... (I took this out of the using loop so I could keep the zip file behind as well - which is something else I need to look at, it bombed if zip.Save() was called):

public static void CreateSfx(ZipFile zip, string zipFile)
    // set the options
    var sfxOptions = new SelfExtractorSaveOptions();
    sfxOptions.Flavor = SelfExtractorFlavor.ConsoleApplication;
    sfxOptions.Quiet = true;
    sfxOptions.DefaultExtractDirectory = "C:\\ConfigFileLocation";
    sfxOptions.ExtractExistingFile = ExtractExistingFileAction.OverwriteSilently;

    // create file
    zip.SaveSelfExtractor(zipFile, sfxOptions);

This part isn't so great.  The resulting file - from the 1kb zip file - is a 506kb exe.  If I take the zip file created by DotNetZip and run it through the WinZip "Create Self-Extracting Zip" tool, it creates a 20kb exe, which is what I'm looking for.

Am I missing something?  Is this normal?

Apr 4, 2011 at 9:26 PM

yes, that sounds about right. DotNetZip is 400k (ish) and when you create an SFX, it embeds the DotNetZip library into the exe.  I realized this was overkill, when I did it - of course you don't need a full zip library to do extraction, you only need the extraction capability.  I created a workitem to track the feature request, but I've never implemented it.

If I optimized the embedded logic for SFX, I think the resulting SFX would be much much smaller but I'd estimate that it would still be much larger than 20k.

Apr 4, 2011 at 9:35 PM

Cheeso - I didn't realize it was embedding the whole library in there - that would definitely explain it.  I'd love to see a smaller sfx-only library get embedded.  This project being open-source and all, maybe I'll have a look and see if I can come up with something.  I'll let you know if I come up with a solution that minimizes the space used.

Apr 6, 2011 at 4:04 PM

Yup - the whole library.  I thought about fixing it.  It isn't necessary to include the parts that do encoding.  But even so, it's hard to leave things out.  If the zip is not WinZip AES encrypted, then you wouldn't need that entire subset, but... currently that logic is just bindled into the single assembly.  You would never need Zlib or GZipStream, since zip files use only DeflateStream. 

It would require some creative restructuring of the packaging of the library.

The most technically attractive idea is to produce a C/C++ version of the unzip logic, and embed that; that would allow the size of an SFX to be reduced pretty nicely and would also eliminate the dependency on .NET.   But that increases the scope of development and testing pretty dramatically.  It would be a completely new implementation of unzip. 

In the end I didn't feel satisfied with any of these approaches, so I did nothing.