Assembly学习心得(1)（ＺＴ）
说明：
最近开始准备把学到的.NET知识重新整理一遍，眼过千遍不如手过一遍，
所以我准备记下我的学习心得，已备参考。
各位都是大虾了，如果有哪些错误或者不完整的地方，还请不吝指出。多谢了。
分为两部分： 首先是一些必须了解的概念； 然后是一个完整的例子来逐一说明
这些概念；
第一部分（概念）
托管模块（Managed Module）
托管模块是一个需要CLR才能执行的标准Windows可移植可执行（portable executable，简称PE）文件。
元数据（Metadata）
简单的讲，元数据就是一个数据表的集合，在这些表中，其中一些用于
描述托管模块中所定义的内容（比如所定义的类型和它们的成员），另外还有一些
用于描述托管模块中所引用的内容（比如被引用的类型和它们的成员）。
URL: ms-help://MS.MSDN
QTR.2004APR.1033/cpguide/html/cpconmetadataoverview.htm
程序集清单（Assembly Manifest）
程序集清单是另外一些元数据表的集合。这些表描述了组成程序集的文件，
程序集所有文件中实现的公有导出类型，以及一些程序集相关的资源文件或数据文件。
ms-help://
MS.MSDNQTR.2004APR.1033/cpguide/html/cpconAssemblyManifest.htm
1.程序集（Assembly）的概念：
首先：程序集是一个或多个托管模块，以及一些资源文件的逻辑组合。因为它是一个逻辑上的组合，所以程序集的逻辑表示和物理表示可以相互分离。如何将代码和资源划分到不同的文件中完全取决于我们。例如，我们可以将一些很少使用的类型或资源放在一个单独的Assembly Module中，然后根据需要（比如第一次用到的时候），从web上下载它们。如果没有用到，它们将不会被下载。这样既节省磁盘空间，也减少了安装时间。程序集允许我们将文件的部署分解开来，同时又将所有的文件看作一个单独的集合。
其次：因为CLR是直接和程序集打交道的，所以程序集也是组件复用，以及实施安全策略和版本策略的最小单元（安全策略，版本信息等都只能是加在程序集上）。
注意：程序集是一个逻辑组合，它可以包含很多个文件。大多数程序集（比如使用Visual Studio.NET创建的那些）一般都是单文件程序集，也就是只有一个.exe或者.dll文件（目前.NET的程序集只有这两种格式）。在这种情况下，程序集清单（manifest）直接嵌入到单文件程序集中。但是，你也可以用“程序集生成工具”（Al.exe）来创建多文件程序集。也可以只创建一个只包含清单的程序集。
2.强命名程序集（Strong Name Assembly）的概念
因为不同的公司可能会开发出有相同名字的程序集来，如果这些程序集都被复制到同一 个相同的目录下，最后一个安装的程序集将会代替前面的程序集。这就是著名的Windows “DLL Hell”出现的原因。
很明显，简单的用文件名来区分程序集是不够的，CLR需要支持某种机制来唯一的标识一个程序集。这就是所谓的强命名程序集。
一个强命名程序集包含四个唯一标志程序集的特性：文件名（没有扩展名），版本号，语言文化信息（如果有的话），公有秘钥。
这些信息存储在程序集的清单（manifest）中。清单包含了程序集的元数据，并嵌入在程序集的某个文件中。
下面的字符串标识了四个不同的程序集文件：
“MyType, Version=1.0.1.0,
Culture=neutral, PublicKeyToken=bf5779af662fc055”
“MyType, Version=1.0.1.0,
Culture=en-us, PublicKeyToken=bf5779af662fc055”
“MyType, Version=1.0.2.0,
Culture=neturl, PublicKeyToken=bf5779af662fc055”
“MyType, Version=1.0.2.0,
Culture=neutral, PublicKeyToken=dbe4120289f9fd8a”
如果一个公司想唯一的标识它的程序集，那么它必须首先获取一个公钥/私钥对，然后将共有秘钥和程序集相关联。不存在两个两个公司有同样的公钥/私钥对的情况，正是这种区分使得我们可以创建有着相同名称，版本和语言文化信息的程序集，而不引起任何冲突。
与强命名程序集对应的就是所谓的弱命名程序集。（其实就是普通的没有被强命名的程序集）。两种程序集在结构上是相同的。都使用相同的PE文件格式，PE表头，CLR表头，元数据，以及清单（manifest）。二者之间真正的区别在于：强命名程序集有一个发布者的公钥/私钥对签名，其中的公钥/私钥对唯一的标识了程序集的发布者。利用公钥/私钥对，我们可以对程序集进行唯一性识别、实施安全策略和版本控制策略，这种唯一标识程序集的能力使得应用程序在试图绑定一个强命名程序集时，CLR能够实施某些“已确知安全”的策略（比如只信任某个公司的程序集）。
3.如何创建强命名程序集（Strong Name Assembly）
创建一个强命名程序集首先需要获得一个用强命名实用工具
（Strong Name Utility，即SN.exe，.NET SDK自带）产生的密钥。
下面简要介绍一下SN.exe的一些用法。 要产生一个公钥/私钥对：
a)SN –k MyCompany.Keys
该命名告诉SN.exe创建一个名为MyCompany.keys的文件。MyCompany.keys文件将包含以对以二进制格式存储的公有密钥和私有密钥。
b)查看公有密钥：
首先生成一个只包含公有密钥的文件： SN –p
MyCompany.keys MyCompany.PublicKey
然后用-tp参数查看：SN –tp MyCompany.PublicKeys
Public key is
00240000048000009400000006020000002400005253413
10004000001000100bb7214723ffc13901343df4b9c464ebf
7ef4312b0ae4d31db04a99673e8163768cc0a2a7062e731d
beb83b869f0509bf8009e90db5c8728e840e782d2cf928dae
35c2578ec55f0d11665a30b37f8636c08789976d8ee9fe9a5
c4a0435f0821738e51d6bdd6e6711a5acb620018658cce93
df37d7e85f9a0104a5845053995ce8
Public key token is 2dc940d5439468c2
创建好了公钥/私钥对，创建强命名程序集就很容易了。只需要把System.Reflection.AssemblyKeyFileAttribute特性加入到源代码中就可以了：?[assembly:AssemblyKeyFile("MyCompany.keys")]
说明：公钥/私钥对文件的扩展名可以是任意的（也可以没有），因为编译的时候都是以元数据的格式读取的。
4.程序集的部署方式
一个程序集有两种部署方式：
a)私有方式
第二部分（例子）
下面是一个完整的例子来逐一说明上面所提到的概念，以加深理解。
整个例子包含7个文件（在主目录下）：
主目录为 …/Assembly ----源程序目录
…/Assembly/Bin ---- 编译结果输出的目录，也就是应用程序主目
录。
文件名
类型
说明
App.cs
Code源文件
主程序，包含程序入口，
属于namespace1
ClassA.cs
Code源文件
类型A，包含一个静态方法，
属于namespace1
ClassB.cs
Code源文件
类型B，包含一个静态方法，
属于namespace2
AssemblyInfo.cs
Code源文件
包含程序集签名信息，
版本信息等
App.Key
公钥/私钥对文件
用来给程序集签名，
生成强命名程序集
App.PublicKey
只包含共有密钥
只储存共有密钥，
用SN.exe来查看
App.exe.config
Xml格式配置文件
App.exe的应用程序配置文件
源代码
App.cs
namespace namespaceA {
public class App {
static void Main (string[] args) {
System.Console.WriteLine(ClassA.ShowMe());
System.Console.WriteLine(namespaceB.ClassB.ShowMe());
}
}
}
ClassA.cs
namespace namespaceA {
public class ClassA {
public static string ShowMe()
{
return "This is ClassA";
}
}
}
ClassB.cs
namespace namespaceB {
public class ClassB {
public static string ShowMe() {
return "This is ClassB";
}
}
}
AssemblyInfo.cs
////////////////////////////////////////////////////////////////////////////////
// Module: AssemblyInfo.cs
////////////////////////////////////////////////////////////////////////////////
using System.Reflection;
////////////////////////////////////////////////////////////////////////////////
// Set CompanyName, LegalCopyright, and LegalTrademarks
[assembly: AssemblyCompany("App Company")]
[assembly: AssemblyCopyright("Copyright (C) 2004 @ App Company")]
[assembly: AssemblyTrademark("App is a test only program")]
////////////////////////////////////////////////////////////////////////////////
// Set ProductName and ProductVersion
[assembly: AssemblyProduct("App Product")]
[assembly: AssemblyInformationalVersion("1.0.0.0")]
////////////////////////////////////////////////////////////////////////////////
// Set FileVersion and AssemblyVersion
[assembly: AssemblyFileVersion("1.0.0.0")]
[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyTitle("App type assembly")]
[assembly: AssemblyDescription("App Aassembly is a test only assembly")]
////////////////////////////////////////////////////////////////////////////////
// Set Culture
[assembly: AssemblyCulture("")]
[assembly: AssemblyDelaySign(false)]
[assembly: AssemblyKeyFile("App.key")]
[assembly: AssemblyKeyName("")]
App.key和App.PublicKey是二进制格式存储的，不能直接查看。后面例子中会用到
1. 把源代码编译为托管模块（Managed Module）
csc /out:bin/classA.module /t:module classA.cs
参数：
/out: 输出路径
/t: 输出格式。可以有四种，分别是：
library ---- DLL程序集
exe ---- 控制台可执行程序（也是程序集的一种）
winexe ---- Windows可执行程序（同样也是程序集的一种）
module ---- 托管模块（程序集的一部分）
说明： 托管模块的的扩展名可以是任意的（也可以没有），因为编译的时候都是以元数据的格式读取的。
2. 把源代码编译为程序集（Assembly）
l 把ClassB编译为一个单文件程序集
csc /out:bin/classB.dll /t:library classB.cs
l 把App.cs，ClassA.module和ClassB.dll编译为一个多文件程序集
csc /out:bin/App.exe /t:exe app.cs /addmodule:bin/classA.module /r:bin/classB.dll
参数：
/addmodule: 把托管模块添加到程序集中 /r: 添加引用说明： 上面生成的程序集因为没有经过公钥/私有签名，所以生成的是非强命名类型的程序集。 生成的程序集App.exe的清单中只包含对classA.module托管模块的说明，并不 包classA.module的元数据，所以App.exe和classA.moudle必须在同一目录中。App.exe在运行时，如果用到对classA.module中类型的引用，则会去classA.moudel文件进行查找，如果classA.moude文件不存在，则会引发System.IO.FileNotFoundException。如果App.exe不会用到class.module中的类型，则classA.module存不存在都不会对App.exe的执行产生任何影响（这就是上面提到的Assembly的好处之一，Assembly只是一个逻辑上的组合）。
App.exe还用到了对ClassB.dll的引用，因为classB.dll不是一个强命名类型，所以它只能进行私有部署，可以和App.exe放在一起，也可以放在主目录下的其他子目录下。（后面通过应用程序更改配置文件，可以重定向指classB.dll的引用）。
3. 更改应用程序配置文件（App.exe.config），重定向对classB.dll的引用。
现在App.exe，classA.moudle和classB.dll都在Bin目录下，app.exe在运行时会找到所有它需要的类型，所以运行正常。
如果把在Bin目录下新建一个目录，比如sub，并把classB.dll移动到sub目录下，再运行App.exe就会出错。同样会引发System.IO.FileNotFoundException错误，因为App.exe运行时需要的classB类型找不到。这时候就需要更改添加（如果没有）或更改应用程序配置文件，应用程序配置文件是一个xml格式的配置文件，和web.config文件的作用差不多，是配置应用程序运行时的行为的。
跟原来比是通俗多了
