file-based units of compiled code that compose .NET applications. An
assembly can be an executable or library, named with the extension
You are probably thinking, “Hey, this sounds eerily familiar!” And it should. However, .NET has put quite a spin on things as they were, most notably eliminating the heartache associated with DLL hell. Two new options are provided, both without the complexity of traditional DLLs.
Private assemblies are designed to be deployed with a single application and shared with no other applications. They do not require signing or version information. They also do not have to be registered with the system. You simply can reference assemblies by name. The runtime locates assemblies using a set of rules.
<dependentAssembly> elements are
loaded from the application configuration file. If the requested
assembly is listed, the assembly is loaded from the location
specified in the
href attribute of the
<codeBase> element. If this sounds a little
complicated, don’t worry about it.
It’s rare to have an assembly listed with this
method in practice, but for the sake of completeness, I had to
Generally, we let the runtime do its job and probe for the assembly. The runtime uses the parameters listed in Table 9-5 to probe for the assembly. These parameters are mixed, matched, concatenated, appended, etc., until the runtime finds the assembly.
Table 9-5. Parameters used to probe ...