模块，准确的来说，并不是C#的概念，而是微软的运行时环境CLR的概念。想要学好C#断然不能只是会使用VS之类的IDE写写代码然后编译运行，很多相关的概念我们也需要去了解。

这一节，我们就简单讨论下C#模块。

其实C#模块，我们几乎每天都需要接触到（如果我们每天都需要写C#代码并且进行编译的话），每次我们对一个C#类（class）进行编译都会生成模块。

csc编译获得模块

下面，我们以经典的hello world为例。

1. 创建一个Program.cs文件，内容只是简单的向控制台输出hello world：

public sealed class Program{
	public static void Main() {
		System.Console.WriteLine("hello world");
	}
}

2. 使用csc.exe 对文件进行编译：

csc.exe /out:Program.exe /t:exe /r:MSCorLib.dll Program.cs

如果以上命令运行成功的话，我们会在源文件的文件夹中得到一个Program.exe的文件。这个Program.exe 就是一个标准的PE32或者PE32+的文件（PE32+对应的是64位，这里没有PE64），也就是一个C#模块。

在继续讲解C#模块之前， 我们先来看看上面这个编译命令，这个命令还是有点意思的。

/out:Program.exe 告诉了编译器我们最后需要生成的是一个exe文件。

/t:exe 看起来和上一个out参数似乎有些重复，这也是这个参数比较迷惑人的地方，t其实代表的是target，exe其实只是指代了没有图形界面的应用程序。如果是我们平常使用的比如迅雷之类的应用那么使用的就应该是winexe。这种类型是具有图形界面的。

/r:MSCorLib.dll，r这里是reference，是为了声明编译Program.cs我们需要使用到定义在MSCorLib.dll 中的某些类型（在我们的例子中就是Console）。

Response文件

有心的朋友可能会发现，其实我们并不需要声明MSCorLib.dll的引用，直接使用如下命令，也能够编译成功。

csc.exe /out:Program.exe /t:exe Program.cs

事实上确实如此，为了方便进行编译，而不需要每次都输入一串参数，csc允许我们使用Response文件来提供参数。

因此我们可以把刚刚使用到的三个参数全部放到response 文件中并保存为Program.rsp，这个文件内容如下：

/out: Program.exe (这里的红色没有任何特殊含义，我确定头条编辑器为何将此行变红)
/t:exe
/r:MSCorLib.dll

然后运行如下命令，也可以得到同样的结果。

csc.exe @Program.rsp Program.cs

参数覆盖规则

聪明的朋友肯定又发现了，可是我们之前并没有定义response文件，为什么我们还是可以不指定引用。这个原因就在于，csc自带了一个全局默认的response文件。我们可以在csc的安装目录中找到这个csc.rsp文件。而这个csc.rsp文件就包含了许多系统自带的常用的引用。因此我们并不需要去声明这些引用。

老白使用的是VS2019安装的版本，因此csc.exe文件可以在“C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Roslyn\”路径中找到，同样的，这个文件夹也包含了csc.rsp文件。

既然存在多个地方可以进行配置，那必然会存在优先级的问题。想必聪明的朋友已经想到了，csc采用的是以下顺序获取参数，一旦获得需要的参数就不再向下查找：

1. 命令行中带的参数
2. 本地传入命令行的response文件中的参数
3. 全局的csc.rsp中的参数

模块内容

通过csc编译出来的模块，需要使用CLR进行运行。那么一个模块是怎么让CLR知道应该怎么进行处理的呢？这就需要我们看看模块到底包含了哪些信息了。

PE32/PE32+的头文件

头文件这个东西，名字很有意思，其实也非常准确，一般来说我们看到一个人的“头”就能知道这个人是谁（who)，大致的年龄（how old，简称how），虽然不准确但是灵魂三问已经完成两问了。

同样的，PE32/PE32+头文件也给我们提供了这些信息。头文件里包含了PE文件类型的信息（who），我们可以知道这是一个GUI文件还是一个普通DLL等等。此外也包含了文件创建信息（how old）。如果这个PE头文件使用了PE32的格式，那么就可以在32位或者64位的Windows上运行。如果使用的是PE32+的格式，那么只能在64位的Windows上运行。

CLR 头文件

如果说PE32/PE32+头文件没什么用途的话（事实上也确实如此，CLR大部分情况下并不使用PE头文件），那么CLR头文件则是包含了CLR运行此文件的必要信息。几个主要的信息包括了，所需要的CLR版本，模块的入口函数，模块的metadata数据位置和大小等等。

元数据（metadata）

主要包含了两部分，一部分是这个模块本身所包含的类型(type)和成员(member)。另外一部分描述了这个模块会引用到类型和成员信息。

IL 代码

整个模块的核心部分，是编译器编译C#源码所生成的中间代码。在运行时，IL代码会被CLR编译成cpu指令。

这就是一个模块所包含的4个部分。这里比较重要的一点是这四个部分都是相互耦合在一起的，这样就能够保证元数据和IL代码之间不会出现不同步的问题。

此外，可能有很多同学都会有困惑，为啥已经有了IL代码了，其实就能够知道这个模块本身所包含的类型和成员也能之后引用了哪些其他模块，为啥还需要元数据呢？我的理解也不一定准确，但是很大一个作用就是GC可以通过阅读元数据来很快的判断哪些类型之间有引用，从而判断是否需要进行GC。此外，我们编写的源码，在进行编译的时候，编译器也能够很快的通过元数据来判断我们的源码是否合规。

好了，到此，老白就将如何（手动）产生一个模块以及模块的组成说完了。如果有什么问题，欢迎大家和老白一起探讨。

码字不易，如果觉得有用或者喜欢老白的内容，欢迎点赞收藏关注。