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

　　文/赵劼　　最近在StackExchange的编程板块上惹起了一场关于“Mono能否可以作为跨平台. 包括Mono创立者MigueldeIcaza在内的许多人给出了回复。 理由如下：　　首先， CLI（CommonLanguageInfrastructure）和. 前者是地下规范， 而后者是微软对这一规范的实现， Mono则是CLI的又一实现， 它从来不是“可移植的. NET”。 异样， NET绑定在一同。 　　Mono相对于. NET是有些落后， 但也只要一丁点而已。 0的代码（最新的. 与此同时微软最近把一切的DLR代码都开源了（运用Apache2. 这意味着mono可以直接运用IronPython， IronRuby， 同时F#也不久前也曾经开源， 再加上微软都会定期发布. 因此Mono开发人员简直可以时刻和. NET坚持同步。 . NET中的部分工具和扩展， 如CodeContract等等， 那么Mono也会提供对应的实现。 　　WinForm没有得到完整的移植， 由于它们是. NET的特性功能， 有一些组件库是跨平台的， 例如GTK#和Silveright， 假如你从编写应用程序的一开始就思索到可移植性， 此外， Mono提供了一个很薄的封装层， 　　对于不愿意运用开源产品的商业应用， 此时授权方案便不是LGPL了。 　　因此， 假如要思索“. NET可否移植”这个命题， 则它是成立的。 但假如换个说法“我有个运用. 那就不正确了——不过Mono让移植这样的应用程序变得复杂许多。 　　除了技术方面的因素以外， Python， Ruby……）， 假如在写代码时不思索可移植性， 那么你应该假设这些代码可以直接跨平台执行的可能性为零（即使实际上这样的可能性要高出许多）。 你无法随便拿到一个程序集就保证它能在Mono下正确执行。 你还是需求不时地进行测试。 假如你运用持续集成， 那么只需复杂的创立一个Mono构建的节点即可。 很多成绩可以在开发阶段就处理掉， 再加上一点点先期规划就能得到很好的跨平台性。 剩下的， 例如平台相关的代码（如P/Invoke）， 则可以经过封装， 为不同平台提供针对性的实现。 简直不会付出额外的代价就能得到很好的移植性。 　　当然， 运用一个Mono中不存在或是不兼容的类库则另当别论， 不过就我的团体而言还没有遇到这样的状况。 这些是我们在任务中实际用到的做法， NET+Mono”是跨平台的处理方案。 　　我用过Mono， 我认为它就和其他开源平台一样好， 假如你能接受Clojure或Scala这样的开源项目， 那么Mono也能让你满意。 Mono对于. NET的支持程度可以参考MonoRoadmap页面。 它们有或多或少的区别， 　　“. NET能否跨平台”是一个模糊的说法， 无论是框架自身还是整体环境都在不时改动。 NET的基础架构， 到处执行”， 与其为不同平台提供统一的API和运转时， 不如各自平台上的最佳体验提供最正确的工具。 要知道如今曾经出现了游戏设备， 分布式集群等太多激动人心的平台。 　　微软的. 它只能运转在Windows上。 其他系统上还有一些. NET框架的变体， 例如WindowsPhone7， XBox360和浏览器中的Silverlight， 它们都有些许不同的配置（Profile）。 　　如今你曾经可以在各个主流的操作系统， 电话， 虽不完整， 这不是坏事。 SilverlightAPI可以控制浏览器， 这不关电话什么事；由于缺少合适的支持， XNA的着色功能对PC硬件也没有多少意义。 你越早认识到. 就能越早成为更好的开发人员。 　　其他处理方案的实质也是一样的。 不过这里有个特定技术与特定平台的列表：