To demonstrate the installation and development processes, a simple application has been created that calls a method in an assembly. The main portion of this code is shown in Listing 6.5.
[STAThread] static void Main(string[] args) { FooLib.Foo f = new FooLib.Foo(); Console.WriteLine("Foo: {0} ", f.Version); } |
This application references an assembly also in the project that implements the Version property, as shown in Listing 6.6.
The code in Listings 6.5 and 6.6 will be used to illustrate how to fully sign the FooLib assembly and install it into the GAC. At that point, the version of the FooLib assembly will be changed and the new version of the FooLib assembly will be installed, demonstrating side-by-side installation and use of assemblies.
You can install code to the Global Assembly Cache with a few simple steps:
The Global Assembly Cache contains the following assemblies: foolib, Version=1.2.697.17891, Culture=neutral, PublicKeyToken=ba049f56c6309b78, Custom=null
When you install the assembly into the GAC and run the test program, you get this:
Foo: 1.2.697.17891
Now that the code is released, the developer is free to work on the next version. The developer continues to work with the public key file that was given to him. When the next version is ready to ship, you repeat the process of re-signing the assembly (with the new version), installing it in the GAC (at a customer's site), and unregistering the assembly from the skip verification list. Now when you list the contents of the GAC, you get the following output:
The Global Assembly Cache contains the following assemblies: FooLib, Version=1.2.697.17891, Culture=neutral, PublicKeyToken=ba049f56c6309b78, Custom=null FooLib, Version=1.3.697.17959, Culture=neutral, PublicKeyToken=ba049f56c6309b78, Custom=null
Now two different versions of the assembly are in the GAC. If you want to reproduce this scenario on your computer, you need to ensure that you have one version of FooTest.exe that is built against version 1.2 of FooLib and one version that is built against version 1.3. To simulate this situation, you need to build FooTest.exe first with version 1.2 and copy it to a 1.2 directory. From there, modify the FooLib assembly version number to be 1.3 and rebuild FooTest.exe. Now that you have version 1.3 of FooTest.exe, you need to copy it to a 1.3 directory. Copies have been made of the applications that called each of these assemblies in two separate directories, 1.2 and 1.3. When you run the version from the 1.2 directory, you get this:
Foo: 1.2.697.17891
When you run the version from the 1.3 directory, you get this:
Foo: 1.3.697.17959
Each application runs side-by-side in that each is retrieving a different version of the assembly. Both versions of the assembly are installed.
Now you can use the browser to look at the assemblies that are installed in the GAC. If you point your Explorer to %SystemRoot%Assembly, you see a list of assemblies that are in the GAC. Your screen should look something like Figure 6.3.
Selecting the properties by right-clicking on FooLib yields a Properties dialog box that looks like Figure 6.4.
From this figure, you are able to see not only general properties (on the General properties tab), but you also can see specific properties of your assembly. Figure 6.4 shows the Comments version information that is set using the assembly attribute, like this:
[assembly: AssemblyDescription("This is a library of Foo functions")]
From the version property page, you can see a number of other version-related properties. Table 6.1 shows the mapping between assembly attributes and these version properties. The IDE sets most of these attributes to “”, so you should take the time to fill in the appropriate values so that this information is available at runtime.
Assembly Attribute | Version Property |
---|---|
AssemblyCompany | Company Name |
AssemblyCopyright | Copyright |
AssemblyCulture | Language |
AssemblyDescription | Comments |
AssemblyProduct | Product Name |
AssemblyTitle | Description |
AssemblyTrademark | Legal Trademarks |
AssemblyVersion | Assembly Version |
n/a | The name of the DLL |
AssemblyVersion | File Version (same as Assembly Version) |
AssemblyInformationalVersion | Product Version (defaults to AssemblyVersion) |
Note
Both private assemblies and shared assemblies share some commonalties:
If the assembly has a strong name, it is verified and version checked. A strong name prevents most tampering and spoofing attempts from succeeding.
Publisher and machine policy files affect both private and shared assemblies.
For most cases, it is not required that a user have system administrative rights to deploy an application. This applies to both private and shared assemblies. To access configuration files, the user should have access to the system directory (%SystemRoot%).
18.221.222.47