对于开发人员来说， .NET 框架的确太爽了。
就我试用.NET 的经验来看， .NET 全面的技术支持真的是非常强大。我觉得我已经离不开 .NET 了。例如当我需要一个哪怕非常简单的界面时，一旦想到.NET创建界面的轻松，我就很难强迫我自己用VC/MFC去艰难地构建一个界面。
我认为微软的确实现了他的诺言：减轻程序员的负担，让程序员专注于他真正想要的功能而不用去考虑太多额外的东西，从而大大加快开发的速度。
这就是 .NET 的优点。

对于用户来说，.NET 是一个让人很不舒服的东西。传统的软件差不多是一点击就打开。可是当打开 .NET 应用程序，哪怕是启动一个非常小的应用程序时，那个漫长的等待阿，真能郁闷死人。他们不一定知道那是第一次调入 .NET 支持库所花的时间，他们也不知道某些杀毒程序和病毒能够把这个调入时间放大到10倍20倍或更多时间，他们只能无奈地看着亮起来就不想灭的硬盘灯，听着咋咋的硬盘响而益发郁闷。特别是对于某些系统维护人员，有时候单位要安装一个小型应用，他们不得不在几十台电脑上安装 .NET 框架；如果目标机是 Win2000
那还得去找来 windows installer 3.0。。。。

这便是 .NET 的缺点

所以我想是把 .NET 托管代码本机化，将一个 .NET 应用程序编译成本机代码，使其彻底脱离 .NET 环境，能够在纯粹的操作系统里运行， 应该是 .NET 的发展方向之一。

同意我意见的人请跟贴。如果有微软专家看到这个帖子，希望能向微软提出相关的建议。

接分.接分.

不同意，其实微软做这个的原因应该有一部分是想跟JAVA类似的，希望可以跨平台。
而且大家现在写程序的时候考虑到多核要怎么执行么？如果按楼主说的方式的话就必须要考虑这个问题了。

问题不单如此，还有向下兼容的问题。
我们开发一套系统，是在.net 1.0 框架上做的。在.net2.0 框架上不能运行。。。。。。

微软的东西给我感觉就是中看，不中用。想开发个应用系统的话，自行改装的东西太多。

关于.NET GUI程序的执行效率问题：

1、Java的JVM一样需要加载时间
2、所有的GUI，包括Swing、SWT和.NET的，都有要求，就是所有UI的更新运行在一个线程中，所以涉及UI的程序运行效率如果不仔细设计的话，普遍都会非常低。但是要低到硬盘灯狂闪的境地，还是要有一定水平的
3、不知道楼主有没有用过JVM，有没有去尝试设置过那些启动参数。相比之下，.NET的CLR算是好多了。

第一次启动.net应用程序时，没有你说的那么漫长。
等待是需要的，任何语言开发的应用第一次运行的时候，是不是都需要加载一些必要的组件或者服务之类的，这都需要点时间。
但.net 绝对不是非常漫长的等待。我想是这样的。

本地化.Net代码好像和.Net的设计初衷背道而驰了。

1、没有必要本地化
2、执行效率未必高过托管的，因为托管代码的优化策略不同，理论上讲，运行时优化效率比编译时优化的效率高
3、托管的还有另外的好处

如果实现本地化，那微软所说的跨平台就支持不了了。