This project is read-only.

Creating uncompress zip on the fly in

Sep 2, 2011 at 2:44 PM


I was trying to to create page that returns a dynamically generated uncompressed zip.

Filesize may vary between 50MB to 2GB.

On my local machine running it in debug mode succeeds about half the time I try calling it (and half the time the save method throws an unhandled execption) and on the server it just hangs. Any sugestions about changes that might affect stability?

Also, as I understand it  the zip.Save(System.IO.OutputStream) should work with only the buffersize and continuously send the result to the outpustream.

Am I correct here?

And the actual code (Nothing fancy, basically the usual example):

    private static void SendZipArchive(string fileName, string storagePath)

            //if (!System.IO.Directory.Exists(storagePath))
            //    HttpContext.Current.Response.Write("File not available.");
            //    HttpContext.Current.Response.End();
            string[] fileNames = System.IO.Directory.GetFiles(storagePath);

            String ReadmeText = "This is a zip file dynamically generated at " + System.DateTime.Now.ToString("G");
            HttpContext.Current.Response.ContentType = "application/zip";
            HttpContext.Current.Response.AddHeader("content-disposition", "attachment; filename=" + fileName);
            using (ZipFile zip = new ZipFile())
                //zip.ForceNoCompression = true;
                zip.CompressionLevel = Ionic.Zlib.CompressionLevel.None;
                zip.BufferSize = 65536 * 8;
                foreach (string filePath in fileNames)
                    zip.AddFile(filePath, string.Empty);


            //throw new NotImplementedException();
Regards Martin
Sep 2, 2011 at 3:38 PM

Hello Martin,

Your understanding of the ZipFile.Save() method and its use of the specified buffersize is correct.

But, ASPNET by default buffers output written to Response.OutputStream.  That means, while DotNetZip will not keep all of the zipped content in memory, ASPNET will.  To tell ASPNET to NOT buffer the output, you must set Response.BufferOutput to false.  This will cause ASPNET to use Chunked Transfer-encoding of the HTTP response - in practice it will transmit the data bytes to the browser/client, as your app writes them into Response.OutputStream.

You can observe this by using an HTTP Debugging proxy like Fiddler.



Sep 2, 2011 at 10:23 PM

Hello Dino,

Thanks, I should have thought of that one myself. I'll fire up fiddler, turn of the buffering and continue testing come monday.

My initial idea was actually to manually make a zip header and a zip ending and just stream it with the files in between ( no need for libraries or any processing of files since there is no compression), but I decided to go with the possibility to add compression if we were going to be reusing this for other stuff.

Cheers Martin.