Feb 9, 2009 at 11:28 PM
Edited Feb 12, 2009 at 7:25 AM
An update for the v1.7 release. The status of this release is now final.
As of right now, v1.7 has been revved to v18.104.22.168. You can get the release here:
If you have previously use DotNetZip, the big new things in v1.7 are:
AES encryption, ZIP64, Compact Framework support, Unicode improvements, Compression improvements (and compression levels).
Now, a more detailed review of what is new and changed in v1.7 as compared to v1.6:
This release brings changes for USERS of the library, and also for DEVELOPERS who may wish to re-use the DotNetZip source code directly.
- there is a namespace change: From Ionic.Utils.Zip to Ionic.Zip . The Utils part of the namespace was meaningless, and as the library gained new features it became more and more evident. The change means old code will not recompile. It should be a fairly
straightforward port - just do a global search-and-replace , swap "Ionic.Utils" with "Ionic" in all your source modules. This goes for Using statements (or imports in VB) as well as in code references of fully-qualified type names (Ionic.Zip.ZipFile
instead of Ionic.Utils.Zip.ZipFile). Concurrent with this namespace change, there is a change in the name of the assembly, from Ionic.Utils.Zip.dll to Ionic.Zip.dll. This may imply changes in your deployment scripts.
- the eventing model is completely revamped. For those of you who have used the v1.6 library with the initial eventing support, I updated the eventing to support much finer-grained notifications. Previously, the SaveProgress event fired for each Entry saved
in the ZipFile. Now the SaveProgress event fires with each batch of data for every file. This will allow you to produce a winforms app with two progressbars, for example: one for the progress on the zipfile itself, and one for the progress on the current
entry. I do this in the WinForms example app to illustrate how to do it. Porting your existing code that depends on eventing will involve some significant effort. The main ZipFile interface does not change, and if you do not use eventing now, it means
no change to you. But if you do use eventing now, you will have to write some new code to move to v1.7.
- v1.7 introduces support for zip64. With this change the CompressedSize and UncompressedSize properties on the ZipEntry class become Int64, instead of Int32. This should be a straightforward port for your apps.
- the TrimVolumeFromFullyQualifiedPaths property has been removed. This property was unused and unloved, but it is worth mentioning. It was a vestige of a prior broken design where the library encoded drive letters into the zipfile. The behavior and the
property are both gone now.
- all the ZipFile ctors that take Streams were removed. If you want to save to a stream, call Save(Stream). I don't know what I was thinking when I introduced those ctors anyway - there were 10 ZipFile constructors (yikes!) and 4 of them were just for
the stream support. All of the 4 were completely unnecessary and redundant - you can do all what you need with streams without these ctors. So I just yanked them. This implies a simple code change in your apps. If you use one of the ctors that takes a
stream parameter - you need to move the stream from the ctor to the Save() call.
Those are the breaking changes.
Also interesting for users of the library, there are also other changes, introducing new features and capabilities.
- Zip64 support - for large archives.
- .NET Compact Framework support. Now the apps you write on .NET CF 2.0 can create and read zip files.
- AES encryption support - WinZip-compatible, FIPS-197 compliant. (sorry, not available on CF)
- Unicode improvements.
- inclusion of a managed zlib library, for better compression (which is also availabile on CF2.0). This last bit is of minor interest if you are just doing ZIP files, but is really interesting if you want to do ZLIB compression in general. For example,
if you are building a SSH tool, or some other socket program that needs to communicate with an agent on the other end that speaks ZLIB. The Zlib stuff, which I am calling DotNetZlib, is consumable in its own assembly (Ionic.Zlib.dll), and is completely
independent of DotNetZip. DotNetZip depends on DotNetZlib, but the converse is not true. Like Ionic.Zip.dll, Ionic.Zlib.dll works on the regular .NET Framework as well as the .NET Compact Framework.
To take advantage of these new features you will have to write new code.
And finally, of course there are improvements that you get for free with a recompile. Things like perf improvements and bug fixes for multi-thread apps.
On the performance improvements - DotNetZip now reads the zip file differently. To read a really large zip file with thousands of entries now takes 3 seconds, where with v1.6 it could take (literally) minutes. If you have to manage large zip files with lots
of entries, this alone is worth the upgrade. Also, with the managed ZLIB, the compression is measurably better - like 10-20% better. But YMMV.
That's it for USERS.
For DEVELOPERS who use the source code, there key changes are in the project structure.
- New projects in the solution specifically for .NET CF
- New projects for ZLIB and ZLIB Tests
- Renamed Projects to clarify what they do. Think of this as a refactoring of the project organization, not a refactoring of the code.
- New "meta" projects - that include no source modules. They merely use ILMerge to combine the ZLIB and ZIP assemblies together. This preserves the "one assembly to deploy" packaging. There is one project for CF and one for regular
- A new "Reduced" assembly that compiles DotNetZip to eliminate the SFX support - for those devs who don't want the SFX and could use a smaller DLL.
- I removed the .pfx and .snk files from the source distribution. If you want to build a signed assembly, you will have to sign it with your own key. I will continue to produce a signed assembly for USERS, but I won't redistribute my keys any longer.
I also added new tests and renamed some source files and etc. Nothing really major there. Of note - the replacement of System.IO.Compression with DotNetZlib required changes in just 3 lines in the source. Every mention of System.IO.Compression.DeflateStream
was replaced with Ionic.Zlib.DeflateStream. Simple. Easy.
What has not changed: DotNetZip continues to use CodePlex to host the project. The library continues to get good reviews, and good suggestions and feedback from users like yourself. Thanks for pitching in. Finally, DotNetZip continues to be "donationware".
(And DotNetZlib is also). It is free to use, and is open source. But if you find value in the library, please consider donating: http://cheeso.members.winisp.net/DotNetZipDonate.aspx
As always, I would love to hear feedback and experiences on any of these changes.
Feb 12, 2009 at 7:26 AM
The v1.7 release is now final.