Section 5.4. Visual Studio 2005 and Versioning

5.4. Visual Studio 2005 and Versioning

The shared assemblies in the GAC are readily available for any client application to use. However, using Visual Studio 2005, there is no easy way to extract the server metadata from a shared assembly in the GAC to compile a client application. To build a client assembly, the client project must be given access to the server metadata. That means that somewhere on the client machine (usually in the server project, if you develop both server and client) there must be a copy of the server assembly.

When you use Visual Studio 2005 to add a reference to a server assembly, Visual Studio 2005 copies the referenced server assembly to the client directory by default. This constitutes a private server assembly for the use of the client assembly. You can, of course, manually remove that private copy of the server assembly, but there is a better way: you can instruct Visual Studio 2005 to only use metadata from the server assembly, and not to copy the assembly to the client directory. This enables compilation on the one hand and loading the shared assembly from the GAC on the other. For example, suppose a client assembly wants to use the shared assembly MySharedAssembly. The file MySharedAssembly.dll is already installed in the GAC and is available in some other location. First, add a reference to MySharedAssembly.dll using the Add Reference dialog box. This copies the assembly locally to the client directory and adds an item called MySharedAssembly to the client's References folder in the Solution Explorer in Visual Studio 2005. Display the Properties window of the referenced MySharedAssembly assembly, and set the Copy Local property to False (see Figure 5-8); this prevents Visual Studio 2005 from generating a private local copy of the server assembly.

Figure 5-8. Referenced assembly properties

Now you can build the client without using a local copy of the server assembly (when you set Copy Local to False, Visual Studio 2005 actually removes the local copy and avoids copying it again). When you run the client, the assembly resolver will use the shared assembly in the GAC.

In Visual Studio 2005, when you use the Browse tab of the Add Reference dialog to add a reference to an assembly that's already in the GAC, the Copy Local property of the reference is automatically set to False. However, when you use the Projects tab to add a reference to an assembly in a different project in the solution, Copy Local is always set to True, even when a copy of the referenced assembly is present in the GAC.

5.4.1. Specific Reference Version

By default, Visual Studio 2005 does not keep track of the referenced assembly version. For example, suppose you browse in Visual Studio 2005 and add a reference to version 1.0.0.0 of the assembly MyAssembly.dll. The reference properties will reflect the assembly version (see Figure 5-8) but will not have any affinity to it. If you replace the referenced assembly on disk with version 2.0.0.0 (while keeping the same friendly name, or even the same strong name), the next time you build the client, the client-side compiler will use the metadata and type definitions from version 2.0.0.0 of the server assembly. The manifest of the client assembly will record 2.0.0.0 as the server assembly version number, and .NET will try to provide version 2.0.0.0 to the client, not version 1.0.0.0 (the version to which the client developer added a reference). In dynamic build environments, this default behavior will allow the client developer always to be synchronized with the latest server assembly version without doing anything special about it.

The default behavior works well in a client project that adds references to other projects in the same solutionwhether you change the referenced assemblies' version explicitly or let the compiler do it for you, you will always get the latest assemblies for your client debug sessions. However, you can easily run into situations where this behavior is not what you want. Imagine developing a client application against a specific version of a control (say, version 1.0.0.0). The control is part of a framework that adds its components to the GAC when it is installed. The framework also provides a folder on the disk for you to add references to. If you install version 2.0.0.0 of the framework, it will add its components to the GAC, but it will also override the disk folder with the newer assemblies. Consequently, your application will not be able to use version 1.0.0.0 of the control, even though it makes specific use of that version.

To address this problem, Visual Studio 2005 provides the Specific version property of the assembly reference. Specific version is set by default to False for all references. When it is set to True, Visual Studio 2005 will build the client only if it has access to the specifically referenced version of the assembly. Setting Specific version to True will have an effect whether the referenced assembly has a strong name or not.

If Copy Local is set to True and the version number does not match, Visual Studio 2005 will not copy the referenced assembly. When trying to build the client assembly, Visual Studio 2005 will look for an assembly with a matching version number, according to the search algorithm described in Chapter 2. If an assembly with a matching version is not found but the assembly has a strong name, Visual Studio 2005 will try to look up the specific assembly version in the GAC. In this respect, the GAC on the development or build machine is actually used as a development resource, hosting side-by-side versions of component frameworks. If Visual Studio 2005 cannot find the specific version of the assembly in the GAC, it will display a warning icon on the reference in the References folder and will expect the developer to resolve the problem.

The Specific version property is only a build-time directive. It has no effect on the runtime version resolution of the referenced assembly.