s2.1.NET Framework部署目标
DLL hell：安装一个心应用程序时候，它可能莫名其妙地破坏了另一个已经安装好的应用程序。这个问题就叫做"DLL hell"。
.NET Framework 正在尝试彻底解决DLL hell的问题。另外，.NET Framework还在很大程度上解决了应用程序状态在用户硬盘上四处分布的问题。例如：和COM不同的是类型不再需要注册表设置。但还是需要建立快捷方式。
code access security代码访问安全性：.NET Framework包含的一个安全模型。
2.2将类型集成到模块中
csc.exe /out:Program.exe /t:exe /r:MSCorLib.dll Program.cs
这个命令行指示c#编译器生成一个名为Program.exe的课执行文件（/out:Program.exe）。生成的文件属于Win32控制台应用程序类型（/t[arget]:exe）。
MSCorLib.dll 是一个比较特殊的文件，因为它包含了所有核心类型：Byte,Char,String,Int32等，事实上，由于这些类型被使用得日此频繁，以至于c#编译器会自动引用MSCorLib.dll程序集。换言之，命令行其实可以如下简化（省略了/r开关）：
csc.exe /out:Program.exe /t:exe Program.cs
在此 由于/out:Program.exe和/t:exe命令行开关是c#编译器的默认设定，所以命令行可以继续如下简化成下面这个样子：
csc.exe Program.cs
不使用c#编译器自动引用MSCorLib.dll程序集，使用开关/nostdlib
csc.exe /out:Program.exe /t:exe /nostdlib Programe.cs
但是肯定会报错，因为System.Console类型是在MSCorLib.dll中
/t:exe 生成的是具有控制台用户界面（CUI）的应用程序
/t:winexe 生成的是具有图形用户界面（GUI）的应用程序
应答文件（response file）
response file 其实就是将上面的命令写入一个rsp格式的文件中，在使用的时候直接调用如下
例子：
我们将如下命令写入MyProject.rsp文件中：
/out:MyProject.exe
/target:winexe
使用上面文件里面的设置我们可以这么执行里面的内容
csc.exe @MyProject.rsp CodeFile1.cs CodeFile2.cs
上门的例子里面就同时编译了CodeFile1.cs 和 CodeFile2.cs两个文件。
2.3元数据概述
一个托管的PE文件由四个部分构成：PE32(+)头、CLR头、元数据以及中间语言（IL）
PE32（+）头是Windows期望的标准信息。
CLR头是一个小的信息块，它要求CLR的那些模块（托管模块）所持有的。包含：
1、用于生成模块的CLR的major(主）和minor（副）版本号；
2、一些标志（flag）；
3、一个MethodDef标记（稍后详述）；
4、它指定了模块的入口方法（前提是该模块是一个CUI或者GUI执行体）；
5、一个可选的强名称数字签名；
6、模块内部的特定元数据表的大小和偏移量。（可以查看CorHdr.h头文件中定义的IMAGE_COR20_HEADER，从而了解CLR头的具体格式。）
元数据：是一个二进制块 有三个表
1、定义表（definition table）
2、引用表（reference table）
3、清单表（manifest table）