Browse DevX
Sign up for e-mail newsletters from DevX


Managing Processes in .NET : Page 5

If you need to launch programs from within a .NET application, the Process class is the right tool. It not only allows you to start and stop a process, but it also provides detailed information about running processes.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

Wrapping Zip Functionalities
The .NET Framework doesn't include any class to compress files. A lot of third-party vendors sell well-designed classes that plug into the .NET Framework and extend it with various flavors of file compression functionality. A few programs are available under various license agreements to zip and unzip files and folders. One of these is gzip, a command line tool. Another one is WinZip. Unlike gzip, WinZip is a GUI program and doesn't lend itself very well for use as a background tool. From the WinZip Web site, though, you can download a couple of command line utilities—wzzip and wzunzip. The code snippet below briefly illustrates how to use these tools. (For more information, please refer to each tool's respective documentation.)

gzip source wzzip source target wzunzip ?vb source

The gzip utility creates a file with the same name as the source file plus a .gz extension. For example, if you try to zip sample.doc, the tool creates a file called sample.doc.gz. The wzzip utility compresses the source file and creates a new file with the specified name. Finally, the third command line lists the files contained in the specified zip file. Let's combine these command lines with the .NET process API to build a new class for zipping files.

Listing 3 shows the source code of the Gzip method on the Compressor class. It takes two strings—source and target—and creates a new file by zipping the source using the gzip utility. For the code to work, the gzip utility must be available in a publicly accessible directory. (For example, you can place gzip in the same directory as the sample program or the Windows directory.)

All instances of the Compressor class share the Gzip method. Calling the Compressor class to zip a file is easy:

Compressor.Gzip(source, target)

The gzip utility doesn't produce any significant output to capture. Because the utility always adds a .gz extension to the source file, I added some extra code to rename the compressed file to the specified name. The Run method encapsulates the logic needed to configure and invoke the Process class.

Listing 4 shows the source code of the Zip method. It uses the wzzip utility to create a familiar .zip file. Note that a .gz file is recognized and successfully handled by WinZip, but not by the default Windows XP extension for zip files. The Zip method is simply a wrapper around the Run method (Listing 3).

Figure 3: The original output of the wzunzip utility.

Compressor.Zip(source, target)

The Zip method compresses the source file using the zip algorithm and creates a new file (the target). If the source parameter references a folder, Compressor will zip all the contents (files and subfolders).

The ReadZip method demonstrates how useful capturing output can be. The ReadZip method invokes the wzunzip utility with the ?vb switch and lists all the files contained in the specified zip file. The method first captures the output and then parses it to build a DataTable object. Figure 3 shows the original output of the wzunzip utility.

The parsing code depends on the version of the utility you use and it could break if you use a new version of WinZip with a different output schema. This example diagram skips heading and trailing lines and it breaks each line in the listing into pieces using a regular expression to detect blank strings. Note that extracting the file name is a little tricky because a file name can contain blanks. For this reason, my utility retrieves the file name by position. Figure 4 shows the same output post-processed to a DataTable and bound to a DataGrid.

Figure 4: The output of the wzunzip utility parsed and transformed into a DataTable.
Microsoft designed the process API in the .NET Framework to make programming easier. For many system level tasks, the .NET Framework still heavily relies on the capabilities and the functions of the operating system and the Win32 API. The process API is no exception. However, the abstraction layer that the .NET Framework builds unifies all the various Win32 API functions (CreateProcess, ToolHelp, shell) into a single object-oriented API. I think that programming objects with the Process class is far easier than programming quirky functions with lots of pointers and parameters. Don't you agree?

regsvr32.exe /u zipfldr.dll

Dino Esposito is a mentor at Solid Quality Mentors where he manages the ASP.NET, workflow, and AJAX courseware. A speaker at many industry events including Microsoft TechEd, Basta, DevWeek, and DevConnections, Dino is the author of two volumes of Programming Microsoft ASP.NET 2.0 Applications, for Microsoft Press. You can find late breaking news at http://weblogs.asp.net/despos.
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date