Assembly Packaging

One advantage of the ability to package multiple modules in a single physical file is performance improvement. When you create an application and deploy it using a multifile assembly, the .NET runtime needs to load only the required modules. This has the effect of reducing the working set of the application.

Assembly Deployment

The smallest unit of deployment in .NET is the assembly. As I mentioned previously, you can create a .netmodule with the /t:module switch, but you must include that module in an assembly if you wish to deploy it. In addition, although it's tempting to say that assemblies are a means of application deployment, this is not technically true. It's more accurate to view assemblies in .NET as a form of class deployment (much like a DLL in Win32), in which a single application can be made up of many assemblies.

Because assemblies are self-describing, the easiest method of deploying them is copying the assembly to the desired destination folder. Then when you attempt to run an application contained in the assembly, the manifest will instruct the .NET runtime as to the modules that are contained in the assembly. In addition, the assembly also contains references to any external assemblies that are needed by the application.

The most common means of deployment is though private assemblies-that is, assemblies that are copied to a folder and that are not shared. How do you specify a private assembly? This is the default and occurs automatically unless you explicitly make the assembly a shared assembly. Sharing assemblies takes a bit more work and is covered later in the section "Creating Shared Assemblies." -

Assembly Versioning

Another great advantage to using assemblies is built-in versioning-specifically, the end of "DLL hell." "DLL hell" refers to the situation in which one application overwrites a DLL needed by another application, usually with an earlier version of the same DLL, breaking the first application. Although the Win32 resource file format does allow for a versioning resource type, the operating system doesn't enforce any versioning rules so that dependant applications will continue to function. This is solely the responsibility of application programmers.

As a means of addressing this issue, the manifest includes versioning information for the assembly as well as a list of all referenced assemblies and the versioning information for those assemblies. Because of this architecture, the .NET runtime can ensure that versioning policies are upheld and applications will continue to function even when newer, incompatible versions of shared DLLs are installed on the system. Because versioning is one of the biggest benefits of assemblies, it's covered in depth, including several examples, in "Versioning Assemblies." -