This project is read-only.

Silverlight support?

Apr 4, 2009 at 1:51 PM
Does silverlight support planned ?

Apr 15, 2009 at 8:22 PM
Edited Apr 15, 2009 at 8:30 PM
I have not planned to produce a silverlight-compatible version of the library. 
But I am open to input.  You could open a workitem with this request.

I don't know what it would take, in terms of engineering and testing effort.
Mar 28, 2010 at 1:35 PM

I've used DotNetZip in earlier projects but I'm finding myself more and more in situations where I need my libraries to support both .NET and Silverlight, so I would love to see this library supporting both platforms as well! I had a quick glance at the sources a while ago and think it might well be possible to port this to SL without to much troubles (although the devil may be in the details...). As a proof of concept, Mike Taulty published a quick hack on his own:

I'm wondering whether the planning status on a possible SL port has changed since this topic was started (and I could also contribute a little time to an SL port, btw).





Mar 28, 2010 at 10:15 PM

Hi Philipp,

I think the silverlight support is an interesting one, but it seems to me that an SL app doesn't need all the power of DotNetZip. It probably makes sense to limit the capabilities in some way.  I think a first step would be to do a requirements analysis.   Does SL need ZipFile?  ZipOutputStream?  ZipInputStream?   Does SL need to be able to produce Self extracting archives?  And so on.

On the other hand it may be simplest to just produce the build for SL and be done with it.

But I've never built aything for SL, so  I don't know what's involved, what the restrictions are, and so on.



Mar 29, 2010 at 7:16 PM


I agree that the "classic" SL apps may need limited functionality, but then there's the out-of-browser (OOB) scenario, which makes quite a strong case for SL. I'm already seeing projects being planned for SL in the first place instead of WPF, because SL brings enough to the table in order to run both on the desktop or in the browser. However, to me, it's not so much about the features of DNZ, but the clean API you are offering, and the effort you're putting into the project (major kudos to you here!).

OOB would benefit from most features of DNZ, but one would have to take into account that file access is still limited for security reasons. So from this point, working strictly with streams might indeed simplify things (one could still add local file access through extension methods, or built-in at a later point). What I would like to see is the following (not the least because I'm currently working on which will be released with a ZIP provider of some sorts):

  • Access to files and folders in a ZIP file either locally or downloaded from the server (browsing)
  • Adding/extracting files and directories (file access, the core library's functionality may be limited to reading/writing through streams).
  • Streaming to/from zip files


With regards to building the library in SL, there's just a few points that prevent the current sources from compiling:

- Serialization code in the custom exceptions
- Access to file attributes (quite a few in FileSelector, which I guess isn't a critical component)
- A few references to a given code page (IBM 437 if I remember correctly)

And that's about it I think - I got the ZLibStream project to compile in just a few minutes, which was encouraging. The first two points are minor ones, the third one might need to some more work in order to make sure the library works ok. On the other hand, the encoding issue may be limited to comments, not file contents. Accordingly, it *might* be possible to get a working SL implementation with a few hours work, given the layering of DNZ allows you to just leave out the parts that require local file access, either by conditional compilation or partial classes. On the other hand, if DNZ is indeed built for local file access with strong dependencies on File/FileInfo rather than streams (there's around 50 usages of the File class), some refactoring will be required for sure.



Mar 29, 2010 at 10:09 PM

Philipp, interesting.

As I said, SL is sort of a vague thing for me, I know what it is but not the core value proposition, or technical constraints. I would need guidance on that stuff from others in order to go forward.

The FileSelector part is entirely optional.   It can be replaced entirely by LINQ, and is really only interesting on .NET 2.0. 

The IBM437 code pages is required. This is the standard encoding for filenames and comments in a zip file.   Is SL not able to use System.Text.Encoding?  Why would that be a problem?  Is it because System.Text.Encoding relies on OS support for the code pages and there's no guarantee of that in an SL context?

If SL cannot do File IO, then I think you're right that a refactoring would be appropriate in order to segregate the File operations from Stream operations.  Partial classes would probably be the right way to go there.

I take it from your comments that the size of the library is not really an issue. In other words, no need to do a triage of function in order to trim size down to the bare minimum for SL.  The main issue is fitting DotNetZip into the SL "sandbox" (is that the right term?).  Is that right?


Mar 29, 2010 at 11:03 PM


Just a few brief remarks:

  • If we can skip FileSelector, this would already erase quite a big part of the non-compiling code.
  • Encoding might be indeed an issue: SL only support UTF-8 / Unicode in order to avoid cross platform issues. So if this is a crucial thing, one would have to write a custom encoding in order to support the IBM437 code page. However, I'm not that sure about the impact if we actually work with UTF-8 (crashes vs. glitches, impacts on files that are created by current tools (if it only affects ZIP files that have been created in the early 90s, I could perfectly live with such a limitation), etc. But you'll probably know better anyway - a quick Google search for ibm437 vs. utf-8 lead me back to comments from yourself :)
  • File access: SL does File IO, but there's a few limitations, mainly with regards to attributes and getting the UTC time stamps. I'd say that the vast majority of the file operations that are currently in your code should work without any problems.
  • Size: The library is so lean that I really wouldn't worry about any optimizations at all. Whether it's 30 or 22 KB doesn't really matter IMO.
  • Finally, regarding the guidance - as already mentioned, I'll gladly invest some time should you want me to :)


Mar 30, 2010 at 1:05 AM

I'm glad you think the library is lean, but it's 400k, not 30k !!

About the IBM437 thing. 

It's not a matter of zips created in the early 90's.  The zip spec calls for IBM437, so a zip file created today is likely to be encoded that way.

IBM437 is essentially a superset of ASCII.  From Wikipedia, the key differences are in the 128 to 255 range.  I think a SL zip implementation can use ASCII encoding for creating zips, and every other zip library will be able to read it, including Windows Explorer.  If there are Unicode characters, the SL zip library can use UTF-8, which is allowed by the spec but not as widely supported.  The problem comes the other way - if an app has used CP437 to write a zip file, and there are characters in the 128-255 range, then the extracted filenames will be different in the SL app.  This is probably a small enough edge case that it doesn't really matter. 

The other problem here is that there are apps and libraries that use none of the above for a code page.  WinRar uses the machine's code page, which will be different in Sao Paolo, Tokyo, and Shanghai.  None of these are allowed by the zip spec, but zip apps do it anyway.  An SL zip library wouldn't be able to read any of those non-compliant zip files. I don't think this is a big deal.  Basically, if you don't create a compliant zip, then you have yourself to blame. 

But, there would be a code cost, because DotNetZip as you may know, currently supports the use of arbitrary code pages to read a zip file. I'd have to pull that code out.  Not a huge problem, just another refactoring, and more use of partial classes.

I think the biggest problem or challenge is the testing.  I don't know how to run tests on the SL runtime; not sure if I can use MSTest for that.   as I said, I don't have experience doing SL development.


Mar 30, 2010 at 9:34 AM

Outch - what the hell did I look at? In this case, making it a bit leaner would definitely something an SL version would benefit from. But still, I'm not too worried - the binaries are being compressed before sent to the client, so...

Regarding IBM437, I guess we could just write a simple encoding that does the job for us. If I get to it today, I'll write a little wizard that does some code generation in order to create encoding classes for SL (sounds like a nice little project).

Testing is not a problem - you can unit test an SL class library without too many issues. I will have to look about MSTest integration myself though.

Mar 30, 2010 at 5:53 PM

Right.  Given the size of the library, I'd be inclined to look to strip extra function from a DotNetZip for Silverlight.  The file selector stuff is one thing to leave out.  The self-extracting archive capability is another.  It is about 200k of the library, approximately 50% of the total size.  

There are some other pieces that may be considered for exclusion.  Zip checking and fixing.  Maybe some other pieces.  There's a parallel deflate feature that I added recently, that could be removed for another 8k or so.  That's a nice feature, I'm not sure if it's important for SL.  It can speed up compression greatly, but not sure if that's important.   Even excluding all these pieces, the resulting library will still be 170k or so.  

An alternative to all that code surgery is to start over from nothing, and build a special implementation just for SL.  Rather than excluding things, including things.  I think this would giev a minimal zip library for SL, but it would be much more expensive to maintain, in terms of time.  How much smaller?  could be down to 50-70k, I don't know.   A different implementation could use the System.IO.Compression.DeflateStream class, which I guess is included in SL.  That would eliminate the contents of the entire Ionic.Zlib.dll, which is about 100k.  Getting you to ~60k.

What's the right way to go?  I don't know, I don't have a good sense of the importance of size versus capability.

I originally introduced the ZLIB classes because the System.IO.Compression lirbary doesn't perform well, in terms of compression.  It's not flexible and it can actually increase the size of a previously-compressed binary data stream.  People were complaining about DotNetZip's compression, so I added an independent zlib.  But is that important for SL?  Will SL be used mainly for de-compression, in which case, the compression performance doesn't matter as much?

I don't know.

Before I invest the time and effort in doing the SL thing, I'd wanna have more confidence that I'm doing the right thing.


Mar 31, 2010 at 10:25 AM


You obviously will have to make the decision about splitting vs. keeping everything under the hood yourself. I guess an important factor will be the maturity of the platform and the plans you have in terms of both new features and backward support. Assuming the library works stable, it might be an option to drop backwards compatibility for future development and fork the project (which also gives you the opportunity to use Linq and all the good stuff in .NET 3.5 and later). To me, however, this would be rather about having a clean platform to work with rather than saving a few kilobytes (given you can already save a lot using partial classes you just don't import in the SL project or conditional compilation).

Regarding importance, I think the library should provide a good API to browse and manipulate ZIP files both ways. Of course, read access might be prevalent, but that doesn't mean that developers won't need it the other way round. If you have created code that is superior to the things that are built into .NET / SL, it's probably a good thing to keep them. However, stuff like self-extraction isn't what I'd regard part of the core, so this might be optional (extension libraries are a great help here).

Last but not least the encoding support - I wrote a little class generator that conveniently tackles the issue:



Mar 31, 2010 at 5:21 PM

Philipp, thanks for all the feedback.  Also thanks for the encoding class stuff.  I will look into it.


Apr 4, 2010 at 1:23 PM


I created an independent SL port for myself in the mean time which should help me to already get rudimentary ZIP file support in VFS. I'll post back here if I run into any issues. The Release build of the library (including built-in ZLib) is 180 KB, btw. If you want the code in order to run a diff, just drop my a note @ my-first-name at (watch the spelling).



Apr 5, 2010 at 9:45 PM

Ahh, ok, thank you Philipp.


May 5, 2010 at 11:54 PM
Dino/philipp: I'm wondering how soon you'll be doing a port to SL, or philipp, if I could get a copy of yours if you think it is ready for prime time? Regards, Dave
May 6, 2010 at 5:54 PM

The SL port is not on "the schedule".  It's on the to-do list, but I've got no timeframe on it.

May 6, 2010 at 6:12 PM



May 6, 2010 at 11:42 PM


I have a port that seems to be working so far although I have stopped using the library due to a show stopper bug (in the regular library), so I haven't used in in a productive environment. If you want the sources, drop me a note through the contact form at

so I get your email address.



May 7, 2010 at 9:15 AM

What bug is that?


May 7, 2010 at 9:22 AM

It will only affect you if you need to save your zip file multiple times:

I added the workaround suggested in my work item to both my CLR version and the Silverlight port, but I'm not aware whether there's potential side effects.

Jul 3, 2010 at 3:46 AM


I have a very practical application for a small lightweight DeflateStream in Silverlight 3 and 4.

Essentially what we are doing is compressing object serialization graphs to make the payload transmitted between the Silverlight client and the WCF host on the server significantly smaller (compresses to between 3-8% of original payload).

As you know .NET offers some built in compression support but it doesn't follow the RFC standards nor is this compression class available in Silverlight. This is where the classes from DotNetZip, specifically the Zlib namespace, would be perfect as it offers a lightweight set of classes to achieve the above (only the compression and decompression of streams and byte arrays is needed).

As part of my evaluation of whether DotNetZip could work for the above scenario, I downloaded the source and looked at its structure and identified that only the ZLib namespace/assembly is what's needed. I proceeded to create both a Silverlight 3 and a Silverlight 4 project (Visual Studio 2010) and added the files from the Zlib project as *linked* files (thus avoiding copying and duplicating the source code). Much to my delight I found that it compiled perfectly (with the exception of having to comment out trace code for outputting debugging content to the console).

So, armed with both the .NET and the Silverlight assembly of the Ionic.Zlib.dll, I proceeded to plug it into our LOB application and it worked beautifully and performed better than SharpZipLib did. The following were beneficial to us:

  • Much smaller Silverlight assembly (than say SharpZipLib) resulting in smaller .XAP package to be downloaded to client browsers.
  • Rough metrics offered almost 10% performance improvement using DeflateStream (this improvement is of course relative to the payload and usage scenario).
  • Much simpler and better organised API.
  • It's strong named (unlike SharpZipLib's Silverlight assembly ??) allowing it to be used in strongly named projects.

We build some of our applications using the CSLA Framework from Rockford Lhotka ( and I'm aware of many other developers that would consider using DotNetZip over SharpLibZip due to the above benefits. This would however require that there is both a Silverlight 3 and Silverlight 4 version of the small Ionic.Zlib.dll assembly available in the downloads. Based on my very quick and easy adaptation above, I believe this to be "low hanging fruit ready to be picked".

Hopefully I've made a case for creating a Silverlight 3/4 assembly of the Zlib namespace and really hope this meets with your approval. If so, I would immediately switch over to DotNetZip (it's just that much better) and appeal to the CSLA community to consider the DotNetZip alternative.

Thanks for the hard work on this great project!


Aug 16, 2010 at 1:17 AM


I've tested the above under Silverlight 4 with great success and performance.

I'd be happy to make the changes myself, and check it in.

PS: Only the ZLib namespace/assembly bits are needed in Silverlight.

Aug 20, 2010 at 12:11 PM
Jaans. thanks for the work and the offer of help. I've added you as a developer on this project.
Aug 21, 2010 at 1:57 AM

That's great... thanks Cheeso

I haven't started in earnest yet, just got the bits from CodePlex TFS server in the mean time and started planning...

Quick question: Do you have plans to move the solution and projects to VS2010 (PS: You can still target .NET 3.5 SP1 if you want) ?

I only ask since VS2008 based projects limits me to being able to create Silverlight 3 class libraries only and thus I'm unable to use Silverlight 4. I could create a project for each version of Silverlight, and then for those who require a Silverlight 4 based DLL, they can use their VS2010 to build the VS2010 project specifically (it'll all link to the same .cs files anyway). But, if you are planning to move to VS2010 anyway, the point becomes a mute as VS2010 happily creates both SL3 and SL4 class libraries.

Thanks for the help!


Sep 21, 2010 at 6:45 PM


Can I get your SL4 version?

Sep 21, 2010 at 6:58 PM

don't have that thing anymore, sorry - i misplaced it somehow :/

From: snelldl []
Sent: Dienstag, 21. September 2010 19:46
Subject: Re: Silverlight support? [DotNetZip:52272]

From: snelldl


Can I get your SL4 version?

Read the full discussion online.

To add a post to this discussion, reply to this email (

To start a new discussion for this project, email

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at

Sep 22, 2010 at 1:43 AM

Hi Snelldl

I'm waiting on Cheeso to release the update binaries that should include the SL3 assembly and also waiting for him to upgrade the project to VS2010 so I can add the SL4 version of the assembly.

However, you should be able to use the Silverlight 3 DLL just fine in SL4. If you are having difficulty in getting an assembly built from the project source, send me your email in a codeplex message and I'll reply with the SL3 DLL.

Note: Cheeso keeps the strong naming key file with him, so you'll have to either remove it from the project or substitute your own (as I have) - until he comes round to getting it updated and released.


Hardcodet: What's up with your message?

Sep 23, 2010 at 12:31 PM

I know this is a pretty old message, but I thought I would respond materially to some of the comments.

Jaans wrote:


As you know .NET offers some built in compression support but it doesn't follow the RFC standards ...

I am not aware that the .net built in compression violates any RFC standards. Maybe you mean that .net doesn't provide a Zlib library. But for the scenario you describe, compression of a wcf message, that shouldn't be a problem. But I am only guessing at your meaning. If you could be more specific about the RFC in question, I may be able to comment in more detail.

...nor is this compression class available in Silverlight.

ah, well that's a more clearcut issue!

Thanks for the hard work on this great project!


Glad you like it, thanks for the compliments.

Sep 23, 2010 at 12:46 PM
Jaans wrote:

Hi Snelldl

I'm waiting on Cheeso to release the update binaries that should include the SL3 assembly and also waiting for him to upgrade the project to VS2010 so I can add the SL4 version of the assembly.

there are some challenges here! First, I no longer have a working computer, or an Internet connection for the last few months. The replies I post here are made mostly from a friend's iPhone, typing on that tiny virtual keyboard with my fat thumbs. Also, I don't have VS2010, so even if I got a computer, I wouldn't be able to produce an SL4 version of the library (assuming VS2010 is required to produce SL4 version). But I'm working on solving those problems.

Note: Cheeso keeps the strong naming key file with him, so you'll have to either remove it from the project or substitute your own (as I have) - until he comes round to getting it updated and released.

You'll have to remove the strong-name and substitute your own key, because I have no plan to release my key. I believe my strong-name key is equivalent to my signature, and I won't grant anyone else the rights to sign things with my signature.

Dec 21, 2010 at 3:49 PM

Hello all,

I saw from the previous discussion between Cheeso and Jaans that a Silverlight 4 version of DotNetZip was in preparation.

In my project, I currently use SharpZipLib for archiving files that must be transmitted to the server. According to all reviews DotNetZip could be a better choice in term of size and performance.

What is the actual status of the SL4 port?


Dec 21, 2010 at 3:58 PM


I ended up buying the Xceed Silverlight Zip control which works very well.

Dec 22, 2010 at 12:45 AM

If what you are after is only the ZLib based compression library, without all the fluff of packaging, etc. then let me know:

Jaans wrote:

However, you should be able to use the Silverlight 3 DLL just fine in SL4. If you are having difficulty in getting an assembly built from the project source, send me your email in a codeplex message and I'll reply with the SL3 DLL.


Jan 28, 2011 at 6:21 PM

I'm also interested in silverlight support.  I do not need support for creating self-extracting archives.  I read the earlier msgs in thread and it seems like it is at one point (and still?) it (is/was?) pretty close...  I'd be interested in testing and possible helping with parts of it.  Been programming for 20+ yrs but new to .NET...


Apr 1, 2011 at 10:47 PM

I am using the version Mike Taulty created on his blog.  All of the functionality I needed worked fine and it builds to 150kb total for the zlib.dll and dotnetzip.dll.  I am able to read the contents of the zip file with LINQ and stream the contents of one of the files in the zip into a string.  Works for me in SL4.  It would be nice to have this available for others to use as perhaps an "alpha" version with caveats.  That way others wouldn't have to hunt down this thread to find it... and perhaps having a starting point would attract people to fix the problems as they are encountered? 


Nov 9, 2012 at 12:56 AM

Latest version of DotNetZip library also supports Silverlight (so ignore older download from Mike Taulty's blog): " - a binary release, that includes the the Silverlight version of the signed DLLs, and the Licenses."

the DevKit download there (the default) also contains Silverlight 3.0+ binaries with following readme:

"Ionic.Zip Silverlight v1.9 packed Sat-08-06-2011-215945.06. This is the Ionic.Zip library packaged for Silverlight 3.0 or later.  Use this library if you want to manipulate ZIP files from within Silverlight applications."

but the Silverlight libs are also available as separate download

Nov 25, 2012 at 7:15 PM
Edited Nov 25, 2012 at 7:16 PM

Seems the Silverlight build in 1.9 official download doesn't work since it tries to use IBM437 Encoding which is missing from Silverlight. A patched version (for version) that uses Unicode instead is available at