.exe文件，DotNet 还是 Native？
现象:
你双击一个exe文件，过了一会系统提示你这个程序的运行需要.net Framework.
问题：
到底一个.exe文件是Native Program还是.net Program?
问题的阐述:
在了解背后的故事之前, 这个现象给我对DotNet架构，DotNet程序和Native Windows程序之间的关系的理解造成了困惑：本来应该是很容易理解的，DotNet 跟JAVA一样， 利用runtime(或者call Virtual mechine) 来方便代码的移植，提供垃圾回收、安全保护等机制。 这样说来，Native code是有OS的进程调度程序载入。而DotNet程序（文件），跟JAVA一样，应该有一个比如.dn的后缀，双击后由注册的CLR（common language runtime, DotNet的"虚拟机"）负责调度运行。
但是事实是，DotNet程序的后缀一样是.exe，和Native Code一样。这就让人糊涂了：为什么这两个是一样的，我要怎么区别，背后的机制是怎么样的？
在讨论这个机制前，让我们先看看Native Program和DotNet Program的编译运行过程：
说明一下，个人觉得右边那个Assembly应该叫DotNet Assemble更合适。而左边那个，一般都直接叫Machine code，很少用Assembly这个说法。
解：
简单地说，微软把.NET assembly编译成符合 PE 可执行格式的文件，在.NET assembly里面有一小段Native Code用来调用(启动)CLR。也许你会问，那这段Native Code会不会成为这个.NET程序OS Independent 的绊脚石？ 答案是不会，因为这一小段Native Code的存在只是为了兼容性的考虑，从WIN XP开始，Windows系统的调度程序就增加了对.NET程序的原生支持：它会自动检测可执行文件中的CLI（Common Language Infrastructure）头，如果有，那调度程序就会自动地调度CLR。
我想问题已经说明白了：）对详细细节感兴趣？-> HERE
尾声：
微软通过这种方式“无缝”地把.NET Framework整合到它自己的操作系统中，但我觉得这有“霸权主义”的味道，而且在一开始害得我理解不能，爬了好些链接才搞明白：（
附图一张，关于CLI。当然，看wiki是最佳选择
