GOTCHA 11 Public key reported by sn.exe is inconsistent


GOTCHA #11 Public key reported by sn.exe is inconsistent

The utility sn.exe creates a strong name to sign your code with a public/private key pair. When you specify the assembly identity as in Example 1-25, or when you define the binding redirect for assembly version forwarding in the configuration file, you need to specify the public key token of the assembly. If you have a strong name key (.snk) file for your assembly, use caution in extracting the public key token from it. The -t option of sn.exe gives you the public key token. However, I have seen a number of developers fall into a trap when extracting the public key token from the .snk file.

Let's look at an example. Suppose you use the .NET command prompt to execute sn.exe as shown in Example 1-26.

Example 1-26. Using the sn utility to create key and extract public key token
 >sn  -k mykey.snk Microsoft (R) .NET Framework Strong Name Utility Version 1.1.4322.573 Copyright (C) Microsoft Corporation 1998-2002. All  rights reserved. Key pair written to mykey.snk >sn -t mykey.snk Microsoft (R) .NET Framework Strong Name Utility Version 1.1.4322.573 Copyright (C) Microsoft Corporation 1998-2002. All  rights reserved. Public key token is 1cf34646172fcb74 >sn -p mykey.snk mykeypublic.snk Microsoft (R) .NET Framework Strong Name Utility Version 1.1.4322.573 Copyright (C) Microsoft Corporation 1998-2002. All  rights reserved. Public key written to mykeypublic.snk >sn -t mykeypublic.snk Microsoft (R) .NET Framework Strong Name Utility Version 1.1.4322.573 Copyright (C) Microsoft Corporation 1998-2002. All  rights reserved. Public key token is bab446454bf67c07 

In this example, you first run sn -k mykey.snk. This creates the strong-name file named mykey.snk that contains the public and private key pair. Then you run sn -t mykey.snk on the generated file. This command prints the public key token. Then you execute the command sn -p mykey.snk mykeypublic.snk to extract the public key from mykey.snk and save it in mykeypublic.snk. Finally, you run sn -t mykeypublic.snk on the public key file. Note that the tokens displayed are not the same! Which one should you use? Which one is correct?

When I ran into this problem, I scratched my head wondering why my binding redirect didn't work properly. Eventually, when I used ildasm.exe to view the manifest of the assembly that was linking to my assembly, I realized that the public key token was not the same as the one I had in the configuration file.

If you read through the documentation for sn -t, you'll find the statement:

Displays the token for the public key stored in infile. The contents of infile must be previously generated using -p.

So this was the problem: the first time I ran sn -t, it extracted the public key from a file that had not been generated using sn -p. The next time I executed sn -t, it targeted mykeypublic.snk, which had been created using sn -p. The first sn -t was incorrect; the second was right.

It would be nice if there were an error or warning when you use -t on an input file that wasn't generated using the -p option.

How does this differ in .NET 2.0 Beta 1? This problem has been fixed in .NET 2.0 Beta 1. When you run sn -t mykey.snk, you get the following error:

 Microsoft (R) .NET Framework Strong Name Utility  Version 2.0.40607.16 Copyright (C) Microsoft Corporation. All rights reserved. Failed to convert key to token -- Bad Version of provider. 

IN A NUTSHELL

Do not extract the public key token from a .snk file directly. Instead use the file generated from the -p option. Or better still, get it from the manifest of a binding assembly by viewing it in ildasm.exe.

SEE ALSO

Gotcha #10, "Type.GetType() may not locate all types."



    .NET Gotachas
    .NET Gotachas
    ISBN: N/A
    EAN: N/A
    Year: 2005
    Pages: 126

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net