1.
Weakly Named Assembly vs Strong Named Assembly
Weakly named assemblies and strongly named assemblies are
structurally identical—that is, they use the same portable executable (PE) file
format, PE32(+) header, CLR header, metadata,
manifest
tables, and Intermediate Language (IL) .
The real
difference between weakly named and strongly
named assemblies is that a strongly named assembly is
signed with a publisher’s public/private key pair that uniquely identifies
the assembly’s publisher.
A strongly named assembly consists of
four attributes that uniquely identify the
assembly:
a file
name (without an extension),
a
version number,
a
culture identity, and
a
public key.
e.g
"MyTypes, Version=1.0.8123.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089"
"MyTypes, Version=1.0.8123.0, Culture="en-US",
PublicKeyToken=b77a5c561934e089"
"MyTypes, Version=2.0.1234.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089"
"MyTypes, Version=1.0.8123.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a"
The first string identifies an assembly file called MyTypes.exe or
MyTypes.dll (you can’t actually determine the file extension from an
assembly identity string). The company producing the
assembly
is creating version 1.0.8123.0 of this assembly, and nothing in the assembly is
sensitive to any one culture because Culture is set to neutral. Of course,
any company could produce a MyTypes.dll (or MyTypes.exe) assembly file that
is marked with a version number of 1.0.8123.0 and a neutral culture.
Microsoft chose to use
standard public/private key cryptographic
technologies instead of any other
unique identification technique such as GUIDs, URLs, or URNs.
2.
SN.exe (Strong Name)
SN –k
MyCompany.snk
This
line tells SN.exe to create a file called MyCompany.snk. This file will contain
the public and private key
numbers persisted in a binary format.
Public
key numbers are very big. If you want to, after creating the file that contains
the public and private key, you can use the SN.exe utility again to see the
actual public key. To do this,
you
must execute the SN.exe utility twice. First, you invoke SN.exe with the –p
switch to create a file that contains only the public key
(MyCompany.PublicKey):
SN
–p MyCompany.snk MyCompany.PublicKey
Then,
you invoke SN.exe, passing it the –tp switch and the file that contains just the
public key:
SN
–tp MyCompany.PublicKey
When
I execute this line, I get the following output:
Microsoft (R) .NET Framework Strong Name Utility Version
4.0.20928.1
Copyright (c) Microsoft Corporation. All rights reserved.
Public key is
00240000048000009400000006020000002400005253413100040000010001003f9d621b702111
850be453b92bd6a58c020eb7b804f75d67ab302047fc786ffa3797b669215afb4d814a6f294010
b233bac0b8c8098ba809855da256d964c0d07f16463d918d651a4846a62317328cac893626a550
69f21a125bc03193261176dd629eace6c90d36858de3fcb781bfc8b817936a567cad608ae672b6
1fb80eb0
Public key token is 3db32f38c8b42c9a
The
SN.exe utility doesn’t offer any way for you to display the private key.
The
size of public keys makes them difficult to work with. To make things easier for
the developer (and for end users too), public key tokens were created. A
public key token is a 64-bit
hash
of the public key. SN.exe’s –tp switch shows the public key token that
corresponds to the complete public key at the end of its output.
Now
that you know how to create a public/private key pair, creating a strongly
named assembly is simple. When you compile your assembly, you use
the /keyfile:<file> compiler
switch:
csc
/keyfile:MyCompany.snk Program.cs
When
the C# compiler sees this switch, the
compiler opens the specified file
(MyCompany.snk), signs the assembly with the private key, and
embeds the public key in the manifest. Note that you sign only the
assembly file that contains the manifest; the assembly’s other files can’t
be signed explicitly.
3.
Sign Assembly
Here’s what it means to sign a file: When you build a strongly
named assembly, the assembly’s FileDef manifest metadata table includes the
list of all the files that make up the assembly.
As
each file’s name is added to the manifest, the file’s
contents are hashed, and this hash value is stored along with the file’s
name in the FileDef table. You can override the
default hash algorithm used with
AL.exe’s /algid switch or apply the
assembly-level System.Reflection.AssemblyAlgorithmIdAttribute custom
attribute in one of the assembly’s source code files. By default, a SHA-1
algorithm is used, and this should be sufficient for almost all
applications.
After
the PE file containing the manifest is built, the PE file’s entire contents
(except for any Authenticode Signature, the assembly’s strong name data,
and the PE header checksum) are
hashed,
as shown in Figure below. The hash algorithm used here
is always SHA-1 and can’t be overridden. This hash value is signed with the
publisher’s private key, and the resulting RSA digital signature is stored
in a reserved section (not included in the hash) within the PE file. The
CLR header of the PE file is updated to reflect where the digital signature is
embedded within the file.
Note: Because public keys are such large
numbers, and a single assembly might reference many assemblies, a large
percentage of the resulting file’s total size would be occupied with
public key information. To conserve storage space, Microsoft hashes the
public key and takes the last 8 bytes of the hashed value. These reduced
public key values—known as public key
tokens—are what are actually stored
in an AssemblyRef table.
In general, developers and end users will see public key token values much
more frequently than full public key values.
Note,
however, that the CLR never uses public key tokens when making security or trust
decisions because it is possible that several public keys could hash to a
single public key token.
e.g
Assembly
-------------------------------------------------------
Token: 0x20000001
Name : JeffTypes
Public Key :
Hash Algorithm : 0x00008004
Version: 3.0.0.0
Major Version: 0x00000003
Minor Version: 0x00000000
Build Number: 0x00000000
Revision Number: 0x00000000
Locale: <null>
Flags : [none] (00000000)
"JeffTypes, Version=3.0.0.0, Culture=neutral,
PublicKeyToken=null"
AssemblyRef #1 (23000001)
-------------------------------------------------------
Token: 0x23000001
Public Key or Token: b7 7a 5c 56 19 34 e0 89
Name: mscorlib
Version: 4.0.0.0
Major Version: 0x00000004
Minor Version: 0x00000000
Build Number: 0x00000000
Revision Number: 0x00000000
Locale: <null>
HashValue Blob:
Flags: [none] (00000000)
"MSCorLib, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089"
4.
The Global Assembly Cache - GAC
If an assembly is to be accessed by multiple applications, the
assembly must be placed into a well-known directory, and the CLR must know
to look in this directory automatically when a
reference
to the assembly is detected. This well-known location is called
the global assembly cache (GAC), which
can usually be found in the following directory (assuming that Windows is
installed in the C:\Windows directory):
C:\Windows\Assembly
The GAC directory is structured: It contains many
subdirectories, and an algorithm is used to generate the names of these
subdirectories. You should never manually copy
assembly files into the GAC; instead, you should use tools to accomplish
this task. These tools know the GAC’s internal structure and how to
generate the proper subdirectory names.
While developing and testing, the most common tool
for installing a strongly named
assembly into the GAC
is GACUtil.exe.
5.
GACUtil.exe
switches
/i <assembly_path> [ /r
<...> ] [ /f ]
Installs an assembly to the global assembly cache.
/il <assembly_path_list_file> [
/r <...> ] [ /f ]
Installs one or more assemblies to the global assembly cache.
/u <assembly_display_name> [ /r
<...> ]
Uninstalls an assembly from the global assembly cache.
/ul <assembly_display_name_list_file>
[ /r <...> ]
Uninstalls one or more assemblies from the global assembly cache.
List the global assembly cache filtered by <assembly_name>
List the global assembly cache with all traced references.
/cdl
Deletes the contents of the download cache
/ldl
Lists the contents of the download cache
/r <reference_scheme>
<reference_id> <description>
Specifies a traced reference to install (/i, /il) or uninstall (/u,
/ul).
Note: By default, the GAC can be manipulated only by a
user belonging to the Windows Administrators group. GACUtil.exe
will fail to install or uninstall an assembly if the user invoking the
execution of the utility isn’t a member of this group.
Using GACUtil.exe’s /i
switch is very
convenient for developer testing. However, if
you use GACUtil.exe to deploy an assembly in a
production environment, it’s recommended that you use
GACUtil.exe’s /r switch in addition to specifying the /i or /u switch to install
or uninstall the assembly. The /r switch
integrates the assembly with the Windows install and uninstall engine.
Uasically, it tells the system which application requires the assembly and
then ties the application and the assembly together.
Important - Globally deploying assembly files
into the GAC is a form of registering the assembly, although the actual
Windows registry isn’t affected in any
way. Installing assemblies into the GAC breaks
the goal of simple application installation, backup, restore, moving, and
uninstall. So it is recommended that you avoid global deployment and use
private deployment whenever possible.
6. Strongly
Named Assemblies Are Tamper-Resistant (防篡改）
When a strongly named assembly is installed in the GAC, the system
ensures that the file containing the manifest hasn’t been tampered with.
This check occurs only once, at installationtime. In addition, to improve
performance, the CLR does not check if a strongly named assembly has been
tampered with if the assembly is fully trusted and is being loaded into a fully
trusted AppDomain. On the other hand, when a strongly named assembly is
loaded from a directory other than the GAC, the CLR verifies the assembly’s
manifest file to ensure that the file’s contents have not been tampered
with, causing an additional performance hit every time this file
is loaded.
7.
Delay Signing
For the C# compiler, you do this
by specifying the /delaysign compiler
switch. In Visual Studio, you display the
properties for your project, click the Signing tab, and then select
the Delay Sign Only check box. If you’re
using AL.exe, you can specify
the /delay[sign] command-line
switch.
8. Privately
Deploying Strongly Named Assemblies
In addition to deploying a strongly named assembly in the GAC or
privately, a strongly named assembly can be
deployed to some arbitrary directory that a small set of applications know
about.
When you install each application into its directory, also
install an XML configuration file, and
have the shared
assembly’s codeBase element
indicate the path of the shared assembly. Now
at runtime, the CLR will know to look in the strongly named assembly’s
directory for the shared assembly. For the record, this technique is rarely
used and is somewhat discouraged because no single application controls
when the assembly’s files should be uninstalled.
The configuration
file’s codeBase element
actually identifies a URL. This URL can refer to any directory on the
user’s machine or to a Web address. In the case of a Web address, the CLR
will
automatically download the file and store it in the user’s download cache (a
subdirectory under C:\Users\UserName\Local Settings\Application
Data\Assembly, where UserName is the name of the Windows user account
currently signed on). When referenced in the future, the CLR will compare
the timestamp of the downloaded file with the timestamp of the file at the
specified URL. If the timestamp of the file at the URL is newer, the CLR
will download the new version of the file and load it. If the previously
downloaded file is newer, the CLR will load this file and will not download
the file again (improving performance). An example of a configuration file
containing a codeBase element is shown later in this chapter.
9. How
the Runtime Resolves Type References
