Summary

Assemblies are the basic unit of deployment and versioning in .NET. You can write and install simple applications without knowing much about assemblies. More complex applications require an in-depth understanding of the structure of assemblies, the metadata they contain, and how assemblies are located and loaded by the CLR.

You have learned how the identity of an assembly is used to allow multiple versions of an assembly to be installed on a machine and run side by side. This chapter explained how an assembly is versioned, the process by which the CLR resolves an external assembly reference, and how you can modify this process through the use of configuration files.

You also learned about how an assembly stores information, such as version number, strong name, and culture, about any external assemblies that it references, and information checked at run time to ensure that the correct version of the assembly is referenced. You saw how you can use versioning policies to override this in the case of a buggy assembly. The assembly is the single biggest aid in reducing the errors that can occur due to DLL hell, and in helping with deployment.

You've also seen how to examine assemblies to discover the types they contain, and the members of those types. You can even invoke a method on a type using the capabilities of reflection.

The chapter also discussed the capability to load an assembly dynamically, based on a location that is derived at run time. This capability is useful for some special deployment scenarios, such as simple Internet deployment, but completely unavailable in others such as Windows RT. Understanding all these elements helps you understand how to structure an application, when and how to use shared assemblies, and the deployment implications of your choices for assemblies.

Simple applications are usually created with no strong names or shared assemblies, and all assemblies for the application are deployed to the application directory. Versioning issues are rare as long as class interfaces are consistent.

Complex applications may require shared assemblies to be placed in the GAC, which means that those assemblies must have strong names, and you must control your version numbers. You also need to understand your options for allowing an application to load a version of an assembly other than the one it would load by default, or for loading assemblies dynamically using an application-specific technique to determine the assembly's location.

The next chapter looks in more detail at how your application interacts with the operating system's built-in security requirements. It also takes a closer look at the new security models that default to fewer privileges at run time, and how you can interact with and adjust for that behavior.