什么是MSIL，CLR，什么是CTS意味着有n个网站解释这些概念，我们都知道，但是如果我们想要了解机器代码转换过程中源代码的确切端到端流程工作流图像，没有人在一个地方解释一切。
所以我的问题与其他人不同，我们可以获得像MSIL（汇编）的源代码这样的细节，然后它将通过使用jit编译器等转换为本机代码，但是当我们编译时，没有清楚的图片说明发生了什么在幕后，以及Assembly（.dll or.exe）ILASM.exe，MSIL，CLR，CLS，CTS和all之间的顺序顺序是什么。什么时候会叫这些东西？
任何人都可以一步一步地解释Dot Net框架源代码编译过程的概述，并以样本图片结束吗？而且我相信，对于那些在一个地方寻找完整.net编译过程的人来说，这也会有所帮助。
解释这是更好的使用白板和很多时间，但我会试一试。
.NET编译/构建=>将C＃/ VB.NET代码转换为PE exe格式，其中包含MSIL +加载.NET框架（CLR）的一些技巧。
Windows仅识别PE格式的可执行文件。但它无法按原样运行MSIL。因此，作为编译/构建过程的一部分，.NET exe用.NET框架程序集（用于JIT编译，GC等）引导。这是一种欺骗Windows操作系统的技巧。操作系统将其作为正常过程启动，但控件不会直接移交给您的MSIL代码。相反，它被移交给.NET CLR程序集（这是普通的机器代码dll）。然后.NET CLR程序集启动JIT编译打包在exe中的MSIL代码并接管内存和线程管理。
这是大多数新手.NET开发人员所困惑的缺失部分。所以简单的伎俩就是; .NET exe有额外的引导代码，在到达MSIL之前执行。所有剩下的东西，如ASP.NET，WPF只是那些加载的CLR dll。这就是.NET exe比原生C / C ++ exe慢的原因。
您的其他疑问
ILASM - >是一个可以读取.NET exe文件并显示它包含的MSIL的工具。像Reflector这样的工具甚至可以将这个MSIL代码转换回C＃/ VB.NET
CLR - >是那些作为编译过程的一部分进行自举的程序集，并根据需要加载到内存中。它正在运行你的MSIL代码。
CTS - >只是您编写代码的类型系统