I'm not clear on what you are doing - you mentioned "directing it as a stream into browser", but I don't see anything having to do with the browser or Response.OutputStream in your code.
I do see a bunch of things in your code that relate to outside code - "mystery code". Before I will be able to help you very much, you need remove some of those variables to isolate the role of DotNetZip in the logic. With the
code you have sent, it is not at all clear that the problem you are experiencing is directly related to DotNetZip. There are too many moving parts.
I can make a few suggestions, though.
If you want to save a zip to the browser from an ASP.NET app, then I suggest calling zip.Save(Response.OutputStream). By writing to a MemoryStream, all of the zip content must be realized in memory before any byte is written to the browser.
This can result in a great deal of memory stress on a loaded system . It can be much faster to write directly to Response.OutputStream.
Of course you may have good reasons to save to a MemoryStream - maybe you are caching the result. In that case I have some hints here as well. Rather than doing this:
byte zipbytes= new byte[msr.Capacity];
//msr.Position = 0;
msr.Read(zipbytes, 0, msr.Capacity);
Can I suggest you do something like this:
byte zipbytes = msr.ToArray();
If you use the former method, you will get a byte array which is end-padded with many zeroes. I don't think you want that, as it can be larger than the aggregate size of the input files, which defeats the purpose of compression.
Internally, within the MemoryStream, there is a byte. As you write into the stream, this byte array gets re-allocated, it "grows". The
Capacity of the MemoryStream is the maximum length of the internal buffer, while
Length gives the length of the content in the stream. Suppose I new a MemoryStream, and (suppose) it allocates an initial buffer of 1024 bytes. If I write 1025 bytes to the MemoryStream, it will grow, and possibly double its internal buffer
in size to 2048 bytes. The Capacity will be 2048, but the Length will be 1025. The ToArray() method will get a byte array of the correct Length, with no trailing zeroes. Using your method, you will get a byte array of length 2048, with 1023 bytes of zero at
The bad news is that I was unable to reproduce the problem you described relating to the missing CRC. It *could* be related to the trailing zeros; It depends on how those other tools read zip files. But I tried it with the Windows shell
compressed folders, and had no problems.
As I said earlier, it seems to me there are many steps in the process, and I am not at all clear on where the error occurs. I suggest that you take one step back and debug the process in pieces. Is it really true that the CRC is missing when
you first create the zip stream? Are there trailing zeros in the zip stream? The "result" that you get from GetRptFile() - is it valid content to start with? These are things I cannot help you with.
If you can produce a test case in a console app, that clearly demonstrates the problem, OR a very clear description of how I can do the same, I would be happy to look at it again.