Chapter 3 Shared Assemblies and Strongly Named Assemblies

As time marches on,MS developers and control developer modify their code:they fix bugs,patch security flaws,add features,and so on,whick contributes to the instability of windows

The CLR supports two kinds of assemblies:weakly named assemblies and strongly named assemblies.

Weakly named assemblies and strongly named assemblies structurally identical-taht is,they user the same portable executble file fomat,PE32(+)header,CLR header,metadata,manifest tables,and IL.
The real difference between weakly named and stongly named assemblies is that a strongly named assembly is signed with a publisher's public/private key pair that uniquely identifies the assembly's publicsher.the key paie allows the assembly to be uniquely identified,secured,and versioned,and it allows the assembly to be deployed andwhere on the user'smachine or even on the internet,this ability to uniquely identify an assembly allows the clR to enforce certain kenow-to-be-safe pilicies when an application tries to bind to astrongly name assemblies are and what plicies the CLR applies to them.

It is highly recommended that you strongly name all of your assemblies. In fact, it is likely that future versions of the CLR will require all assemblies to be strongly named, and the ability to create weakly named assemblies will be deprecated. Weakly named assemblies are a problem
because it is possible to have several different assemblies all with the same weak name. On the other hand, giving an assembly a strong name uniquely identifies that assembly. If the CLR can uniquely identify an assembly, it can apply more policies to it related to versioning or backward
compatibility. It is Microsoft’s plan to endow future versions of the CLR with these policies to make versioning simpler. In fact, just eliminating the ability to make weakly named assemblies makes understanding the CLR’s versioning policies simpler.

Obviously, differentiating assemblies simply by using a file name isn’t good enough. The CLR needs to support some mechanism that allows assemblies to be uniquely identified. This is what the term strongly named assembly refers to. 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. Since public keys are very large numbers, we frequently use a small hash value derived from a public key. This hash value is called a public key
token. The following assembly identity strings (sometimes called an assembly display name) identify four completely different assembly files:
"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.

In my workplace,wo don't useing this type frequent,so not understand clear