Versioning and Deployment

Components and their clients are often installed at different times by different vendors. For example, a Visual Basic application might rely on a third-party grid control to display data. Runtime support for versioning is crucial in ensuring that an incompatible version of the grid control does not cause problems for the Visual Basic application.

In addition to this issue of compatibility, the deployment of applications written in previous versions of Visual Basic was problematic. Fortunately, .NET provides major improvements over the versioning and deployment offered by COM and the previous versions of Visual Basic.

Better Support for Versioning

Managing the version of components was challenging in previous versions of Visual Basic. The version number of the component could be set, but this version number was not used by the runtime. COM components are often referenced by their ProgID, but Visual Basic does not provide any support for appending the version number on the end of the ProgID.

For those of you who are unfamiliar with the term ProgID, it’s enough to know that ProgIDs are developer-friendly strings used to identify a component. For example, Word.Application describes Microsoft Word. ProgIDs can be fully qualified with the targeted version of the component - for example Word.Application.10 - but this is a limited capability and relies on both the application and whether the person using it chooses this optional addendum. As you’ll see in Chapter 8, a namespace is built on the basic elements of a ProgID, but provides a more robust naming system.

For many applications, .NET has removed the need to identify the version of each assembly in a central registry on a machine. However, some assemblies are installed once and used by multiple applications. .NET provides a Global Assembly Cache (GAC), which is used to store assemblies that are intended for use by multiple applications. The CLR provides versioning support for all components loaded in the GAC.

The CLR provides two features for assemblies installed within the GAC:

• Side-by-side versioning - Multiple versions of the same component can be simultaneously stored in the GAC.

• Automatic Quick Fix Engineering (QFE), also known as hotfix support - If a new version of a component, which is still compatible with the old version, is available in the GAC, the CLR will load the updated component. The version number, which is maintained by the developer who created the referenced assembly, drives this behavior.

The assembly’s manifest contains the version numbers of referenced assemblies. The CLR uses the assembly’s manifest at runtime to locate a compatible version of each referenced assembly. The version number of an assembly takes the following form:

 Major.Minor.Build.Revision

Changes to the major and minor version numbers of the assembly indicate that the assembly is no longer compatible with the previous versions. The CLR will not use versions of the assembly that have a different major or minor number unless it is explicitly told to do so. For example, if an assembly was originally compiled against a referenced assembly with a version number of 3.4.1.9, then the CLR will not load an assembly stored in the GAC unless it has a major and minor number of 3 and 4.

Incrementing the revision and build numbers indicates that the new version is still compatible with the previous version. If a new assembly that has an incremented revision or build number is loaded into the GAC, the CLR can still load this assembly for applications that were compiled referencing a previous version. Versioning is discussed in greater detail in Chapter 21.

Better Deployment

Applications written using previous versions of Visual Basic and COM were often complicated to deploy. Components referenced by the application needed to be installed and registered; and for Visual Basic components, the correct version of the Visual Basic runtime needed to be available. The Component Deployment tool helped in the creation of complex installation packages, but applications could be easily broken if the dependent components were inadvertently replaced by incompatible versions on the client’s computer during the installation of an unrelated product.

In .NET, most components do not need to be registered. When an external assembly is referenced, the application makes a decision between using a global copy (which must be in the GAC on the developer’s system) or copying a component locally. For most references, the external assemblies are referenced locally, which means they are carried in the application’s local directory structure. Using local copies of external assemblies enables the CLR to support the side-by-side execution of different versions of the same component. As noted earlier, to reference a globally registered assembly, that assembly must be located in the GAC. The GAC provides a versioning system that is robust enough to allow different versions of the same external assembly to exist side by side. For example, an application could use a newer version of ADO.NET without adversely affecting another application that relies on a previous version.

So long as the client has the .NET runtime installed (which only has to be done once), a .NET application can be distributed using a simple command like this:

  xcopy \\server\appDirectory "C:\Program Files\appDirectory" /E /O /I 

The preceding command would copy all of the files and subdirectories from \\ server\appDirectory to C:\Program Files\appDirectory and would transfer the file’s access control lists (ACLs).

Besides the capability to XCopy applications, Visual Studio provides a built-in tool for constructing simple .msi installations. New with Visual Studio 2005 is the idea of a ClickOnce deployment project. These deployment settings can be customized for your project solution, enabling you to integrate the deployment project with your application output.

ClickOnce deployment provides an entirely new method of deployment, referred to as smart client deployment. In the smart-client model, your application is placed on a central server from which the clients access the application files. Smart-client deployment builds on the XML Web Services architecture about which you are learning. It has the advantages of central application maintenance combined with a richer client interface and fewer server communication requirements, all of which you have become familiar with in Windows Forms applications. ClickOnce deployment is discussed in greater detail in Chapter 22.