Supplying an Assembly Version Number
In Visual Studio 2003, you had to manually write the various assembly-level attributes, including the version number. Visual Studio 2005 provides visual editing of all the attributes commonly found in the AssemblyInfo
file. Visual Studio 2005 will even auto-populate certain values such as company name and copyright statements based on the information found in the Registry as part of Windows activation process.
|Figure 3: Specify the assembly version in the Assembly Information dialog.|
To specify the version number using Visual Studio 2005, bring up the assembly properties and open the Application tab. Next click the Assembly Information button to display the Assembly Information dialog (see Figure 3
Under Assembly Version you'll find four text boxes that you can use to specify the assembly version. The Assembly Information dialog is merely a visual editor for the set of assembly attributes found in AssemblyInfo
. For example, the AssemblyVersion
and its value, corresponding to the settings in Figure 3
The Assembly Information dialog also lets you specify the file version number. The file version number has no bearing whatsoever on .NET versioning, and is simply available for your custom needs if you want to apply a proprietary semantic to it.
In Visual Studio 2003, you had no way to create strong name keys and you were forced to use a command line utility (SN.exe
). Microsoft simply assumed that creating strong names was a relatively infrequent
operation, done once per company, and it saw no need to have that functionality in Visual Studio. However, in practice, it turns out that developers often create new strong names, used for testing, learning and experimenting, branching, security, configuration management, and so on.
Visual Studio 2005 can both create the encryption keys for you and sign the assembly, all without leaving the visual environment. In the project properties, select the Signing pane (see Figure 4
). By checking the "Sign the assembly" checkbox, you instruct the compiler to sign the assembly with the key file specified.
The "Choose a strong name key file" combo box will allow you to either create a new key or to browse to an existing file. If you choose to create a new key, Visual Studio 2005 will launch the Create Strong Name Key dialog box shown in Figure 5
Strong name key files come in two flavors plain and password-protected. If you uncheck the "Protect my key file with a password" checkbox, Visual Studio 2005 will generate a file with the name specified and with the snk
(Strong Name Key) extension. However, keeping the key in such a raw format carries great liability: since the strong name uniquely identifies an assembly vendor, if the private key is compromised, any malicious party could produce components as if they came from that vendor. To reduce the risk, I strongly recommend always choosing to protect the key using a password. Visual Studio 2005 insists that the password specified has 6 characters or more. If you check the "Protect my key file with a password" checkbox, Visual Studio 2005 will generate a file with the name specified and with the pfx
(Personal Information Exchange) extension. The pfx
file is more secure because whenever another user tries to use the file, that user will be prompted
|Figure 5: Generating strong name key file.|
for the password. The other advantage of a pfx
file is that you can add it to a certificate container (see the sidebar Protecting Your Keys
If instead of creating a new key file you would like to browse for an existing key, Visual Studio 2005 will bring up a dialog letting you browse for either .snk
files. Once you have selected a file, Visual Studio 2005 will copy that file to the project folder. There is no way to share an existing file, and every project must have its own physical copy of the file.
In addition, unlike Visual studio 2003, Visual studio 2005 does not use attributes for storing the key file name. Instead, it persists that in the project settings.
Specific Reference Version
|Figure 6: Stipulating a specific version.|
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 188.8.131.52 of the assembly MyAssembly.dll
. The reference properties will reflect the assembly version (see Figure 6
) but will not have any affinity to it. If you replace the referenced assembly on disk with version 184.108.40.206 (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 220.127.116.11 of the server assembly. The manifest of the client assembly will record 18.104.22.168 as the server assembly version number, and .NET will try to provide version 22.214.171.124 to the client, not version 126.96.36.199, 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. 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 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, version 188.8.131.52. 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 184.108.40.206 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 220.127.116.11 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 effect whether the referenced assembly has a strong
|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.|
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.