he Base Class Libraries were first introduced as a core component of the .NET Framework back in January 2002. The introduction of the BCL represented a huge step forward in simplicity and consistency of API design for application development. Through provision of a standard hierarchical design known as namespaces, the BCL removed many of the downsides but did not eliminate all of the need for leveraging unmanaged or third-party APIs.
The .NET Framework 1.0/1.1 provided a BCL set that can be segmented into three functionality groups: a managed group, a managed wrappers group, and a support services group. The managed group contains classes consisting mostly of managed code implementations that replace unmanaged APIs. A perfect example of this is ADO.NET found in System.Data. The second group consists of managed wrappers around code or services still implemented as unmanaged code. An example of this can be found in the System.EnterpriseServices namespace that exposes COM+ Services to managed classes. The final functionality group provides support services to facilitate interoperability between the managed and unmanaged APIs. Many of these classes can be found in System.Runtime.InteropServices.
Many of the enhancements to the Whidbey BCL set focus on the managed group of classes. Although the interoperability support provided by the BCL allows seamless use of unmanaged code, providing similar functionality as true managed classes improves the performance, general ease of use, and reduces the dependency on proper installation of the underlying unmanaged code being replaced.
| Fast Facts |
| Enhancements to the Base Class Library provide sought-after functionality missing from the .NET Framework 1.1, including simplified DPAPI-based encryption classes and significant increases in Console class functionality. |
The Whidbey BCL offers new classes as well as new features for existing BCL classes that greatly simplify a number of common tasks. Some of these new classes can be considered information classes, designed to facilitate information acquisition. Some BCL enhancements provide improved network support or network-oriented features. Other BCL enhancements offer completely new functionality, some of which I’ll describe below.
I can’t cover all the changes to the BCL in this short space; I will cover some of the more important or noticeable areas of improvements. My article discusses the alpha version of the Whidbey BCL, which will continue to evolve, improve, and change as Microsoft moves through the alpha and beta process.
New Classes
Many of the new Whidbey BCL classes provide functionality directly through the .NET Framework that were previously available to developers only through COM interoperability and/or third-party APIs, or functionality that could be obtained through substantially less convenient avenues.
Obtaining Drive Information
One new BCL enhancement, the DriveInfo class which you’ll find in the System.IO namespace, provides functionality similar to the FileInfo and DirectoryInfo classes already found in the System.IO namespace. DriveInfo provides methods and properties to query information about a current drive on the system or, through the shared GetDrives method, retrieves an array of DriveInfo objects representing all the logical drive names on a computer. Developers will typically use this class to determine available size, or total size, as shown in Figure 1, or to determine whether a drive is a hard disk, network share, or floppy drive. To retrieve information about the “C” drive, you could use code similar to the following:
Dim c As New DriveInfo("C") Console.WriteLine("Data for Drive C:") Console.WriteLine("Avail: {0} bytes", _ c.AvailableFreeSpace) Console.WriteLine("Total Free: {0} bytes", _ c.TotalFreeSpace) Console.WriteLine("Format: {0}", c.DriveFormat) Console.WriteLine("Type: {0}", c.DriveType) Console.WriteLine("Name: {0}", c.Name) Console.WriteLine("Size: {0}", c.TotalSize) Console.WriteLine("Label: {0}", c.VolumeLabel) |
Obtaining Configuration Details Enhancements to the BCL provide options for retrieving and updating configuration information from managed code. The Configuration class, found in the System.Configuration namespace, provides the ability to easily retrieve machine configuration information. Much of the System.Configuration namespace is contained in the System.dll assembly, but the Configuration class is contained within System.Web.dll. If you want to retrieve connection string information, in particular, from the new Tracing to the Console Timing Code Execution The Stopwatch class provides all of the intuitive features you expect to find. Call the Start method to instruct the class to begin counting from the current elapsed time value. Do not start an already running Stopwatch, as it has no impact. Call the Stop method to end the current time measurement recording or to establish an interval time and pause the Stopwatch. Do not stop an already stopped Stopwatch, as it has no impact. Call the Start method again to resume time measurement recording. Call the Reset method to clear the cumulative elapsed time. You can retrieve the elapsed time for a Stopwatch instance by checking the Elapsed, ElapsedTicks, or ElapsedMilliseconds properties. You can call ElapsedTicks to retrieve a raw indicator of elapsed units or use the Frequency field to determine the relationship between ticks and actual elapsed time in direct terms such as milliseconds. A tick is the smallest unit a Stopwatch measures. A Stopwatch tick is not the same as a System.Ticks value. A System.Ticks value represents a 100-nanosecond span. A Stopwatch tick represents a time interval equal to one second divided by the value of the Frequency field. For example, a high-frequency timer, such as that shown in Figure 3, has a Frequency value in the millions, providing sub-millisecond elapsed time resolution granularity. Support of the hardware and OS is required for the underlying timing mechanism to provide high-resolution. Check IsHighResolution to determine whether the Stopwatch supports high-resolution elapsed time intervals.
|
