小弟我想请教下各位大神，就是用这个C#开发桌面程序都是编译成中间语言，把这个程序发给别人还得要别人的机器上安装对应版本的.NET才能运行，搞得好烦哦。我想了下，既然中间语言是靠JIT编译器“翻译”执行的，那如果谁你能够开发一个程序，可以把这个JIT编译器“翻译”出来的二进制程序保存下来不就是二进制程序了嘛？微软完全可以在VS里面集成一个可选项嘛，让开发者发布的时候选择是否编译成二进制程序，这样岂不是更方便？
注：小弟我只是菜鸟一枚，各位大神请勿喷！
------解决思路----------------------
比如说你基于 mfc 等去开发与 .net 程序相同功能的程序，那么 mfc的巨大的类库也根本只是相当于.net中一点点功能，你还需要加上其它一堆、各种类库，最终你给你的程序发不要带上的类库并不比 .net framework 小。只不过，你可以手动选择这些类库中需要哪些dll、不需要那些dll而已。如果要用户在windows上发布一次类库，以后就发布很小的exe文件就行了，那么还是要让用户在windows上安装一次完整的类库的。
------解决思路----------------------
具体来说，用jit二次编译的好处有：
（1）更加优化的程序，如果直接编译，你不知道目标平台用什么处理器，那么为了程序能正确运行，你不能使用特定处理器才有的指令集。不同的处理器，可能这样优化在另一种处理器上反倒没有效果，所以本地编译器只能产生折衷的编译优化。
（2）方便代码在不同处理器和平台的移植。比如windows 8.1/windows phone，你都可以使用相同的语言编译，然后在不同的平台运行。
（3）降低编写一种语言的难度，jit相当于后端编译器，对于中间语言，编写一个编译器相当于只要做词法、语法分析得到ast就可以了，而目标代码生成、优化都不需要了。
（4）提高程序的质量，以及安全性。中间代码程序更容易进行代码审计，比如说一个不受信任的程序不允许访问硬件和敏感数据，如果程序是面向本地代码的，分析和限制这样的程序运行就很困难，而jit可以对此把关。
------解决思路----------------------
要我看不是技术问题，即使技术上这么做有种种好处，也还可以增加这个功能给用户选择，大概还是商业层面的考虑更多。
------解决思路----------------------
你可以在安装是编译成native code.
参考:
Walkthrough: Using a Custom Action to Compile a Binary to Native Code at Installation
https://msdn.microsoft.com/en-us/library/vstudio/3hwzzhyd(v=vs.100).aspx
------解决思路----------------------
VC++不就是直接编译成二进制吗
既然已经有编译器能直接编译二进制了,为什么还要再出一款直接编译二进制的编译器,这样做有什么优势?
而且相比于这样做能拉拢的用户量来说,需要的工作量完全不成正比
你有一种平台,就需要一种编译器
------解决思路----------------------
现在微软提供了把.Net代码直接编译成机器代码的编译器,叫做.Net Native, 不过目前只支持win8 中的windows store应用.
------解决思路----------------------
就算原生了，也会用了那些链接那些，40多M的程序 估计没人会用的。