将我的应用程序转换为.Net真的是个好主意吗?

不要仅仅为了转化而这样做。

编辑:我还想补充一点,如果你在.NET中启动一些小项目,只是为了知道会发生什么,然后再决定转换现有项目是否有效。

你的三点都至少有一点正确,尽管“1”非常模糊——普通的.NET应用程序往往比本地应用程序启动时间更长——也许这就是你的意思?

在某些情况下,Mono是点“2”的缓解措施。

MS对“3”点的处理确实慢得令人不快,但我认为他们正在逐步做到这一点,互联网速度的普遍提高意味着人们比5年前更不关心几十秒的梅格。

对我来说,最大的问题是,几乎所有关于C语言编程的东西都比C++好得多(我是一个硬核C++人,有迈尔斯和Alexandrescu书籍的架子),当你必须回到C++时,感觉就像是一场冷水浴。

缓慢的响应时间可能被误导了。您基本上被锁定在windows中(Mono除外,它还不成熟),并且依赖于运行时。这就是说,运行时通常已经安装在大多数系统上(不过如果失败,您必须确保并提供安装方法)。

我的问题是,为什么要切换?如果您已经有了本机代码,那么移植工作将是一件痛苦的事情。您的整个开发团队也需要学习新的.net语言。为了克服转换到任何语言(更不用说.net)所带来的障碍,您需要在转换方面有一些巨大的优势。

不管第1点和第2点是什么,我都不会太担心.NET运行时——我现在很少遇到没有安装它的机器。

至于反应慢,我还没有这样的经历。我认为你可以用任何语言编写一个反应缓慢的应用程序。NET并不是最差的,使用它对开发者有巨大的好处。

不过,作为一项规则,我从不在没有确凿理由的情况下重新开发某些东西。让你的应用程序更新到最新和最棒的版本听起来可能是个好主意,但往往会导致时间的巨大损失,而收益却微乎其微。

可能没有令人信服的理由重新编写应用程序。性能和较小的内存占用将是这些应用程序的一个持续优势。任何生产率的提高都可能远远超过移植成本。

对于新的应用程序,切换到.Net可能会带来一些好处。与C++相比,它将更高效,但代价是运行时依赖性、内存占用增加和某些性能命中。

你也可以选择做混合系统,在其中,你可以将一个.NET前端放在一个用C++编写的后端上,以加速或更多地控制内存消耗。对我来说,内存消耗可能是最大的。在体验过使用大型托管代码应用程序(Oracle Warehouse Builder和BIDS)的乐趣后,即使在高规格的现代PC上,这些应用程序的性能也非常糟糕。

这取决于几个因素。

.Net是一个很好的平台,但它并不适合所有人或每个项目。我要说的是,运行时问题在.Net刚刚出现的时候是一个更大的问题,在这一点上,它已经变得相当微不足道了。

任何 不同的开发语言或框架相当高。在以下所有情况都属实之前,我不会这么做:

• 您的客户中有相当多的人要求这样做。
• 你有开发技能来完成转换。

如果您对本机代码感到满意,并且决定权归您,那么为什么要移动呢?

就我个人而言,我不想念我的C++时代(MFC,com等等),对生产力的IMO没有多大的帮助。我发现.Net和C#提供了多种工具和功能的完美结合。我可以轻松构建看起来和感觉都像普通Windows应用程序的Windows应用程序。

我也很高兴C#提供了一种有趣的混合了OO和声明式编程的方式,这是我喜欢的。该框架还不完整,但仍有很多功能需要添加。

可能.Net最有趣的部分是越来越多的针对该平台的不同语言。我欢迎IronPython和IronRuby的加入,据我所知,随着VisualStudio的下一个版本,IronPython和IronRuby将成为一流的.NET语言。

您的应用程序不应该明显变慢,但是如果您在终结器队列中留下太多的对象,GC可能会导致执行中的短暂中断(.Net GC不是异步的)。从技术上讲.Net应该和本机代码一样快,但我已经读过几次了,事实并非如此:但与此同时,它只是稍微慢了一点(正如他们所说,只有在学术或实时情况下才相关)。

至于较长的启动时间,您可以重新设置程序集。这会将程序集预编译为本机代码,这样在第一次访问方法时就不会产生JIT编译的成本(请记住,JIT只在第一次调用方法时编译,在应用程序运行时不会再编译)。

极小的 (当你写了1000行代码却得到了一个小于meg的DLL时,这实际上是令人沮丧的)。如果您使用一键式部署,那么更新的成本也非常小(如果您遵守规则并将功能剥离到适当的程序集中)。