The .NET Answer

Although they are incapable of reducing deployment problems to nothing, the mechanisms put into place by the .NET runtime significantly decrease the complexity of deployment operations. This section gives an overview of the different portions of .NET related to application deployment. From here, we will examine each one in depth and illustrate how they all come together to enable you to distribute the code that you have worked so hard to write.

Self-Describing Components

Components deployed in the .NET runtime do not rely on the registry any longer. Instead, they are said to be self-describing: Each component carries its own information around as baggage that uniquely describes itself, including its version number. Components do not rely on any other mechanism to indicate their identity, nor can any other system entity affect their functioning. In this way, components are said to be isolated within the .NET runtime. Changing component A should have absolutely no effect on component B.

Version Control

The .NET runtime also provides a gatekeeper that monitors and records version information for each component. This also provides the side benefit of allowing newer versions of components to be introduced without breaking other applications: Each application is inherently aware of the specific versions of components that it needs to run. When a component is encountered that does not match this reference, it is up to the developer how to handle this situation. These settings can be controlled universally per machine, or on a per-application or per-component basis.

The runtime also keeps track of the last known set of components (and their versions) that actually worked for a given application. This allows developers or administrators to roll back components to a point in time that everything was still working, and then work out the issues from there.

So, how does .NET do all of this? A discussion of component deployment with .NET starts with assemblies.