SharpDevelop Community

Get your problems solved!
Welcome to SharpDevelop Community Sign in | Join | Help
in Search


A managed .NET compression library for ZIP, TAR, GZip, BZip2, ZLib.
  • New SharpZipLib release version 0.86.0 available

    John Reilly has run the SharpZipLib project single handedly for some time, and after a magnificent stint running the show, has handed the reins over to me. They'll be big boots to step into.

    My first release is out now. Version 0.86.0 (download here) features a number of crucial bugfixes, many submitted by forum members. I'm especially excited about the zero-byte ZipOutputStream bugfix because this has been like a sniper, causing havoc and we never knew where the problem was coming from.

    The CommitUpdate bugfixes were remarkable for the complexity of the issue and a great example of the energy of our members.

    Please see the release history for a full list.

    Main New features:

    • Multi-member GZip handling will be a popular addition, and was generously added by Geoff Hart.  This will just operate automatically, no code change required on your part.
    • AES encryption and decryption, which is how I got involved in the project originally. Note that AES decryption is not yet supported in ZipInputStream, but works if you use ZipFile with an input stream, so that shouldn't be an impediment. Decryption is automatic and Encryption requires setting AESKeySize to 128 or 256.

    Thanks to everyone who contributed. Much appreciated.

  • Help wanted

    I am unable to do much with the library any more.  If there are keen people out there then they are invited to take over maintenance.

  • The road to 1.0

    I think the path to #Zip 1.0 should be as short and simple as possible.  Tidy up the public interfaces/existing code and fix as many bugs as possible.  Maybe add a feature or two if they are small.  Getting rid of the current licensing is in there as well, although in thats not so big a deal in the short term.

    I think tidying things up is really the best thing to do at this point.

    Current state

    The library as it stands is a collection of code from various places that when combined arent cohesive/coherent as a whole.  Also the class interfaces are ok in some places and a bit rough in others.

    I have a strong urge to restructure things to iron out some of the wrinkles.  Probably the only way to do this effectively would be to create a new library or namespace in the existing library and go from there.  This was code relying on the existing interface is protected from any changes.


  • 0.85.4 has arrived

    0.85.4 hard on the heels of 0.85.3 includes a fix for encryption problems which turned up in the forums, one for the power of open source!

    Its best to get this out there asap.

    The help file has also been updated a bunch and is now being generated with Sandcastle Help File Builder.


  • 0.85.3 Maintenance release

    0.85.3 is available for download!

    Dont forget if you download the help file to unblock it in the file properties dialog using windows file explorer!

    Please bear with the samples code the projects are a bit messy!

  • New release imminent

    A new release 0.85.3 has been generated and will be made available in the next day or so!


    Once this has been done there will be a lull as other work takes precedence for a while. 

  • More fixes == 0.85.3

    In the short term there are more fixes coming mainly for Zip handling.

    This is likely to be called 0.85.3 because its already been mentioned as such in the forum.

    Hopefully this will happen in the next month or so.

  • Help file is now available

    The CHM file is there now

  • 0.85.2.... Almost

    There have been a few problems getting 0.85.2 out the door involving SMTP servers and failures therein which is frustrating.  The release has gone ahead despite this somewhat to my surprise I must confess.

    You will find the HTML help file is missing from the release currently.  It should turn up in a few days time hopefully.



  • Zip64 setting for entries

    When Zip64 was first introduced the default strategy was to usezip64 extensions if the size of the entry was known and required it, or the size was not known.  This was the safest way of handling large files it seemed as it wasn't possible to end up with an entry and all the data written only to discover at the end that the header was not usable for an entry that turned out to need Zip64.


    There were complaints however from people who found they couldn't open there archives with XP's build in compression as it could not handle Zip64.  The library was changed adding a setting which defaulted to not using Zip64.

    After spending a fair while trying to help someone recently with problems with large files only to discover that this was the cause I have decided to go back to the original strategy as the library will not (by default) occasionally blow up.  Its better to get a valid archive and sometimes not see it easily than to blow up!

    The setting is still there for now but the best method of getting optimal results is to set the size of the entry before it is added.  For streams that dont support seeking Zip64 is the best default strategy I think.

    The cleanest and best solution is to set the size for each entry that is added as there is no confusion then!

  • Upcoming 0.85.2 release!

    The library has had a fair bunch of bugs fixed of late and its time for a release.

    The way the release is done has been reworked (more to come on that) and will in this next release anyway include binaries for compact framework as well as the desktop.

    You can find a preview come beta at  in both source and binary.

    If you have a chance try them out.  All going well 0.85.2 will be out in a couple of weeks.

  • SharpZipLib where to from here?

    Let the blog begin. 

    Its my intention to blog about applications that use SharpZipLib, new features, the demo
    applications that ship, programming techniques used.

    Right now 0.85 has just been released which is good as it been a long time between drinks and this fixes a few bugs and adds a couple of handy things

    • Zip64 which allows very large archives to be created.
    • Modifying of an existing archive via the ZipFile class.

    The next step is to take a quick breath and decide were to go next.  In the very short term there are a couple of fixes ups, CF has been busted for a while with regard to encryption, and there is a nasty little bug in the compression code for low compression levels which really needs to be nailed down as well.

    Were is the project going?  Well that is something to think about.  I am seriously thinking of adding strong encryption to Zip files as this would be useful for me.  This would tie in with fixing encryption for the Compact Framework as well, so there is some synergy there perhaps.

    But the big picture is not clear to me.  Were should the library be headed? Or more accurately what do users want?  The library is currently a somewhat polygot collection of tools and one thing to do would be to tidy the API up so there is more consistency across the entire tool set.

    There are many directions that the library could be extended.

    Please make your views known.


Powered by Community Server (Commercial Edition), by Telligent Systems
Don't contact us via this ( email address.