讨论：“Mono是个跨平台的.NET”是否是个正确的说法

　　文/赵劼　　最近在StackExchange的编程板块上引起了一场关于“Mono能否可以作为跨平台. CLI（CommonLanguageInfrastructure）和. NET是有区别的， 前者是公开规范， 而后者是微软对这一规范的完成， 它从来不是“可移植的. NET”。 也不和. NET绑定在一同。 　　Mono绝关于. NET是有些落后， 但也只要一丁点而已。 Mono可以运行C#4. 0的代码（最新的. NET版本）， 与此同时微软最近把所有的DLR代码都开源了（运用Apache2. 0授权协议）， IronRuby， NET的CTP版本， 因此Mono开发人员简直可以时刻和. . NET中的部分工具和扩展， 如CodeContract等等， 它们并没有mono中的完整完成， 不过它们的运用并不普遍。 　　WinForm没有失掉完整的移植， 由于它们是. 而并非CLI的一部分。 CLI中并没有定义特定的组件库。 有一些组件库是跨平台的， 例如GTK#和Silveright， 如果你从编写运用程序的一开始就思索到可移植性， 那就不应该运用Win. NETForm/WPF。 此外， Mono提供了一个很薄的封装层， 　　关于不情愿运用开源产品的商业运用， Mono可以运用另一种授权方案， 我想如果你从一开始就思索到框架的可移植性问题， 则它是成立的。 但如果换个说法“我有个运用. NET开发的Windows运用程序， 它应该可以在Mono上运行”， 　　除了技术方面的要素以外， 关键还是在于编写代码的方式。 　　无论是哪种跨平台的运用程序（例如Java， Ruby……）， 那么你应该假定这些代码可以直接跨平台执行的可能性为零（即便实际上这样的可能性要高出许多）。 你无法随意拿到一个程序集就保证它能在Mono下正确执行。 　　不过关于一个新项目（或是你可以轻易重构的项目）， 选择. NET/Mono作为可移植的方案之一则是明智的， 如果你运用继续集成， 很多问题可以在开发阶段就处置掉， 剩下的， 简直不会付出额外的代价就能失掉很好的移植性。 不过就我的个人而言还没有遇到这样的情况。 这些是我们在任务中实际用到的做法， NET+Mono”是跨平台的处置方案。 　　我用过Mono， 我认为它就和其他开源平台一样好， 只不过不是微软直接支持的而已。 如果你能接受Clojure或Scala这样的开源项目， 那么Mono也能让你满意。 Mono关于. NET， 例如如今你还无法运用EntityFramework。 无论是框架自身还是整体环境都在不时改变。 作为. CLI规范是跨平台的， 但如果要在不同平台上失掉最好的体验， 则势必要运用各自平台上有针对性的API。 好比电话和大型机的区别实在是太大了。 不如各自平台上的最佳体验提供最正确的工具。 试想那些非WindowsPC或Unix服务器的程序员， 要晓得如今已经出现了游戏设备， 散布式集群等太多激动人心的平台。 　　微软的. NET框架不是跨平台的产品， 它只能运行在Windows上。 例如WindowsPhone7， XBox360和浏览器中的Silverlight， 它们都有些许不同的配置（Profile）。 电话， 嵌入式系统或是服务器上运用基于. NET的技术， 以下是各种CLI完成的列表， 这不是坏事。 例如， SilverlightAPI可以控制浏览器， XNA的着色功能对PC硬件也没有多少意义。 你越早看法到. NET不是个将开发人员绑定在特定硬件或平台上的处置方案， 　　其他处置方案的本质也是一样的。 要完整列出这些技术需要一张复杂的表格， 我不晓得如何在这里表现出来，