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

  Thorbjorn在提问中认为Mono并不能称作是跨平台的.NET,理由如下:

  • OpenJDK等Java提供商都通过了官方的Sun TCK来保证正常工作,Mono似乎并没有通过Microsoft TC上海企业网站设计与制作K。
  • Mono的发布总是落后于.NET,那么目前它又对.NET支持到什么程度呢?
  • 如WinForm等GUI工具是否可以在Mono下正常工作?
  • 商业用户不会将开源框架作为备选方案。

  用户sparkie首先回应了以上几点疑问:

首先,CLI(Common Language Infrastructure)和.NET是有区别的,前者是公开标准,而后者是微软对这一标准的实现,Mono则是CLI的又一实现,它从来不是“可移植的.NET”。同样,C#也是一个公开标准,也不和.NET绑定在一起。

Mono相对上海企业网站制作于.NET是有些落后,但也只有一丁点而已。Mono可以运行C# 4.0的代码(最新的.NET版本),与此同时微软最近把所有的DLR代码都开源了(使用Apache 2.0授权协议),这意味着mono可以直接使用IronPython,IronRuby,同时F#也不久前也已经开源,再加上微软都会定期发布.NET的CTP版本,因此Mono开发人员几乎可以时刻和.NET保持同步。.NET中的部分工具和扩展,如Code Contract等等,它们并没有mono中的完整实现,不过它们的使用并不广泛。如果这些扩展变得流行起来了,那么Mono也会提供对应的实现。

WinForm没有得到完整的移植,因为它们是.NET的特性功能,而并非CLI的一部分。CLI中并没有定义特定的组件库。有一些组件库是跨平台的,例如GTK#和Silveright,如果你从编写应用程序的一开始就考虑到可移植性,那就不应该使用WinForm/WPF。此外,Mono提供了一个很薄的封装层,现有的WinForm应用程序可以可以比较容易地移植为GTK#(不需要完全重写)。

Mono提供了一个工具:Mono Migration Analyser(MoMA),它能检查一个.NET应用程序能否移植到Mono上(如,是否使用了不可移植的类库,或是P/Invoke)。

对于不愿意使用开源产品的商业应用,Mono可以使用另一种授权方案,这时候Mono代码的归属权则交由Novell负责,此时授权方案便不是LGPL了。

因此,如果要考虑“.NET可否移植”这个命题,我想如果你从一开始就考虑到框架的可移植性问题,则它是成立的。但如果换个说法“我有个使用.NET开发的Windows应用程序,它应该可以在Mono上运行”,那就不正确了——不过Mono让移植这样的应用程序变得简单许多。

  随后Lloeki谈论了他的工作方式:

除了技术方面的因素以外,关键还是在于编写代码的方式。

无论是哪种跨平台的应用程序(例如Java,Python,Ruby……),如果在写代码时不考虑可移植性,那么你应该假设这些代码可以直接跨平台执行的可能性为零(即使实际上这样的可能性要高出许多)。你无法随便拿到一个程序集就保证它能在Mono下正确执行。

不过对于一个新项目(或是你可以轻易重构的项目),选择.NET/Mono作为可移植的方案之一则是明智的,不过对于跨平台的代码来说,你还是需要不断地进行测试。如果你使用持续集成,那么只要简单的创建一个Mono构建的节点即可。只要养成良好的习惯(例如路径的分隔符),很多问题可以在开发阶段就解决掉,而绝大部分代码只要使用单元测试以及其他一些常见的实践方式,再加上一点点先期规划就能得到很好的跨平台性。剩下的,例如平台相关的代码(如P/Invoke),则可以通过封装,为不同平台提供针对性的实现。这样产出的项目,几乎不会付出额外的代价就能得到很好的移植性。

当然,使用一个Mono中不存在或是不兼容的类库则另当别论,不过就我的个人而言还没有遇到这样的情况。这些是我们在工作中实际用到的做法,我可以放心的声称“.NET+Mono”是跨平台的解决方案。

  对于Mono于.NET功能的支持程度,Robert和Michael谈到:

我用过Mono,我认为它就和其他开源平台一样好,只不过不是微软直接支持的而已。如果你能接受Clojure或Scala这样的开源项目,那么Mono也能让你满意。Mono对于.NET的支持程度可以参考Mono Roadmap页面。Mono并不等同于.NET,它们有或多或少的区别,例如现在你还无法使用Entity Framework。

Mono不是.NET的移植品,有些技术是Mono不会或不打算实现的(如Workflow Foundation或WPF),此外它们还提供了微软.NET外的其他一些技术,例如SIMD扩展。简单地说,Mono和微软.NET是基于相同基础——CIL和BCL——的两个不同项目。

  在讨论中,Mono创建者Miguel de Icaza给出了最为详细的回应:

“.NET是否跨平台”是一个模糊的说法,无论是框架本身还是整体环境都在不断改变。

简单地说,作为.NET的基础架构,CLI标准是跨平台的,但如果要在不同平台上得到最好的体验,则势必要使用各自平台上有针对性的API。CLI技术家族从来没有试着要“一次编写,到处执行”,好比电话和大型机的区别实在是太大了。与其为不同平台提供统一的API和运行时,不如各自平台上的最佳体验提供最正确的工具。试想那些非Windows PC或Unix服务器的程序员,要知道如今已经出现了游戏设备,移动电话,机顶盒,分布式集群等太多激动人心的平台。

微软的.NET框架不是跨平台的产品,它只能运行在Windows上。其他系统上还有一些.NET框架的变体,例如Window上海网站建设s Phone 7,XBox 360和浏览器中的Silverlight,它们都有些许不同的配置(Profile)。

如今你已经可以在各个主流的操作系统,电话,移动设备,嵌入式系统或是服务器上使用基于.NET的技术,以下是各种CLI实现的列表,虽不完整,但应该可以覆盖99%的情况:

  • 基于x86和x86-64的计算机:

    • Windows:一般来说你会使用.NET或Silverlight,不过你也可以使用完整的Mono。
    • Linux, BSD或Solaris:完整的Mono或Silverlight。
    • MacOS X:完整的Mono或Silverlight。
    • Android:Mono及Android的子集。
  • ARM计算机:
    • Windows Phone 7:Compact Framework 2010。
    • Windows 6.5及更早:早期的Compact Framework。
    • Android设备:Mono/Android。
  • PowerPC计算机:
    • 在Linux,BSD或Unix操作系统上使用完整的Mono功能。
    • 在嵌入式系统中使用Mono,如PS3,Wii。
    • 在XBox36上运行Compact Framework。
  • S390, S390x, Itanium, SPARC计算机:
    • 完整的Mono支持
  • 其他嵌入式操作系统:
    • .NET MicroFramework或Mono的移动配置。

有时候相同的代码很难四处运行。例如XNA代码不会在每个桌面上运行,反之亦然。为了.NET不同的配置里运行,你需要修改些许代码。以下是我所了解的一些配置:

  • .NET 4.0配置
  • Silverlight配置
  • Windows Phone 7配置
  • XBox360配置
  • Mono核心配置:与.NET配置相同,可以在Linux,MacOS X,Solaris,Windows和BSD里使用。
  • .NET Micro Framework
  • Mono的iPhone配置
  • Mono的Android配置
  • Mono的PS3配置
  • Mono的Wii配置
  • Moonlight配置(与Silverlight兼容)
  • Moonlight扩展配置(Silverlight和完整的.NET 4 API)

以上配置都有多多少少的不同,这不是坏事。每个配置的设计都适应其平台,去除任何一个都是不明智的。例如,Silverlight API可以控制浏览器,这不关电话什么事;由于缺少合适的支持,XNA的着色功能对PC硬件也没有多少意义。你越早认识到.NET不是个将开发人员绑定在特定硬件或平台上的解决方案,就能越早成为更好的开发人员。

这意味着,有些API或解决方案可以在多个平台中使用,例如ASP.NET可以用在Window上海闵行企业网站制作s,Linux,Solaris,MacOS X上,因为.NET和Mono都提供了这些API。同时,ASP.NET则无法在某些微软支持的平台上使用,例如XBox或Windows 7,也不支持Mono的Wii和iPhone配置。

其他解决方案的本质也是一样的。要完整列出这些技术需要一张复杂的表格,我不知道如何在这里表现出来,不过这里有个特定技术与特定平台的列表:

核心运行时引擎(所有平台):

  • Reflection.Emit支持:除WP7、CF、XBox、MonoTouch和PS3外的所有平台 。
  • CPU SIMD支持:Linux,、BSD、Solaris及MacOS X。即将支持PS 3、MonoTouch和MonoDroid。
  • Continuations - Mono.Tasklets:Linux、BSD、Solaris、MacOS、PS3及Wii。
  • 程序集卸载:只有Windows。
  • VM注入:Linux、BSD、MacOS X及Solaris。
  • DLR:Windows、Linux、MacOS X、Solaris及MonoDroid。
  • 泛型:在iPhone和PS3上存在一些限制。

语言:

  • C# 4:所有平台。
  • C# 编译器即服务:Linux、MacOS、Solaris、BSD及Android。
  • F#、IronRuby及IronPython:除WP7、CF、Xbox、MonoTouch及PS3外的所有平台。

服务器技术:

  • ASP.NET:Windows、Linux、MacOS、BSD及Solaris。
  • ADO.NET:所有平台
  • LINQ to SQL:所有平台
  • Entity Framework:仅Windows
  • XML核心技术:所有平台
    • XML序列化:除WP7,CF和XBox外的所有平台。
  • LINQ 上海闵行企业网站设计与制作:white;' href='http://www.93tj.com'>上海徐汇企业网站制作to XML:所有平台
  • System.Json:Silverlight,Linux,MacOS,MonoTouch,MonoDroid(译注:可移植到其他平台)
  • System.Messaging:Windows、Linux、MacOS和Solaris的支持则需要RabbitMQ。
  • .NET 1 Enterprise Services:仅Windows。
  • WCF:完整版仅支持Windows。Silverlight、Solaris、MacOS、Linux、MonoTouch、MonoDroid支持其自己。
  • Windows Workflow:仅Windows。
  • Cardspace identity:仅Windows。

GUI技术:

  • Silverlight:Windows、Mac和Linux(Moonlight)
  • WPF:仅Windows
  • Gtk#:Windows、Mac、Linux及BSD
  • Windows.Forms:Windows、Mac、Linux和BSD
  • MonoMac - 原生Mac集成:仅Mac
  • MonoTouch - 原生iPhone集成:仅iPhone/iPad
  • MonoDroid - 原生Android集成:仅Android
  • Medi上海徐汇企业网站设计与制作a Center API:仅Windows
  • Clutter:Windows和Linux

图像类库:

  • GDI+:Windows、Linux、BSD及MacOS
  • Quartz:MacOS X、iPhone及iPad
  • Cairo:Windows、Linux、BSD、MacOS、iPhone、iPad、MacOS X、PS3及Wii

Mono类库 - 跨平台,可以在.NET里使用,不过需要手动编译:

  • C# 4编辑器及服务
  • Cecil - CIL操作,工作流,CIL探测,链接器
  • RelaxNG类库
  • Mono.Data.* 数据提供者
  • 完整的System.Xaml(用于安装程序,.NET没有提供这个技术)

MonoTouch为iPhone上运行的Mono,MonoDroid为Andriod上运行的Mono。PS3和Wii的移植只供索尼和任天堂认证的开发人员使用。

  在讨论中Miguel de Icaza还表示,IBM至少完成了两个针对AIX的Mono移植,不过他们的移植团队没有得到反馈其成果的许可。

时间: 2024-08-01 19:23:05

讨论:““.NET研究”Mono是个跨平台的.NET”是否是个正确的说法的相关文章

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

Thorbjorn在提问中认为Mono并不能称作是跨平台的.NET,理由如下: OpenJDK等Java提供商都通过了官方的Sun TCK来保证正常工作,Mono似乎并没有通过Microsoft TCK. Mono的发布总是落后于.NET,那么目前它又对.NET支持到什么程度呢? 如WinForm等GUI工具是否可以在Mono下正常工作? 商业用户不会将开源框架作为备选方案. 用户sparkie首先回应了以上几点疑问: 首先,CLI(Common Language Infrastructure)

用户研究的元思考:获取、提炼、转化

文章描述:用户研究三部曲:有关用户研究的战略思考. 用户研究的"元思考" 钻研任何一个领域,都离不开"元思考",或者称为"战略级思考":思考它要解决的基本问题是什么,思考它的核心的方法路径是什么,以及思考它面临的最大挑战是什么.用户研究如是. 用户研究面临的最大挑战是研究与设计之间的鸿沟,也就是说,研究的结果常常难以落地,难以为产品的设计和创新发挥直接可见的作用.因此,一种"用户研究无用论"的观点在业界颇有市场,最被人广泛提及

Mysql大数据量存储及访问的设计讨论

一.引言 随着互联网应用的广泛普及,海量数据的存储和访问成为了系统设计的瓶颈问题.对于一个大型的互联网应用,每天几十亿的PV无疑对数据库造成了相当高的负载.对于系统的稳定性和扩展性造成了极大的问题.通过数据切分来提高网站性能,横向扩展数据层已经成为架构研发人员首选的方式.水平切分数据库,可以降低单台机器的负载,同时最大限度的降低了了宕机造成的损失.通过负载均衡策略,有效的降低了单台机器的访问负载,降低了宕机的可能性:通过集群方案,解决了数据库宕机带来的单点数据库不能访问的问题:通过读写分离策略更

C#/C++/Java之间的本质对比讨论

问题描述 我在网上看过很多关于才C#/C++/Java三门语言之间的优劣对战,有人说C#,Java比C++强大应用稳定在开发领域有着无与伦比的稳定性,但回过头看一下很多古董公司用的都是C++,我们能从软件直接开发角度来说确实是Java,C++比较稳定,但跟多人在比较的时候忽略的了一个很重要的问题,从包容性,以及工具的全面性考虑,c++有着绝对的优势,虽说很多源有着模糊性只是不明确性,但包含范围确实比那些明确的源广泛了,但如果从确切的开发某一程序来说,这个有程序着明确的目的性以及程序的应用方面的指

PowerShell 5.0和跨平台PowerShell支持class类编程

PowerShell 5.0和跨平台PowerShell支持class类编程 PowerShell 5.0支持class类编程,具体查看:https://technet.microsoft.com/en-us/library/dn820211.aspx 这里给个最简单的例子: class A{ [string]$name A([string]$name){$this.name=$name} } $a=[A]::new("test") $a.name 另外,微软这两年做的跨平台Power

在MonoTouch中自定“.NET研究”义表格

为什么要定制表格? 表格在很多iPhone应用程序中都是必需的UI元素.虽然对于应用程序开发而言,这并非是一项新发明,鉴于设备尺寸等方面的限制,表格在iPhone中的功能是非常固定的. 苹果在其SDK中,直接内置了很多风格来让你定制表格.不过,在你最初创建表格的时候,它看起来非常简单.在没有进行任何定制的时候,你可以为表格选择两种基本风格,默认风格和分组风格: 在对表格中的单元格进行一点调整后,你就可以添加图标和说明文字: 你甚至能改变单元格的字体和颜色,然而,有时候这样还是不足够.如果你真的想

您当前的位置: 安全博客 > 技术研究 > 没有绝对安全的系统:写在AES 256破解之后

NULL 在理论上,理论和实践是一致的.在实践中,呵呵. --(应该是)爱因斯坦(说的) (INFO:本文中不会出现公式,请放心阅读) AES 256被破解了? 对于TLNR(Too Long, Not Read)的读者来说,先把答案放在这:是的,但也不尽然. 事件回顾如下:前几日在互联网上转发的一条题为"AES 256加密被破 一套1500元设备5分钟内搞定"的新闻引起了各界的关注.新闻在国内各大媒体转载,热门评论里不乏各种被高赞但实际上并不正确的说法:有说是字典攻击无线信号,和破解

Python中使用语句导入模块或包的机制研究_python

这篇文章讨论了Python的from <module> import *和from <package> import *,它们怎么执行以及为什么使用这种语法(也许)是一个坏主意.从一个模块导入全部 from <module> import * means意味着"我希望能访问<module>中我有权限访问的全部名称".例如以下代码something.py:   # something.py public_variable = 42 _pri

WPF基础到企业应用系列7深入剖析依赖属性(WPF/Silverlight核心)

一. 摘要 首先圣殿骑士很高兴这个系列能得到大家的关注和支持,这个系列从七月份开始到现在才第七篇,上一篇发布是在8月2日,掐指一算有二十多天没有继续更新了,最主要原因一来是想把它写好,二来是因为最近几个月在筹备"云计算之旅"系列,所以一再推迟了发布进度.之前一直都没有想过要录制视频,主要的原因还是怕自己知识有限,从而误导他人,所以前几次浪曦和51CTO邀请录制视频,我都以工作忙.公司内部培训需要时间和自己有待提高等理由委婉的拒绝了,说实在的,自己也知道自己还有很多地方有待提高,还需要向