Installing Shared Code

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.

Listing 6.5. FooTest an Application to Test a Class Foo That Resides in FooLib
[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.

Listing 6.6. Implementation of FooLib
[assembly: AssemblyDelaySign(true)]
[assembly: AssemblyKeyFile(@"....pubfoo.snk")]
[assembly: AssemblyVersion("1.2.*")]
. . .
public class Foo
{
    public Foo()
    {
    }
    public string Version
    {
        get
        {
            Assembly a = Assembly.GetAssembly(GetType());
            return a.GetName().Version.ToString();
        }
    }
}

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:

  • sn -R foolib.dll foo.snk— Here you are re-signing with the private key. This is not the public key file that was generated with sn -p. This is the original file that contains both the public and private key pair. Because this file is sensitive, you should perform this step in a guarded environment where it is unlikely that the file containing the public and private key pair would be compromised.

  • gacutil -i foolib.dll— You perform this step at install time to install the assembly into the GAC.

  • sn -Vx— This is an optional step that you can do on the development platform so that the development site does not have a security hole. This essentially turns on all strong name verification. As illustrated previously, you can unregister an assembly from the “skip verification” list in numerous ways.

  • gacutil -l FooLib— This verifies that the assembly is really in the GAC. After you install the assembly, 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
    

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.

Figure 6.3. Explorer GAC assembly listing.


Selecting the properties by right-clicking on FooLib yields a Properties dialog box that looks like Figure 6.4.

Figure 6.4. FooLib assembly properties.


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.

Table 6.1. Assembly Attribute to Version Property Mapping
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%).


..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.221.222.47