DotNetZip for the .NET Compact Framework v3.5

  • Thread starter Thread starter Cheeso
  • Start date Start date
C

Cheeso

DotNetZip has just been revised - there is now a version of the
library built for .NET Compact Framework v3.5.

DotNetZip is an open source zip library for .NET. It allows your
applications to create, extract, edit, or examine zip files. It does
passwords, Unicode, ZIP64, streams.

It's all managed code, and it is packaged in binary form as a single
DLL. For the Compact Framework, it is about 70k in size. (The full-
sized DotNetZip library is about 200k, and includes the ability to
produce Self-extracting zip files).

Check it out.

http://www.codeplex.com/DotNetZip
 
Out of curiosity, why built for CF 3.5? CF 3.5 *has* compression support
built in. It would be far more useful if it were built for 2.0, which there
is still a significant install base and which *doesn't* have compression
support.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com
 
Out of curiosity, why built for CF 3.5?  CF 3.5 *has* compression support
built in.  It would be far more useful if it were built for 2.0, which there
is still a significant install base and which *doesn't* have compression
support.
Click to expand...

Hey Chris,
The relevant part that was added into .NET 3.5 CF is the
System.IO.Compression namespace.
These classes have support for GzipStream and DeflateStream, but as
far as I know, there is no support for managing zip files directly.

A zip file consists of a series of entries, each of which has a
header, followed by the file data. The header contains metadata -
filename, timestamp, file comment, and other things. The data is the
bytestream of the file after it has been run through a compressor -
like DeflateStream. The Zip format as specified by PKWare supports
other compression algorithms, but the Deflate algorithm, as described
in IETF's RFC 1951, "DEFLATE Compressed Data Format Specification
version 1.3.", is the most commonly used.

In the .NET CF 3.5, the compression libraries allow an app to produce
the compresed bytestream (the "data" from above), but there is no
support for handling the metadata, the header. The ZipFile class I
built, internally uses the System.IO.Compression.DeflateStream class,
and also handles the metadata. The result is that you can do stuff
like this:


using (var zip = ZipFile.Read("aaa.zip"))
{
foreach (ZipEntry e in zip)
{
e.Extract(....);
}
}

So to answer your question, why build it for 3.5? 3.5 is the first
CF to have the built-in Compression support.

This is the same library that runs on the (full) .NET Framework v2.0 -
because 2.0 is when Compression was added in the full Framework.
 
Sure, I'm just saying the utility would have been substantially higher if
you're targeted CF 2.0. Sure you'd have to implement the deflate algorithm,
but it's pretty simple and there are already desktop managed sources for the
algorithm.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com


Out of curiosity, why built for CF 3.5? CF 3.5 *has* compression support
built in. It would be far more useful if it were built for 2.0, which
there
is still a significant install base and which *doesn't* have compression
support.
Click to expand...

Hey Chris,
The relevant part that was added into .NET 3.5 CF is the
System.IO.Compression namespace.
These classes have support for GzipStream and DeflateStream, but as
far as I know, there is no support for managing zip files directly.

A zip file consists of a series of entries, each of which has a
header, followed by the file data. The header contains metadata -
filename, timestamp, file comment, and other things. The data is the
bytestream of the file after it has been run through a compressor -
like DeflateStream. The Zip format as specified by PKWare supports
other compression algorithms, but the Deflate algorithm, as described
in IETF's RFC 1951, "DEFLATE Compressed Data Format Specification
version 1.3.", is the most commonly used.

In the .NET CF 3.5, the compression libraries allow an app to produce
the compresed bytestream (the "data" from above), but there is no
support for handling the metadata, the header. The ZipFile class I
built, internally uses the System.IO.Compression.DeflateStream class,
and also handles the metadata. The result is that you can do stuff
like this:


using (var zip = ZipFile.Read("aaa.zip"))
{
foreach (ZipEntry e in zip)
{
e.Extract(....);
}
}

So to answer your question, why build it for 3.5? 3.5 is the first
CF to have the built-in Compression support.

This is the same library that runs on the (full) .NET Framework v2.0 -
because 2.0 is when Compression was added in the full Framework.
 
Sure, I'm just saying the utility would have been substantially higher if
you're targeted CF 2.0.  Sure you'd have to implement the deflate algorithm,
but it's pretty simple and there are already desktop managed sources for the
algorithm.
Click to expand...

Ah, I see what you are saying.
I hadn't even considered it. The Deflate algorithm is pretty simple?
And implementations are available? I didn't even look.
Do you think it would be worth it for CF2.0, now that 3.5 is out?

I was thinking I needed to rely on the DeflateStream that is built-in.
 
There are still a *lot* of CF 2.0 applications out there and a lot of people
targeting CF 2.0 for new development because you have a much larger install
base of 2.0 in existing devices than you do with 3.5.

Yes, Deflate is simple, well documented, and there are plenty of resources
on the web in C# and Java (as well as others).


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com


Sure, I'm just saying the utility would have been substantially higher if
you're targeted CF 2.0. Sure you'd have to implement the deflate
algorithm,
but it's pretty simple and there are already desktop managed sources for
the
algorithm.
Click to expand...

Ah, I see what you are saying.
I hadn't even considered it. The Deflate algorithm is pretty simple?
And implementations are available? I didn't even look.
Do you think it would be worth it for CF2.0, now that 3.5 is out?

I was thinking I needed to rely on the DeflateStream that is built-in.
 
There are still a *lot* of CF 2.0 applications out there and a lot of people
targeting CF 2.0 for new development because you have a much larger install
base of 2.0 in existing devices than you do with 3.5.

Yes, Deflate is simple, well documented, and there are plenty of resources
on the web in C# and Java (as well as others).
Click to expand...
Chris, thanks.
I grabbed the jzlib source that is BSD licensed. Converted it with
JLCA, and then modified it extensively.
jzlib is not a ZIP library - it is a Deflate/Zlib library. But I used
it to implement a DeflateStream class that works on .NET CF 2.0.
This DeflateStream is similar, but not identical, to the DeflateStream
from System.IO.Compression that was added in .NET CF 3.5.

Currently I have a prototype of the DotNetZip library working with
that .NETCF-2.0-friendly DeflateStream.

I need to do some testing, will keep you posted.
..NET CF is not my main area of development expertise; I don't have a
mature unit testing approach on .NET CF projects. Any suggestions for
me?
 
We do all of our unit testing with MSTEST under TFS (unfortunately not so
simple, even if you have TFS already up).


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com


There are still a *lot* of CF 2.0 applications out there and a lot of
people
targeting CF 2.0 for new development because you have a much larger
install
base of 2.0 in existing devices than you do with 3.5.

Yes, Deflate is simple, well documented, and there are plenty of resources
on the web in C# and Java (as well as others).
Click to expand...
Chris, thanks.
I grabbed the jzlib source that is BSD licensed. Converted it with
JLCA, and then modified it extensively.
jzlib is not a ZIP library - it is a Deflate/Zlib library. But I used
it to implement a DeflateStream class that works on .NET CF 2.0.
This DeflateStream is similar, but not identical, to the DeflateStream
from System.IO.Compression that was added in .NET CF 3.5.

Currently I have a prototype of the DotNetZip library working with
that .NETCF-2.0-friendly DeflateStream.

I need to do some testing, will keep you posted.
..NET CF is not my main area of development expertise; I don't have a
mature unit testing approach on .NET CF projects. Any suggestions for
me?
 
Ok, I've posted a new release of DotNetZip that includes a Compact
Framework version.
It is fully managed code.
It embeds its own DeflateStream, based on a managed zlib library. In
fact you can use just the zlib library if you like.

I also included an example CF app that uses the library to unzip zip
files on the device.

The pre-requisite is CF 2.0. It will also work with CF 3.5.

Get the v1.7 release at http://www.codeplex.com/DotNetZip
 
Since VS2008, MSTEST is built into VS for device support. You don't actually
need TFS, although it does work (with some patience I hear gtp, Chris). As
far as I am aware there are no other frameworks that allow testing directly
on the device, without work.

--
Simon Hart
Visual Developer - Device Application Development MVP
http://www.simonrhart.com

There are still a *lot* of CF 2.0 applications out there and a lot of
people
targeting CF 2.0 for new development because you have a much larger
install
base of 2.0 in existing devices than you do with 3.5.

Yes, Deflate is simple, well documented, and there are plenty of resources
on the web in C# and Java (as well as others).
Click to expand...
Chris, thanks.
I grabbed the jzlib source that is BSD licensed. Converted it with
JLCA, and then modified it extensively.
jzlib is not a ZIP library - it is a Deflate/Zlib library. But I used
it to implement a DeflateStream class that works on .NET CF 2.0.
This DeflateStream is similar, but not identical, to the DeflateStream
from System.IO.Compression that was added in .NET CF 3.5.

Currently I have a prototype of the DotNetZip library working with
that .NETCF-2.0-friendly DeflateStream.

I need to do some testing, will keep you posted.
..NET CF is not my main area of development expertise; I don't have a
mature unit testing approach on .NET CF projects. Any suggestions for
me?
 
Currently I have a prototype of theDotNetZiplibrary working with
that .NETCF-2.0-friendly DeflateStream.

I need to do some testing, will keep you posted.
Click to expand...

Update: DotNetZip is now working on .NET CF 2.0. Version 1.7.2.2 of
DotNetZip embeds a managed-code port of Zlib, which includes a
DeflateStream.

Get it at http://www.codeplex.com/DotNetZip/Release/ProjectReleases.aspx?ReleaseId=18985

For Smart Device development, you need to reference a single DLL in
your project in order to be able to read, extract and create zip files
on a smart device.

DotNetZip is free, open source.
 
Back
Top