什么是MSIL，CLR，什么是CTS意味着有n个网站解释这些概念，我们都知道，但是如果我们想了解源代码到机器代码转换过程的确切端到端过程与工作流图像，没有人在一个地方解释所有内容。
所以我在这里的问题与其他问题不同，我们可以将源代码等详细信息获取到 MSIL(程序集)，然后使用 jit 编译器等将其转换为本机代码，但是当我们编译时，没有清楚地了解幕后发生的事情以及程序集(.dll 或.exe)ILASM 之间的序列顺序是什么.exe， MSIL，CLR，CLS，CTS等等。这些东西什么时候会被称为？。
谁能用示例图片逐步解释 Dot Net 框架源代码编译过程的概述？而且我相信这对所有在一个地方查看整个 .net 编译过程的其他人也会有所帮助。
使用白板和大量时间解释这一点要好得多，但我会尝试一下。
.NET 编译/构建=>将C#/VB.NET代码转换为带有MSIL的PE exe 格式+ 加载 .NET 框架 (CLR)的一些技巧。
Windows仅识别PE 格式的可执行文件。但它不能按原样运行MSIL。因此，作为编译/构建过程的一部分，.NET exe 与 .NET 框架程序集(用于JIT编译、GC等)一起引导。这是一种愚弄Windows操作系统的伎俩。OS 将其作为正常进程启动，但控制权不会直接移交给MSIL代码。相反，它被移交给 .NET CLR 程序集(这是普通的机器代码 dll)。然后，.NET CLR 程序集开始JIT编译exe中打包的 MSIL 代码，并接管内存和线程管理。
这是大多数新手 .NET 开发人员感到困惑的缺失部分。所以简单的技巧是;.NET exe具有额外的引导代码，这些代码在到达MSIL之前执行。所有剩余的东西，如ASP.NET，WPF只是那些加载的CLRdll。这就是为什么.NETexe 比本机 C/C++ exe 慢得多的原因。
您的其他查询
ILASM-> 是一个可以读取 .NET exe 文件并显示它包含的 MSIL 的工具。像Reflector这样的工具甚至可以将MSIL代码转换回C#/VB.NET
CLR-> 是作为编译过程的一部分引导并根据需要加载到内存中的程序集。它正在运行您的 MSIL 代码。
CTS-> 只是您编写代码所依据的类型系统