This project is read-only.

v1.8 sfx and utils tool

Jun 12, 2009 at 10:22 PM

Has anybody been able to get a self extract exe to work which has been build with the v1.8 library. It appears to error when trying to load the form. I would use the v1.7 but I really need the ability to add new files to an existing sfx.

Also I'm not able to get the utils form tool to work either. At first I thought this was an issue with having v1.7 installed on the same box but Ive since tried it with another machine and the utils tool just errors.

Seems to be an issue with the build?? or am i missing a component on my machine. Both boxes have .net 2.0.

cheers nick

Jun 13, 2009 at 4:49 AM

Hey Nick,

When I deliver the release, I run through a series of tests, and those tests include the self-extracting archive tests. 

I just ran the SFX tests again, and they ran successfully. 

You mentioned the winforms SFX "errors".  What does that mean, exactly?  What error do you see? What happens ?

If you can give me some more information, I'll try to help sort it out with you.


Jun 13, 2009 at 1:28 PM

Hi Cheeso,

On my own laptop which has not had the v1.7 stuff installed, Ive unpackaged the Utils zip  and tried to run the DotNetZip-WinFormsTool.exe - the generic windows send error details window opens. This contains the following details:


EventType : clr20r3     P1 : dotnetzip-winformstool.exe     P2 :     

P3 : 4a32a3a3     P4 :     P5 :     P6 : 4889dee7

P7 : 2328     P8 : 5d     P9 : system.argumentoutofrange  

This same behaviour happens on my dev  machine as well. If I remove the v1.8 and install the v1.7 (either msi or zip build) the v1.7 forms tool opens correctly.

I've built an sfx package I've built which has password encryption (aes 256) and contains multiple password pkzip encrypted zips. When excuting this exe via cmd i get the message "Program to big to fit in memory". However the sfx file is only 725 bytes.

I'm assuming these 2 issues are connected and nothing to do with the build of the test exe however below is the code im using to created the archive. Basically i run through a directory pulling out a list of .vox files. If a zip already exists of the same name then it gets added else I create a new zip and add the file. A Second pass is then done using the zip file names to create a sfx package. (file names contain datetime strings). 


        private void BuildZip(List<string> filepaths, string zipFullName, string passWord, bool encryptAES256, bool selfextractexe, List<string> ammendedFileNames)
            if (!File.Exists(zipFullName))
                using (ZipFile zip = new ZipFile(zipFullName))
                    zip.CompressionLevel = Ionic.Zlib.CompressionLevel.BestCompression;
                    zip.Encryption = encryptAES256 ? EncryptionAlgorithm.WinZipAes256 : EncryptionAlgorithm.PkzipWeak;
                    zip.Password = passWord;                    
                    foreach (string fi in filepaths)
                        zip.AddFile(fi, String.Empty);
                    if (selfextractexe)
                        zip.SaveSelfExtractor(zipFullName.Replace(".zip", ".exe"), SelfExtractorFlavor.WinFormsApplication);
                    else { zip.Save(); }
                using (ZipFile zip = ZipFile.Read(zipFullName))
                    foreach (string fi in filepaths)
                        zip.CompressionLevel = Ionic.Zlib.CompressionLevel.BestCompression;
                        zip.Encryption = encryptAES256 ? EncryptionAlgorithm.WinZipAes256 : EncryptionAlgorithm.PkzipWeak;
                        zip.Password = passWord;
                        zip.AddFile(fi, String.Empty);

hopefully Im not doing anything stupid...(has been know before).

If you need any more info etc just let me know. (the only other way i can think to test it is to download the source code and debug through it?)

cheers Nick


Jun 13, 2009 at 4:39 PM

Wow, thanks for reporting that.   I will have a look and get back to you.

Jun 13, 2009 at 5:00 PM

ok, that's been fixed. Get the new release v1.8.3.21. Thanks for reporting it Nick.

Jun 13, 2009 at 5:43 PM

No worries mate, sounds like it was an easy fix. 

Must say so far I've been very impressed with the library... much more easy to use than the ICSharps #ZipLib.

How long do you think it'll be before this release is classed as stable?

Thanks for sorting the fix out so quickly. I'll download the new release and give it a go later this evening.

cheers nick

Jun 13, 2009 at 8:20 PM

Hey Nick, it was an easy fix, thanks for reporting it. Also thanks for the comments about the ease-of-use - that's what I was going for.

I was expecting DotNetZip to be classified as stable or "officially released" in May, but there have been a few bug reports dribbling in, so I've held off.
My new estimate is, by the end of June, and barring a burst of problems reported by people, I'm confident in that date. 
Between now and then, there's nothing more I will do to the library, except write a few more tests.
I think v1.8 is solid and reilable enough to use now, but before I pronounce it so, I'd like a few more weeks testing.  


Jun 15, 2009 at 1:01 PM

Hi Cheeso... Have only just got round to testing the v1.8.3.21 and I've come across a related issue.

First off... the utils app works perfectly. :-)

If I build an sfx (GUI) with a single file - it unpackages correctly. If I build an sfx with multiple files, but add them at the time of creation - it unpackages correctly.

However.... if i build an sfx with a single file, then reopen it and add another file (  using ZipFile.Read(zipFullName) as per the 'else' statement in my code above) ... then the sfx will not unpackage.

If this is built with no password encryption then we get the following error:

the NTVDM CPU has encountered an illegal instruction.
CS:0000 IP:0077 OP:f0 37 05 0c 02

If the sfx is built with password encryption (aes256) then the extractor appears to just hang

When stepping through my code the Count is correct after adding the second file to a previously created (and closed) exe.

Also the msi installer for the runtime requires net 3.5 whereas the utils installer doesn't (minor issue but thought I'd mention this)

Let me know if you require any further info or a test file

cheers Nick

Jun 15, 2009 at 2:32 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Jun 15, 2009 at 2:34 PM

Thanks, Nick, your feedback is valuable.


Jun 15, 2009 at 2:36 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Jun 15, 2009 at 3:47 PM

Nick, I Think the reason the updated SFX is not running is because you have called ZipFile.Save() which produces a regular zip file. 
If you call ZipFile.SaveSelfExtractor() after adding a file, it should work for you.
Can you check that and get back to me?

I will change the pre-reqs for the runtime - good catch.

Jun 15, 2009 at 4:50 PM

hey Cheeso.... thanks for the prompt response... I've tested the above and can confirm that solution works correctly for both encrypted and non-encrypted sfx. :-)

My only comment is maybe the ZipFile.Save() method should throw a custom error if the file is of type sfx? would stop this problem immediately.

cheers Nick


Jun 15, 2009 at 6:53 PM

OK, let's think about that. 

When you have a ZipFile instance in memory, there's no way to tell whether it came from reading an EXE/SFX, or a zip file.  (or a stream, or a byte array).

I guess it's possible for ZipFile.Save() to throw an error if the extension of the file to be saved is .exe.  Does that make sense to you? 

Jun 15, 2009 at 6:58 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Jun 15, 2009 at 8:06 PM

ok to summarize, the workaround for the problem you experienced was to call SaveSelfExtractor. 

From your mail, I took three workitems:

7892 - MSI installer prereqs were wrong.
7893 - Calling Save() after reading an SFX results in an unusable exe file
7895 - Winforms SFX loops endlessly when files exist and WantOverwrite is not checked

Thanks for helping to make DotNetZip better.

These are all fixed in v1.8.3.25.