Finished another chapter in my book, Input/Output, which deals with the following:
Implementing serialization and input/output functionality in a .NET Framework application
Access files and folders by using the File System classes.
- File class and FileInfo class
- Directory class and DirectoryInfo class
- DriveInfo class and DriveType enumeration
- FileSystemInfo class and FileSystemWatcher class
- Path class
- ErrorEventArgs class and ErrorEventHandler delegate
- RenamedEventArgs class and RenamedEventHandler delegate
Manage byte streams by using Stream classes.
Manage the .NET Framework application data by using Reader and Writer classes.
- StringReader class and StringWriter class
- TextReader class and TextWriter class
- StreamReader class and StreamWriter class
- BinaryReader class and BinaryWriter class
Compress or decompress stream information in a .NET Framework application and improve the security of application data by using isolated storage.
Nice things I learned from this is how to easily compress and decompress data.
More importantly, the reason it is so easily, is because of the important role Streams play in the Framework. Once you get your head around streams, it's easy to use various sorts of them to get things done.
Another best practice I picked up, is to stop writing application specific configuration data to .xml/.ini files, but store them in the IsolatedStorage, it's the new Registry! :)
Besides the basic fundamentals of working with streams and the nice features you basically get for free once you know how to work with them, there are also some helper classes to work with the filesystem.
If you got any questions on the articles, feel free to comment.
+32 (0)478 57.79.17
These summaries with links to your wiki are great! I'm also studying for 70-536 using the Microsoft Press book. When I need a different slant, I use C# 3.0 in a nutshell, which is awesome. Good luck to you and I'll keep watching and maybe even contribute, although you are doing a great job.
Unfortunately, the compression/decompression functionality in the DeflateStream/GZipStream classes has proved to be near useless.
Have you seen the resulting size of the compressed files? :)
Yeah, I've seen the result, they are useless if you compress byte per byte, indeed.
If I do ReadByte(), (byte)WriteByte() in a loop, the resulting file is *bigger* than the original, after trying it with 3 different files (small, medium, huge file)
However, when I read the entire file in a byte[] buffer, and compressed that, the resulting file was smaller, as it should be! :p
I'm guessing this has something to do with the fact that GZip/DeflateStream don't look forward, so there's no way to efficiently compress a single byte. But when given enough bytes, they start becoming more efficient.
I have no idea if these resulting files play well together with ZIP utilities though, when you start making up your own buffer sizes ;) But to store things in your own application, it could work.
However, you'll usually be compressing entire files anyway, which makes it a lot better to get a library which produces valid .zip files. Like SharpZipLib :)