|only for RuBoard|
When you have an instance of a class, you are said to have an object . A collection of object definitions comprises a component . For instance, msado15.dll is a COM component that contains the Connection , Command , and Recordset objects (among others) found in ADO. In .NET, the concept of an assembly is roughly analogous to that of a component, but you can think of it as more of a "super component."
In addition to your program's code, assemblies contain a manifest , which is a block of metadata that describes everything in the assembly and how it relates to everything else. As shown in Figure 2-3, it contains references to other assemblies that the current assembly might need, as well as a description of the types contained within the assembly. These references make the assembly self-describing , alleviating the need for type libraries and IDL files. In Visual Basic, assemblies can be a single executable with a Sub Main entry point or a class library in a DLL.
Assemblies can also contain nonexecutable files of any type, similar to a resource file in a traditional Windows executable. The difference is that these additional files do not have to exist as binary information that is part of the executable. Every file that comprises an assembly can retain its individual identity within the filesystem. However, as far as the runtime is concerned , they are a single, cohesive unit. Multimodule assemblies, which contain resources in addition to code, are built using the Assembly Linker utility ( al.exe ) that is part of the .NET Framework SDK. The VB compiler only emits single module assemblies containing code.
Assemblies are the fundamental units in which code is deployed, version information is specified, and security permissions are defined. An assembly also represents a boundary for the identity of a type. If two different assemblies contain the same type definition, the runtime considers each a different type. This happens irrespective of the namespace the two types are defined within. Remember that namespaces are just mechanisms for organizing type information; the CLR resolves type names through namespaces.
hello-client.exe and hello.dll are two distinct assemblies. They can be deployed and versioned independently of each other, and each can maintain a different level of security. Instead of compiling hello.vb to a DLL, you can compile it into a module as follows :
C:\>vbc /t:module hello.vb
This compilation produces a file named hello.netmodule .
A module is similar to an assembly, but it is nonexecutable and does not have any of the attributes associated with an executable. It does not maintain a version, for instance. You can recompile the hello client and link the module by using the /addmodule compiler option:
C:\>vbc /addmodule:hello.netmodule hello-client.vb
One advantage to using modules is that they are compiled and can be distributed in place of source code.
|only for RuBoard|