Building, Packaging, Deploying, and Administering ...

梁珍

说明：本文内容和术语来源于CLRviaC_4 。
如前面CLR 所描述的内容 ,本文将在前面阐述的CLR 环境，具体展开一些操作细节，方便大家对于.NET Framework和C#的环境有更进一步的认识。
我们先从.NET Framework 来看看其诞生的目标。
.NET Framework的目标

伴随着Windows 操作系统的流行，引入了非常多的开发者，也产生了非常多的.dll，COM，可以说是良莠不齐。与此同时，Windows也成为了一个庞大无比，极其复杂的操作系统。首先DLL的管理就成了一个极大的麻烦，不同的厂家写的DLL 很有可能导致整个系统的崩溃，另外不同版本的操作系统写的DLL 很容易导致兼容性的问题。
因此DLL增长速度快，兼容性差，是.NET Framework需要解决的头号问题。其次则是解决或者Wondows环境下编译，安装对应的DLL 过于复杂的问题，最后则是一并解决安全性的问题（应用可以被设置或者授予不同等级的权限）。

Building Types Into a Module

假设存在如下的Program.cs文件，里面定义了Class Program的Type
public sealed class Program {  
public static void Main() {  
System.Console.WriteLine("Hi");  
}  
}
我们可以通过以下命令行来输出对应的编译产生可执行文件 Program.exe结果。
csc.exe /out:Program.exe /t:exe /r:MSCorLib.dll Program.cs
/t  表示编译结果输出目标类型，可以是exe, standard portable executable(PE 32或者 64位应用),/t:exe 默认编译成CUI(Console user interface) 应用，/t:winexe  输出GUI(graphical user interface) 应用，采用 /t:appcontainerexe 的命令行则输出Windows Store app。
/r 表示引用对应的库文件，其中MSCorLib.dll 中包含着标准的Byte，Char，String，Int32 等很多基本类型，该编译开关可以告诉编译器 去外部哪些库中搜索对应的类型信息。
另外，需要注意的是，以下两种命令行输出的方式都有相同的结果。
csc.exe /out:Program.exe /t:exe Program.cs
csc.exe  Program.cs
当然，凡事也有例外，如果不想引用标准库中的类型，也可以通过如下方式来跳过对标准库的引用。
csc.exe /out:Program.exe /t:exe /nostdlib Program.cs
也许大家在使用这些命令的时候，也发现了，有些命令是不是必须的，有些事平台相关的，那微软也考虑到了这个问题，可以通过Response Files 来定义一些平台编译相关的开关，如将前面提到的命令符输入的开关，通过如下文本格式的命令行存储到Program.rsp文件存储下来。
/out:Program.exe
/t:exe
然后通过 csc.exe @Program.rsp CodeFile1.cs  CodeFile2.cs 类似的方式可以指定多个rsp 编译开关文件来进行编译，对于多个rsp 文件，存在着一些对应的规则，如Global.rsp 全局的配置文件可以被Local.rsp文件进行重载和覆盖，意思就是如果存在全局和本地的两个配置文件，只有本地配置文件会生效，另外对于通过命令行传入指定的配置文件的优先级是最高的，可以覆盖前面描述的默认规则。
在用户默认安装完成.NET Framework的时候，会默认部署一个全局的rsp文件，一般会存放在%Systemroot%\http://Microsoft.NET\Framework(64)\vX.X.X路径中。其中vX.X.X对应于当前安装的.NET Framework安装的版本号，其中内容如下，主要是概述了当前需要加载和引用的库文件，这个就像公共的默认需要包含的类型一样，能够为后续的编程带来很大的便利性，使用者不需要再去单独关注需要引用哪个公共类型库文件。



安装.NETFramework后的引用文件

当然/r(reference) 编译开关也可以直接引用完整的路径名，如果没有包含完整的路径名称将会按照以下四条规则进行对应的引用路径搜索。
1.当前的工作路径。
2.包含csc.exe文件，同时也包含MSCorLib.dll 的文件路径，这个文件路径主要来源于%SystemRoot%\http://Microsoft.NET\Framework\v4.0.####。
3.采用/lib指定的任何编译开关。
4.任何指定了采用 LIB 环境变量的的路径。
当然，也可以通过在命令行中增加 /noconfig  的命令行开关来进行关闭对于全局global 或者本地 CSC.rsp 文件的默认编译引用配置生效。

A Brief Look at Metadata

在看完了对应的编译过程后，咱们再来继续简单的看看当前编译的exe （PE）文件和对应的构成。一个托管的PE头文件一般由四个部分组成。
PE32(+) 头文件，CLR头文件，metadata文件，IL
一般而言，PE32(+)是指Windows 操作系统指定的标准的exe头文件，CLR头信息则是一个小的信息块，指明了当前CLR要求的一些模块信息，包含了CLR模块要求的主次版本号，一些标志信息，像MethodDef 中的标志符能够指明当前的模块是CUI(控制台程序)，GUI ,还是Windows Store excutable文件，还有一些可选的强名数字签名标识符。反正，这些头文件都包含了对应模块的一些具体元信息表的偏移和大小信息，对应的数据可以查阅CorHdr.h头文件中包含的 IMAGE_COR20_HEADER字段信息。
metadata 文件是一个由数个表格组成的二进制数据块。主要由三个表格组成，definition tables，reference tables，以及manifest tables。



Common Definition Metadata Tables



Common Reference Metadata Tables

大家可以看到，metadata中存在着许多的tables 信息，那么该如何查看这些具体的信息呢？.NET Framework 提供了对应的工具可供大家查阅，具体可以对想要查看的托管应用程序执行如下的命令行指令。
ILDasm.exe  Program.exe
这个命令行 会加载对应的exe程序集，并且将metadata以一种视觉友好的人类可读方式呈现出来。具体可以选择 一个信息展示视图来展示，View/MetaInfo/Show! 菜单或者采用快捷键(Ctrl+M)来展示对应的信息。





ILDasm.exe Program.exe执行后得到的MetaData数据

Metadata的详细细节咱们将留到后面的章节再继续做详细的介绍，在这里咱们用一个实用的小信息来做本章的结尾，对于任意一个应用程序，咱们可以通过如下的方式看到一些版本相关的信息，但是这些信息可以在哪里定义呢？



The Details tab of the dll Properties dialog box



定义Assemblies的头文件版本信息的数据结构

修改这种类型的版本信息一共有两种方法，一种如上图所示，可以在程序中定义对应的Assembly Attribute属性
另外一种方法则是，在Visual Studio IDE环境中编辑对应的信息：

陌上无尘

这么强,支持楼主，佩服