Please use System.IO.Compression! A fork of the DotNetZip project without signing with a solution that compiles cleanly. This project aims to follow semver to avoid versioning conflicts. DotNetZip is a FAST, FREE class library and toolset for manipulating zip files. Use VB, C# or any .NET language to easily create, extract, or update zip files.
I couldn't find a previous issue addressing this as a cursory glance did not reveal similar issue.
This is more of a discussion question around the interface and high-level implementation of ZipEntry.
To start, why is ZipEntry from ZipInputStream not a separate, base class of the ZipEntry acquired from ZipFile? (That spurs a follow up I will note further below)
The current 'interface' allows for methods that cannot be used when working with a directly instantiated ZipInputStream (where the ZipEntry must be provided from a ZipFile to use Extract(), for example). While this is documented, it makes for a very cluttered intellisense experience and requires more documentation reading and experimentation to figure out how ZipInputStream was intended to be used. For example, using ZipInputStream, it is not immediately obvious how to do something as simple as filtering one zip into a new zip without the use of the filesystem. My guess as to why this is, is that the performance heavily depends on seeking streams to a file handle instead of doing everything in memory (let me know if that sounds right).
So to follow up on the initial question, I predict a concern with the proposal arises around reusability of ZipInputStream (because writing and maintaining a ZipInputStream for two ZipEntry types as proposed could be a nuisance). I don't know if generics would be a good solution or if a derived ZipInputStream for ZipFile entries would suffice. But either seems preferable (as a consumer of the package) to seeing unusable methods being presented via intellisense.
I couldn't find a previous issue addressing this as a cursory glance did not reveal similar issue. This is more of a discussion question around the interface and high-level implementation of
ZipEntry.To start, why is
ZipEntryfromZipInputStreamnot a separate, base class of theZipEntryacquired fromZipFile? (That spurs a follow up I will note further below)The current 'interface' allows for methods that cannot be used when working with a directly instantiated
ZipInputStream(where theZipEntrymust be provided from aZipFileto useExtract(), for example). While this is documented, it makes for a very cluttered intellisense experience and requires more documentation reading and experimentation to figure out howZipInputStreamwas intended to be used. For example, usingZipInputStream, it is not immediately obvious how to do something as simple as filtering one zip into a new zip without the use of the filesystem. My guess as to why this is, is that the performance heavily depends on seeking streams to a file handle instead of doing everything in memory (let me know if that sounds right).So to follow up on the initial question, I predict a concern with the proposal arises around reusability of ZipInputStream (because writing and maintaining a ZipInputStream for two ZipEntry types as proposed could be a nuisance). I don't know if generics would be a good solution or if a derived ZipInputStream for ZipFile entries would suffice. But either seems preferable (as a consumer of the package) to seeing unusable methods being presented via intellisense.