Before I dive into the Xceed FileSystem (the heart of Xceed Zip for .NET), a quick tour of the object model is required. At the heart of the Xceed FileSystem are three abstract classes: the base FileSystemItem class and the two derived AbstractFile and AbstractFolder classes. They expose the basic operations we can do on files and folders, like copy, move, create, delete, read from or write to, browse contents, get or change attributes and dates. You're already familiar with all this, either using Windows Explorer, a third party shell explorer, or the good old command prompt.
Files and folders are not only found on disk drives, they can be located in memory, on an FTP or HTTP server, on your Windows CE device, in the isolated storage, in your favorite source control system, in an email as an attachment, name it. Sometimes, the device is smart enough to expose itself as a real drive. For example, ram drives are usually accessible through normal file paths. They acquire a drive letter and trick the OS in thinking they are a legitimate disk drive. Another good example is Daemon Tools, which lets you expose a CD ISO image located on your hard disk as if it was a CD drive. In both cases, normal IO APIs can access them with the proper file paths.
But most often, integration stops at the shell or application level. For example, ActiveSync will let you access files and folders on your Windows CE device through Windows Explorer, as if they were normal files and folders. But don't try using classes under System.IO to access them. It won't work. You have to revert to RAPI, and manage the bridge between "worlds" yourself.
Another example is the zip file support in Windows XP (and originally in Windows 98 with the Plus! pack). From Windows Explorer, it lets you see zip files as if they were folders. What is a folder? A "place" where files are stored. What is a zip file? A "place" where files are stored. Makes sense! Neet. But again, something like this won't work:
System.IO.Directory.GetFiles( @"d:\data.zip", "*.bmp" );
For classes under System.IO, "d:\data.zip" is an unknown binary file, it's not a folder. You need third party libraries to read from that zip file, using a proprietary API which makes sense only for zip files. And most often, those libraries will support files accessible with a path or streams. Beyond that, you'll need to code it yourself.
The Xceed FileSystem removes those barriers between devices, virtual file systems, remote data, etc. A file is a file. A folder is a folder. Who cares how it works underneath. Let's says I want to get image files located in a particular folder of a zip file located on an FTP server, and copy them into a project folder located in a VSS database located on a server accessible through a UNC path.
AbstractFile ftpFile = new FtpFile( "ftp.xceedsoft.com", @"\pub\resources.zip" );
AbstractFolder zipFolder = new ZippedFolder( ftpFile, @"\Images" );
AbstractFile vssIniFile = new DiskFile( @"\\Repository\WebDepot\srcsafe.ini" );
AbstractFolder vssFolder = new VssFolder( vssIniFile, @"$\Intro\Logos" );
foreach( AbstractFile imageFile in zipFolder.GetFiles( false, "*.bmp" ) )
{
imageFile.CopyTo( vssFolder, true );
}
An FtpFile is a file. A ZippedFolder is a folder. A DiskFile is a file. A VssFolder is a folder. Once you have the instances, working with them hides their implementation. You can copy files. You can browse folder contents.
Another example. We can read from files. We can write to files. Something like this makes perfect sense:
AbstractFile logFile = new DiskFile( @"d:\myapp.log" );
if( !logFile.Exists )
logFile.Create();
string line = string.Empty;
using( StreamWriter writer = new StreamWriter( logFile.OpenWrite( false ) ) )
{
while( ( line = Console.ReadLine() ).Length > 0 )
{
writer.WriteLine( line );
}
}
using( StreamReader reader = new StreamReader( logFile.OpenRead() ) )
{
while( ( line = reader.ReadLine() ) != null )
{
Console.WriteLine( line );
}
}
A file is a file, right? Then changing the first line with this should not surprise you:
AbstractFile zipFile = new DiskFile( @"d:\myappdata.zip" );
AbstractFile logFile = new ZippedFile( zipFile, @"\logs\today.log" );
It still works. A zip file named "myappdata.zip" is created in the "D:\" folder, and contains a file named "logs\today.log" which contains what you typed.
Xceed Zip for .NET comes with the following classes:
DiskFile and DiskFolder are your regular disk file and folder accessible with a file path (drive letter or UNC path). MemoryFile and MemoryFolder virtually let you create ram drives for your process. IsolatedFile and IsolatedFolder give you access to the user isolated storage (System.IO.IsolatedStorage). Finally, StreamFile is a special implementation of an AbstractFile that lets you expose any stream as if it was a file.
You wont find the FtpFile and FtpFolder classes (yet). Though they are "feature complete", they will be available in Xceed FTP for .NET 2.1 (hopefully this year, or early next year). As for VssFile and VssFolder they are incomplete academic implementations someone here did for a project. Because that's the fun part: nothing's sealed. AbstractFile and AbstractFolder are waiting for you to derive from them. As a matter of fact, MemoryFile and MemoryFolder were first exposed as a sample on how to derive from AbstractFile and AbstractFolder. But they are so usefull that they are now first class citizens. Do you have other ideas of file and folder implementations that should be available in the Xceed FileSystem?