What Is an Assembly?

I l @ ve RuBoard

The term Assembly refers to one or more files that make up a logical grouping in .NET. An assembly can be a single DLL or EXE as well as a collection of DLLs and/or EXEs. The notion of an assembly is more of a packaging for .NET components than anything else.

Before the days of .NET, code could reside within an EXE, DLL and, for those of you who remember, an overlay. By breaking compiled code up into smaller blocks, it was possible to reuse existing compiled code for other applications, and to share that code among various applications. This, of course, led to the dreaded DLL hell often referred to in various conversations and articles. DLL hell is basically the problem that arises when a new version of a DLL replaces an older version and, as a result, a client application suddenly quits working. The reason for the client's sudden sickness is not always apparent but, due to lack of versioning enforcement of DLLs, a client application was at the mercy of the DLL author.

With .NET assemblies, it is now possible to retain multiple versions of a particular assembly. A client application can choose to use the assembly it was compiled against or to use the latest and greatest version of the assembly. This dynamic binding is controlled by the applications configuration file, located in the same directory as the application. A brief discussion of this dynamic binding will be covered in the "Application Configuration File" in Chapter 5.2, "Signing and Versioning."

Assembly Contents

Each assembly contains a Manifest and the compiled code. A Manifest is a roster of additional files for a multifile assembly, as well as storing information about the assembly's version, strong name , and other information about the particular assembly. Using ILDASM , you can view the Manifest of any .NET assembly to see what the Manifest actually contains. Figure 5.1.1 shows the Manifest for the mscorlib.dll assembly.

Figure 5.1.1. Manifest for mscorlib.dll .

graphics/0501fig01.gif

.NET assemblies are fully self-describing ; that is, all information about the assembly's contents is accessible to the runtime and to other .NET clients . In the same way that a COM client could interrogate a COM server about the interfaces it supported, it is possible to query for all entities within an assembly. The last section of this chapter creates a lightweight assembly viewer.

Locating Assembly

The goal of .NET assemblies was to allow for easy client installation of components. It is possible to install an application by merely doing an XCOPY of the application to a directory on the client computer. No registering of components is required, no registry entries for COM. So how does the runtime locate an assembly? The .NET runtime will locate required assemblies using the following options:

  • Application path

  • Bin directory under the Application path

  • Assembly named directory under application path (for example C:\program files\ myapp\myassembly\myassembly.dll )

  • Global Assembly Cache (covered in Chapter 5.2)

A more detailed explanation of locating assemblies can be found in MSDN, including topics such as probing heuristics and so on.

For most applications, the use of private assemblies will suffice. A private assembly is an assembly that is only used by that particular application. Because no other application is even aware of the existence of the assembly, the assembly should reside within the application directory or a subdirectory of the application. Only if your company is developing a suite of applications that share common assemblies should you consider making use of the Global Assembly Cache.

I l @ ve RuBoard


C# and the .NET Framework. The C++ Perspective
C# and the .NET Framework
ISBN: 067232153X
EAN: 2147483647
Year: 2001
Pages: 204

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net