114
The documentation for the command-line compiler states that the argument to the reference switch is an assembly. This is not quite accurate. The argument is the name of the module that contains the
assembly manifest for an assembly.
If more than one assembly needs to be referenced, you can list them all in the same reference
switch, separated by commas, like this: vbc MySource.vb reference:System.Drawing.dll,System.Windows.Forms.dll
The Visual Basic .NET command-line compiler automatically references two assemblies: mscorlib.dll, which contains most of the types found in the System namespace; and Microsoft.VisualBasic.dll,
which contains the types found in the Microsoft.VisualBasic namespace.
When youre working within the Visual Studio .NET IDE, external assemblies are referenced by doing the following:
1. In the Solution Explorer window, right-click on References, then click on Add Reference. The Add Reference dialog box appears, as shown in
Figur e 3- 1 .
2. Scroll down to find the desired assembly. 3. Double-click or highlight the assembly name, and press the Select button. The assembly
name appears in the Selected Components frame of the dialog box. 4. Select additional assemblies, or click OK.
Figure 3-1. The Add Reference dialog box
3.4.1 Global Assembly Cache GAC
By default, assemblies are not shared. When one assembly is dependent on another, the two assemblies are typically deployed into a single application directory. This makes it easy to install and
remove an application. To install an application, simply create the application directory and copy the files into it. To delete the application, just delete the application directory. The Windows Registry is not
used at all.
115
If an assembly must be shared among more than one program, either it can be copied into each appropriate application directory or it can be installed into the global assembly cache GAC. The GAC
is an area on disk typically, its the assembly subdirectory of the Windows directory that holds assemblies to be shared among all applications. All of the .NET Framework assemblies reside in the
GAC. See
Figur e 3- 2 for a partial view of the assemblies in a typical GAC. Placing an assembly into
the GAC should be avoided if possible: it makes application installation and removal more difficult. This is because the Windows Installer or gacutil.exe must be used to manipulate the GAC—you can
no longer simply copy or remove the application directory. Installing assemblies into the GAC is not covered in this book. For information, point your browser to
ht t p: m sdn.m icr osoft .com and
perform a search for Deploying Shared Components.
Figure 3-2. Partial view of a typical GAC
3.4.2 Comparison of Assemblies, Modules, and Namespaces
Its easy to confuse the three concepts of namespace, module, and assembly. Here is a recap: Namespace
A portion of a type name. Specifically, it is the portion that precedes the final period in a fully qualified type name.
Module A file that contains executable code .exe or .dll.
Assembly A set of one or more modules that are deployed as a unit. The assembly name is the same as
the name of the module that contains the assembly manifest, minus the filename extension. Depending on how things are named, it can seem like these three terms are interchangeable. For
example, System.Drawing.dll is the name of a module that is deployed as part of the .NET Framework.
116
As it happens, this module is part of a single-module assembly. Because assemblies are named after the module that contains the assembly manifest, the assembly is called System.Drawing. A compiler
will reference this assembly as System.Drawing.dll. Many but not all of the types in this assembly have a namespace of System.Drawing. Other types in the System.Drawing assembly have
namespaces of System.Drawing.Design, System.Drawing.Drawing2D, System.Drawing.Imaging, System.Drawing.Printing, and System.Drawing.Text. Note that even though the namespace, module,
and assembly are similarly named in this case, they are distinct concepts. Note in particular that importing a namespace and referencing an assembly are different operations with different purposes.
The statement:
Imports System.Drawing allows the developer to avoid typing the fully qualified names of the types in the System.Drawing
namespace. It does not reference the assembly in which those types are defined. To use the types, the System.Drawing assembly contained in the System.Drawing.dll module must be referenced as
described earlier in this section. The Imports
statement was introduced in Chapt er 2
. In other cases, namespace and assembly names dont correspond. One example is the System
namespace. Some types with this namespace are found in the mscorlib assembly, and others are found in the System assembly. In addition, each of those assemblies has types with other
namespaces. For example, the System assembly contains types with the Microsoft.VisualBasic namespace, even though most of the types with that namespace are found in the
Microsoft.VisualBasic assembly. The reason for this apparent inconsistency is actually quite sound. Namespaces group types according to functionality, while assemblies tend to group types according to
which types are most likely to be used together. This improves performance because it minimizes the number of assemblies that have to be loaded at runtime.
When thinking about namespaces, just remember that types can have any namespace at all, regardless of where theyre defined—the namespace is just part of the type name.
3.5 Application Domains
