form the fundamental unit of deployment, version control, reuse,
activation scoping, and security permissions for a .NET-based
application. Assemblies take the form of an executable (.exe) file or
dynamic link library (.dll) file, and are the building blocks of the
.NET Framework. They provide the common language runtime with the
information it needs to be aware of type implementations. You can think
of an assembly as a collection of types and resources that form a
logical unit of functionality and are built to work together.
Visual Basic .NET, you use the contents of assemblies, and add
references to them, in much the same way as you use type libraries with
previous versions of Visual Basic. What makes assemblies different from
.exe or .dll files in earlier versions of Windows, however, is that they
contain all the information you would find in a type library, plus
information about everything else necessary to use the application or
Within every assembly is an assembly manifest. Similar to a table of contents, the assembly manifest contains the following:
- The assembly's identity (its name and version).
file table describing all the other files that make up the assembly,
including, for example, any other assemblies you created that your .exe
or .dll file relies on, or even bitmap or Readme files.
- An assembly reference list,
which is a list of all external dependencies - .dlls or other files
your application needs that may have been created by someone else.
Assembly references contain references to both global and private
objects. Global objects reside in the global assembly cache, an area
available to other applications, somewhat like the System32 directory.
The Microsoft.VisualBasic namespace is an example of an assembly
in the global assembly cache. Private objects must be in a directory at
either the same level as or below the directory in which your
application is installed.
assemblies contain information about content, versioning, and
dependencies, the applications you create with Visual Basic .NET do not
rely on registry values to function properly. Assemblies reduce DLL
conflicts and make your applications more reliable and easier to deploy.
In many cases, you can install a .NET-based application simply by
copying its files to the target computer.
To use an assembly, you must add a reference to it, as described in Adding and Removing References. Next, you use the Imports statement to choose the namespace of the items you want to use, as described in References and the Imports Statement.
Once an assembly is referenced and imported, all the accessible
classes, properties, methods, and other members of its namespaces are
available to your application as if their code were part of your source
file. A single assembly can contain multiple namespaces, and each
namespace can contain a different grouping of items, including other
For information on creating assemblies, see Creating and Using Assemblies.
Creating and Using Assemblies
assembly is one or more .exe or .dll files that make up a Visual Studio
.NET-based application. Assemblies are created automatically when you
compile Visual Studio .NET source files.
To create an assembly
- Compile your application by choosing Build from the Build
menu, or by building it from the command line using the command line
compiler. For details about building assemblies from the command line,
see Building From the Command Line.
To add a reference to another assembly
To use objects in another assembly
Specify the fully qualified name for the object, or use an alias that has been defined for the object using an Imports
statement. For details about fully qualified names, see Namespaces
. For details about adding references and using the Imports
statement, see References and the Imports Statement