Stream out of Scope

Apr 30, 2008 at 4:30 AM
Perhaps I'm missing something.
I'm trying to add different streams to the same zip file from within different functions.
The problem is that after AddFileStream is called, the corresponding stream cannot go out of scope while the ZipFile object is still in scope. If it does I get an exception. This occurs even if a Save() function is called right after AddFileStream.
Trying to create a separate ZipFile object within each function doesn't work either, since the last function call then just overwrites the previous ones.
Is there a way to do this?


May 8, 2008 at 3:23 PM
I'm running into the exact same issue - any input would be truly appriciated.

Ellery
May 8, 2008 at 4:58 PM
So here's my solution: I no longer use DotNetZip for saving. (However, I still use it for loading.)
For saving I use a utility called ZipStorer, located at http://69.10.233.10/KB/recipes/ZipStorer.aspx in the CodeProject by a guy called Jaime Olivares.
It's a small c# program that creates a zip archive, but WITHOUT COMPRESSION. (I didn't really want compression anyhow, since most of the files I'm archiving are already compressed.) So I use ZipStorer to create the zip, and it has no problems with adding to streams from different functions.
I still use DotNet Zip to read from a zip.
Bit strange using a separate libraries for reading and writing, I agree. However, can't use DotNetZip for both because a) The stream problem mentioned above, and b) No way to turn off compression (I posted a question about this, but nobody had any suggestions).
And can't use ZipStorer for both because (so far) it only has the capability to write to a zip, not to read from a zip. Even if ZipStorer added reading capability from uncompressed zips, I'd probably still use DotNetZip for reading. This is because I can then also robustly handle zips created outside my app.
From my testing so far, this solution seems robust.
But if you want to compress on writing, you'll obviously need an extra layer.
Hope this helps.
Adrian
May 9, 2008 at 7:12 PM
I actually fixed my issue. The root of my problem was that I was closing the StreamWriter I used to fill them stream. I commented out the streamWriter.Close() calls in all functions, and it works fine now.


aadrian wrote:
So here's my solution: I no longer use DotNetZip for saving. (However, I still use it for loading.)
For saving I use a utility called ZipStorer, located at http://69.10.233.10/KB/recipes/ZipStorer.aspx in the CodeProject by a guy called Jaime Olivares.
It's a small c# program that creates a zip archive, but WITHOUT COMPRESSION. (I didn't really want compression anyhow, since most of the files I'm archiving are already compressed.) So I use ZipStorer to create the zip, and it has no problems with adding to streams from different functions.
I still use DotNet Zip to read from a zip.
Bit strange using a separate libraries for reading and writing, I agree. However, can't use DotNetZip for both because a) The stream problem mentioned above, and b) No way to turn off compression (I posted a question about this, but nobody had any suggestions).
And can't use ZipStorer for both because (so far) it only has the capability to write to a zip, not to read from a zip. Even if ZipStorer added reading capability from uncompressed zips, I'd probably still use DotNetZip for reading. This is because I can then also robustly handle zips created outside my app.
From my testing so far, this solution seems robust.
But if you want to compress on writing, you'll obviously need an extra layer.
Hope this helps.
Adrian