想要运行这些会产生IL的语言，就必须在机器上装有.NET Framework，就如同要运行MFC程序或者VB6.0程序就要装MFC的Library和VB的DLLS。
C++的编译器编译的时候会产生非托管的代码以及非托管的数据，这些单元不需要CLR来执行他们。但是如果一定要指定CLR来执行，C++的编译器所产生的单元会包含托管的代码。当然，在这种情况下，CLR当然就得安装在机器上咯。在微软所有的编译器中，c++的编译器很unique，因为他们允许开发者既可以写托管的代码，又可以编写非托管的代码。同时也是唯一一个能在代码中同时定义2中代码的编译器。这样就极大的方便了开发者在代码方面的集成。
CLR经常性的不是与模块(module)一起工作的，而是与程序集(assembly)一起工作。程序集是一个抽象的概念，首先，一个程序集是一个模块或者多个模块或者资源文件的逻辑分组。其次，一个程序集是代码重用，安全，版本控制的最小单元。依赖你使用的编译器或者工具会产生一个独立的文件或者一个多文件的程序集。在CLR的世界里，一个程序集其实就是所谓的组件。
PE32(+)中包含着一个叫做“清单”的数据块。这个清单简直就是元数据另外一种形式的表，它描述了这些文件是如何构成程序集的。
Assembly mainfest:describes the set of files in the assembly.
默认的情况下，编译器将流出的托管模块变为一个程序集，而编译器流出的托管模块包含一个清单，此清单表明程序集只包含一个文件...
程序集的存在让你的部署更加随意吧~
一个程序集的模块也包含应用程序集的信息，所以CLR可以直接执行这些引用的程序集，不用额外的信息，部署程序集比部署一个非托管的组件简单多了。
每一个你建立的程序集都可以是一个可执行性程序或者是一个DLL，当然，这些儿玩意都是用CLR来管理它的执行的，这就意味着你的机器必须安装.net framework，某些版本的windows已经装好了。
查看Framework是否安装。
查看已经安装的Framework版本。
只要.net framework版本对的，代码都可以跑。
环境可以选 - -
还是讲32位，64位的...
Executing Your Assembly's Code
IL是比大部分CPU机器语言更高级的语言，可以把IL座位一门面相对象的机器语言来看待。
IL是可以用汇编语言来写的。
你一定要记住，任何高级语言所表现出来的处理功能只是CLR提供功能的一部分。然后，IL程序集却允许开发者使用所有CLR的所有功能。可见IL的重要性。
我想很多其他的书会把CLR当做一门语言来写，所以很多的开发者对CLR的认识就限制在他们所使用的语言内了。
JIT编译器负责把IL转换成自然机器指令（just in time）
Main方法的执行，其实是2个步骤，第一个步骤是JIT把IL翻译成自然机器语言，第二个步骤就直接执行而不经过JIT了。
第一次call的时候执行，第二次速度就会很快了，因为第一次已经执行过了。
JIT把自然机器指令是存储在动态内存中的，这就意味着这些机器指令在程序的生命周期完结时也消散了。所以，如果你以后再来运行的话，JIT编译器又要把IL编译成自然机器指令。
在方法内部所花的时间远比调用方法的时间要多。而且要知道的是，JIT可能会花很多时间来优化代码，但是这些经过优化的代码会拥有较好的性能。
对于C和C++背景的开发者，他们可能会对性能有所怀疑。因为，非托管的代码，就这样简单的执行掉了。而在这个托管的环境中，编译代码需要2个步骤，第一步，编辑器会无视source code,尽可能的生成IL代码，但是为了要执行IL代码，IL代码要在运行时中转换成自然机器指令，这可能就会需要更多的内存以及CPU占用时间。
相信我，我也是从c/c++那边转到CLR这边来的，我也曾对这些额外的步骤持怀疑的态度。事实是，这第二次发生在运行时的编译的确降低了性能，的确消耗了内存。然后，微软已经尽他们最大的可能来把这些额外的开销降低到最低。
如果你还不相信，那你就自己去测试一下好啦，我想你对实际结果会很吃惊的。
也许你会发现这一切很难相信，但是很多人（包括我）认为托管代码比非托管代码表现的要好。这是有原因的，举个例子，JIT编译器把IL代码转变成自然机器指令的时候，编译器在这个环境中比非托管编译器知道的东西更多。这里有一些托管代码表现更好的原因：
-
JIT编译器会使用奔腾4的CPU一些特殊的指令。
-
自动识别，如果只有1个CUP，JIT编译器就不会产生任何CPU指令了。
-
在IL代码转后成自然代码的过程中，通过观察执行模式能够减少一些错误的分支。