Chapter 5. Versioning

As discussed in Chapter 1, a component technology must provide some sort of version-control support, which ensures that client applications have a deterministic way of always interacting with a compatible version of a server component. The component-versioning challenges you face are closely related to the component-sharing mode you choose. Private components (components that reside in a location private to the application using them) are far less exposed to versioning issues, because each application comes bundled with its own private set of compatible componentsyou have to explicitly intervene to cause incompatibilities. Shared components, on the other hand, can cause a lot of versioning headaches because they are stored in a globally known location and are used by multiple applications. Nonetheless, a mature component technology must allow multiple applications to share server components. A mature component technology should also allow different client applications to use different versions of the server components. Placing DLLs in global locations such as the system directory, as done in the past, proved fatal in the end, resulting in the devil's choice of either stifling innovation or suffering DLL Hell. Not surprisingly, one of the major goals set for the .NET platform was to simplify component deployment and version control. This chapter starts by presenting the principles behind .NET version control and assembly sharing, then explains how you can provide custom versioning policies for cases in which the .NET default isn't adequate. The chapter ends by describing how you should deal with versioning of .NET itself.