Summary: Visual Studio has a new property for assembly references – Specific Version. When this property is set to True, Visual Studio 2005 will only build the client if it has access to the same version of the referenced assembly of when the reference was added; otherwise, it’ll result in a warning.
Details: By default, Visual Studio 2005 will not keep track of the referenced assembly version. For example, suppose you browse in Visual Studio 2005 and add a reference to version 184.108.40.206 of the assembly MyAssembly.dll. The reference properties will reflect the assembly version, but will not have any affinity to it. If you replace the referenced assembly on disk with version 220.127.116.11 (while keeping the same friendly name or even the strong name), next time you build the client, the client-side complier will use the metadata and type definitions from version 18.104.22.168 of the server assembly. The manifest of the client assembly will record 22.214.171.124 as the server assembly version number, and .NET will try to provide version 126.96.36.199 to the client, not version 188.8.131.52, which the client developer added a reference to. In dynamic build environments, this default behavior will allow the client developer to always 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 solution. Whether you change the referenced assemblies' version explicitly or let the complier 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, version 184.108.40.206. 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 220.127.116.11 of the framework, it will add its components to the GAC, but will also override the disk folder with the newer assemblies. Consequently, your application will not be able to use version 18.104.22.168 of the control, even though it makes specific use of that version. To address this need, Visual Studio 2005 provides the Specific Version property of the assembly reference. Specific Version is set by default to False for all references. When Specific Version is set to True, Visual Studio 2005 will only build the client if it has access to the specific version of the referenced assembly. Specific Version set to True will have an affect 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. If an assembly with a matching version was not found, but the assembly has a strong name, Visual Studio 2005 will also 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, it displays a warning icon on the reference in the References folder, expecting the developer to resolve it.
Note that the Specific Version property is only a build-time directive, and it has no effect on the runtime version resolution of the referenced assembly.