oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button O'Reilly Book Excerpts: VB.NET Core Classes in a Nutshell

An Introduction to the .NET FCL, Part 3

Related Reading

VB.NET Core Classes in a Nutshell
By Budi Kurniawan, Ted Neward

In part three in this series of book excerpts on the .NET FCL from VB.NET Core Classes in a Nutshell, learn how to work with the .NET FCL.

Working with the .NET FCL

Despite its vast size, the .NET FCL is a manageable collection of classes and their methods. This is because, unlike more traditional development tools such as the Win32 API, the .NET FCL is a collection of types (classes, interfaces, delegates, events, structures, modules, and enumerations) and their members organized into namespaces. A namespace is simply a logical grouping of classes that can in turn contain other namespaces, so that a collection of namespaces forms an inverse hierarchical tree. Organization of types into namespaces helps to prevent collisions in the event that types are identically named.

Although the .NET system of namespaces does not have a single root, we can consider the System namespace at the top of the .NET FCL hierarchy. It includes a wide variety of basic system classes, including data types, exception types, and types defining the most important attributes.

Defining Accessible Namespaces

The types in a namespace, in turn, reside in an assembly, which is simply a logical unit of deployment. An assembly provides the Microsoft Intermediate Language (MSIL) code for its contents, which is packaged in a Windows portable executable (PE) file. An assembly also specifies security permissions for itself, maintains a list of the types that it defines and their scopes, and specifies rules for resolving references to external types.

The assemblies in which namespaces of the .NET FCL reside are Windows dynamic link libraries (.DLLs). Typically, a single assembly contains multiple namespaces. In addition, however, a single namespace can reside in multiple assemblies. The System namespace, for example, resides in both mscorlib.dll and system.dll.

TIP: You can use ILDASM, the Intermediate Language disassembler included with the .NET Framework SDK, to see which namespaces and types are available in a particular assembly or DLL.

Namespaces are made available to Visual Studio or to the Visual Basic compiler by identifying the assembly in which the namespace resides. When using Visual Studio as the development environment for your Visual Basic projects, this is done by using the References dialog, as follows:

  1. Select Project Add Reference from the main menu, or right-click on References in the Solution Explorer window and select Add Reference from the popup menu.

  2. When the Add Reference dialog appears, make sure the .NET tab is selected, as shown in Figure 1-1. (The tab should be selected by default.)

  3. Select one or more DLL whose types you'd like to reference, then click the Select button. The assemblies you've added should appear in the Selected Components data grid. (See Figure 1-2.) Repeat this step if necessary until each assembly whose types you wish to access is displayed in the Selected Components data grid in the lower portion of the dialog.

  4. Click the OK button to close the dialog.

Figure 1-1

Figure 1-1. The .NET tab of the Add Reference dialog

WARNING: The Add Reference dialog does not list the assemblies whose references have already been added to a Visual Studio .NET project. You can see which assemblies are currently referenced by a project by expanding the References tree in the Solution Explorer window.

Figure 1-2

Figure 1-2. Selecting assemblies whose namespaces and types will be referenced

When compiling using the VB.NET command-line compiler, assemblies are made available to the compiler by using the /r: (or /reference:) compiler switch. Commas are used to separate DLLs if multiple DLLs are referenced. For example, the following command might compile a standard Windows desktop application:

vbc MyWinApp.vb /t:winexe /r:system.dll,

TIP: You may have noticed that you don't need to specify the path to .NET DLLs in order to access them. This is because they are registered in the Global Assembly Cache (or GAC), a location in which the Common Language Runtime expects to find its shared libraries.

Pages: 1, 2, 3, 4, 5

Next Pagearrow