it-swarm.cn

Mono通常被用来表示“是的,.NET是跨平台的”。该要求的有效性如何?

您在.NET和Java此时)之间为您的项目选择什么? 中,我说我会考虑“您将始终部署到Windows吗? “在一个新的Web项目中首先要做出的最重要的技术决定,如果答案是“否”,我建议Java而不是.NET。

一个非常普遍的反驳是“如果我们要在Linux/OS X /任何平台上运行,我们将只运行Mono”。1个,这在表面上是一个非常有说服力的论点,但出于几个原因,我不同意。

  • OpenJDK和所有供应商提供的JVM已通过官方的Sun TCK,以确保一切正常。我不知道Mono通过Microsoft TCK。
  • Mono落后于.NET版本。当前完全支持什么.NET级别?
  • 所有的GUI元素(WinForms?)在Mono中都能正常工作吗?
  • 企业可能不希望将开源框架作为官方计划B。

我知道,使用新的Java),未来是不安全的,但例如 IBM为许多平台提供了JDK ,包括Linux。开源的。

那么,在哪种情况下Mono是.NET应用程序的有效业务策略?


1个Mark H总结为 :“如果声称是”“我有一个用.NET编写的Windows应用程序,则应在mono上运行”,那不是一个有效的声明-但Mono已努力使这种应用程序的移植更加简单。”

171
user1249

Sparkie的答案 知道了,让我补充一下。

“ .NET是跨平台”的说法过于模棱两可,因为其最初创建的框架和世界都在发生变化和发展。

简短的答案是:

支持.NET及其衍生产品的基础引擎(通用语言基础结构标准)是跨平台的,就好像您要使代码进入多个平台一样您需要计划使用在正确的平台上使用正确的API,以在每个平台上提供最佳体验。

CLI系列尚未尝试“一次编写,可在任何地方运行”的方法,因为从电话到大型机的差异太大。取而代之的是,出现了特定于平台的API和运行时功能范围,以为开发人员提供正确的工具,以在每个平台上创建很棒的体验

想一想:程序员不再针对Windows PC或Unix服务器。从PC到游戏机,功能强大的手机,机顶盒,大型服务器和分布式机器集群,如今,当今世界比以往任何时候都更加吸引人。 在所有平台上都只能使用一个尺码的尺码在小型设备上只会感到,肿,而在大型系统上则感觉动力不足

微软的.NET Framework产品不是跨平台的,它只能在Windows上运行。 Microsoft的.NET Framework有所不同,它们可以在Windows Phone 7,XBox360和通过Silverlight的浏览器等其他系统上运行,但它们的配置文件都略有不同。

如今,您可以使用基于.NET的技术来针对所有主流主流操作系统,电话,移动设备,嵌入式系统和服务器。以下列表显示了在每种情况下都将使用哪种CLI实现(此列表并不全面,但应涵盖99%的情况):

  • 基于x86和x86-64的PC计算机:
    • 运行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。
    • 您为PS3,Wii或其他嵌入式系统运行嵌入式Mono。
    • 在XBox360上,您运行CompactFramework
  • S390,S390x,Itanium,SPARC计算机:
    • 您运行完整的单声道
  • 其他嵌入式操作系统:
    • 您使用移动配置文件运行.NET MicroFramework或Mono。

根据您的需求,上面的内容可能足够了。您几乎不会获得相同的源代码可以在任何地方运行。例如,XNA代码不会在每个桌面上运行,而.NET Desktop软件不会在XNA或手机上运行。通常,您需要对代码进行更改才能在.NET Framework的其他配置文件中运行。以下是一些我了解的配置文件:

  • .NET 4.0配置文件
  • Silverlight个人资料
  • Windows Phone 7配置文件
  • XBox360配置文件
  • Mono core配置文件-遵循.NET配置文件,可在Linux,MacOS X,Solaris,Windows和BSD上使用。
  • .NET Micro Framework
  • IPhone配置文件上的Mono
  • Mono on Android个人资料
  • PS3配置文件上的单声道
  • Wii个人资料上的Mono
  • 月光配置文件(与Silverlight兼容)
  • Moonlight扩展配置文件(Silverlight +完整的.NET 4 API访问权限)

因此,每个配置文件实际上都稍有不同,这不是一件坏事。每个配置文件旨在适合其主机平台,并公开有意义的API,并删除不合理的API。

例如,Silverlight用于控制主机浏览器的API在电话上没有意义。 XNA中的着色器在缺少对它的同等支持的PC硬件上毫无意义。

越早意识到.NET并不是将开发人员与硬件和本机平台的基础功能隔离开的解决方案,您的利益就会越多。

首先,一些API和堆栈可在多个平台上使用,例如ASP.NET可以在Windows,Linux,Solaris,MacOS X上使用,因为这些API在.NET和Mono上都存在。 ASP.NET在Microsoft某些受支持的平台(如XBox或Windows Phone 7)上不可用,在Mono支持的其他平台(如Wii或iPhone)上也不受支持。

以下信息仅在11月21日才是正确的,并且Mono世界中的许多情况可能会发生变化。

可以将相同的原理应用于其他堆栈,完整的列表将需要一个适当的表,我不知道如何在此处显示,但是这里列出了特定平台上可能不存在的技术。您可以假定这里没有列出的任何内容都可用(可以随时将我错过的内容发送给我):

核心运行时引擎[无处不在]

  • Reflection.Emit支持[除WP7,CF,Xbox,MonoTouch,PS3之外的所有地方]
  • CPU SIMD支持[Linux,BSD,Solaris,MacOS X;即将推出PS3,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]
  • 泛型[PS3和iPhone的某些限制]。

语言能力

  • C#4 [无处不在]
  • C#编译器即服务(Linux,MacOS,Solaris,BSD,Android)
  • IronRuby [无处不在,执行WP7,CF,Xbox,MonoTouch,PS3]
  • IronPython [无处不在,执行WP7,CF,Xbox,MonoTouch,PS3]
  • F#[无处不在,执行WP7,CF,Xbox,MonoTouch,PS3]

服务器堆栈

  • ASP.NET [Windows,Linux,MacOS,BSD,Solaris]
  • ADO.NET [无处不在]
  • LINQ to SQL [无处不在]
  • 实体框架[无处不在]
  • 核心XML堆栈[无处不在]
    • XML序列化(除WP7,CF,Xbox之外的所有地方)
  • LINQ to XML(无处不在)
  • System.Json [Silverlight,Linux,MacOS,MonoTouch,MonoDroid]
  • System.Messaging [Windows;在Linux,MacOS和Solaris上需要RabbitMQ]
  • .NET 1企业服务[仅Windows]
  • WCF [在Windows上完整; Silverlight,Solaris,MacOS,Linux,MonoTouch,MonoDroid上的一小部分]
  • Windows工作流程[仅Windows]
  • 卡空间标识(仅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)
  • 媒体中心API-仅Windows
  • 混乱(Windows和Linux)

图形库

  • GDI +(Windows,Linux,BSD,MacOS)
  • 石英(MacOS X,iPhone,iPad)
  • 开罗(Windows,Linux,BSD,MacOS,iPhone,iPad,MacOS X,PS3,Wii)

Mono库-跨平台,可以在.NET中使用,但需要手动构建

  • C#4编译器即服务
  • Cecil-CIL操纵,工作流,CIL仪表,链接器
  • RelaxNG库
  • Mono.Data。*数据库提供程序
  • 完整的System.Xaml(用于.NET不提供堆栈的安装程序)

MonoTouch表示Mono在iPhone上运行; MonoDroid表示Mono在Android上运行; PS3和Wii端口仅适用于Sony和Nintendo合格的开发人员。

对于缺乏手续性,我深表歉意。

195
miguel.de.icaza

首先,您需要区分公共语言基础结构(开放标准)和.NET(Microsoft对标准的实现)。 Mono是CLI的一种实现,从未宣称是“便携式.NET”。同样,C#语言是一种开放标准,并不严格地与.NET绑定。

我不知道Microsoft是否有任何工具可以验证实现是否合规,但是如果这样做,我很确定单身汉拥有并可以使用它。

Mono落后于.Net,但几乎没有。 Mono可以运行C#4.0代码(当前的.NET版本)。此外,微软最近已将所有DLR代码和库开源(根据Apache 2.0许可),这使Mono能够利用IronPython,IronRuby和F#等语言在上周才被开源。此外,Microsoft定期发布.NET中即将发布功能的CTP,这使Mono开发人员可以了解最新发行版本。

.NET中有许多工具和扩展,例如代码合同。这些并不总是完全在mono中实现。 (目前,我认为需要合同的部分合同验证器)。无论如何,它们都不是.NET应用程序中常用的,但是,如果它们的受欢迎程度增加,则在mono中实现它们的速度也会增加。

WinForms不(完全)可移植。它们是.NET特有的,不是CLI的一部分。 CLI没有指定任何特定的窗口小部件集。尽管有跨平台的小部件集(GTK#和Silverlight)。如果您从头开始编写应用程序时要考虑到可移植性,则可以使用其中一种而不是Winforms/WPF。此外,mono为Winforms API提供了一个瘦包装器-使现有的winforms应用程序可以更轻松地移植到GTK#中(而无需整个重写)。

Mono提供了一个Mono迁移分析器(MoMA)工具,该工具可以使用现有的.Net应用程序并告诉您其可移植性。 (例如,标识使用的不可移植库,P/Invokes等)。

对于不想依赖开源的企业,可以重新许可mono。添加到mono的代码的所有权被移交给Novell,Novell可以以通常的LGPL许可证(反过来几乎没有限制)以外的其他方式来对其进行许可。

因此,关于“ .NET是可移植的”的说法,如果您是从头开始编写代码并且知道该框架的可移植性问题,那么我认为这可能是一个有效的断言。如果声称“我有一个用.NET编写的Windows应用程序,则应在Mono上运行”,则不是这样,这不是有效的主张-但Mono努力使这种应用程序的移植更加简单。

115
Mark H

逐点:

  • OpenJDK和所有供应商提供的JVM已通过官方的Sun TCK,以确保一切正常。我不知道Mono已通过Microsoft TCK。
    Microsoft CLR符合一个规范。 Mono不是Microsoft CLR的克隆,而是相同规范的实现。一方面,这有可能导致更大的不兼容性。实际上,这对于单声道效果很好。
  • Mono落后于.NET版本。目前完全支持什么.NET级别?
    由于.Net的文档在实际发行版之前,因此mono实际上已经完成了对.Net 4的支持(不是beta版)之前 Microsoft正式发行版。此外,mono在记录不支持的内容方面做得非常好,并且它们具有一些可在现有项目上运行的工具,可帮助您发现潜在的不兼容之处。
  • 所有GUI元素(WinForms?)在Mono中都能正常工作吗?
    绝大多数winform都可以正常工作。 WPF,不是很多。我听说Java也是这样-许多高级小部件/ gui工具箱并非在所有平台上都得到很好的支持。
  • 企业可能不希望将开放源代码框架作为官方计划B。
    如果是这种情况,那么他们肯定不会使用Java,因为这样会使计划A的开源框架更高。

总而言之,如果您想构建一个跨平台的应用程序现在,从一开始就从mono开始并将其用作您的框架没有任何问题。如果愿意,您甚至可以在Windows上部署mono。

另一方面,如果您打算今天构建Windows应用程序,而您认为might将来需要在未知的地方跨平台,则您可能希望使用本机Windows小部件和工具。 .Net在这里比Java做得好得多,而在这种情况下,单声道是完全可以接受的。

换句话说:是的,.Net是跨平台的,对您的问题至关重要。不,mono不仅会开箱即用地运行每个.Net程序,但是您的问题是在一个新项目的上下文中。使新项目摆脱困境并避免兼容性问题并不需要太多工作,特别是如果您考虑针对Mono开发而不是针对.Net开发的话。

但最重要的是,我首先认为这是一个错误的问题。除非您是从头开始建立新的开发团队,否则您将从具有某个领域或另一个领域专业知识的程序员开始。通过与您的程序员已经知道的知识相结合,可以实现最佳结果。与构建跨平台应用程序似乎很重要,如果您的团队中只有.Java经验很少的.Net程序员,那么您就不可能解雇他们或让他们都学习Java用于您的下一个项目。如果您有一个由Java个程序员组成的团队,则不要让他们为仅Windows项目学习.Net。这些都不是疯子。

14
Joel Coehoorn

我曾与Mono合作过,我想说它与开源的,Microsoft不直接支持的替代平台一样好。如果您可以轻松使用Clojure或Scala之类的替代开源平台,则可以使用Mono感到满意。

Mono支持的.NET级别始终可以在 Mono路线图 页面上找到。

所有GUI元素都能正常工作吗?据我所知,它们确实可以,尽管我还没有详尽地尝试每个要素。

Mono是否与.NET相同?不,我怀疑这里和那里都将需要进行细微(可能是重大)调整。例如,您目前无法与其一起运行实体框架。

11
Robert Harvey

作为目标,.NET/mono宇宙移动非常快

每隔几年,Microsoft就围绕.NET的语言,运行时和基础结构进行一些引人注目的更改和创新。例如:泛型,LINQ,DLR,实体框架-随着Visual Studio的每个新修订版的发布,它所针对的框架的功能集和实用性通常都有相当大的提高。

尽管不断改进框架是值得欢迎的,但是如果您希望在多个平台之间实现兼容性,这也是一个问题。红帽企业Linux之类的长期支持平台在采用新技术方面进展缓慢,并且在任何给定的时间点,Mono平台都将在最近几个月内发生重大改进。因此,如果您想运行酷孩子们正在建设的东西,则必须从头开始编译Mono并管理自己的补丁程序和更新。那不酷。

另一方面,Java像小孩子库一样停滞不前。尤其是现在,它是由一家只想要Java的专利诉讼,可以肯定的是,在可预见的将来,语言或运行时将不会发生可检测的变化。Java与FORTRAN一样稳定。如果您希望使用任何一种改进,但是如果您要部署企业应用程序,还不错。

9
tylerl

从用户的角度来看,Mono致力于使Windows .NET应用程序与Linux兼容。如果您实际上尝试在Mono中运行任何编写得体的Windows应用程序,它将无法正常工作。

从打包者的角度(我曾经在PortableApps做过一些工作),. NET既是福也是祸。如果您仅在Windows上使用.NET,则部署会容易得多,因为更多的库意味着更少的系统相关内容(我相信,尤其是在Windows版本之间),但即使在Windows上,也会造成极大的混乱,因为.NET版本都不会倒退-compatible或转发兼容。您必须为不同的程序下载不同版本的.NET。

也就是说,Mono是使C#程序跨平台的一个很好的起点。只是不要将程序与最新的WINE打包在一起就可以了。看看Picasa的去向。

与这两种语言/平台的政治稳定性一样,RMS可能会开始争论Monol是由Novell领导的,Novell与Microsoft的蜜月期是众所周知的。这两个平台现在都可以认为在政治上是不稳定的。

如果您真的想要轻松的跨平台,那么经过实践检验的真正途径是QT,从目前来看,它在政治上是相当稳定的,这是a)LGPL的,b)几年前完成的主要许可发行,以及c)由诺基亚支持,该公司销售真正非常受欢迎的手机。

7
digitxp

Mono不是Microsoft .net的1:1端口。有一些Mono根本不会实施或没有计划实施的技术(例如,Workflow Foundation或 [〜#〜] wpf [〜#〜] ),另一方面,它们拥有Microsoft .NET不具备的某些技术,例如SIMD Extensions。

简短的答案:Mono和Microsoft .NET基于相同的基础基础-CIL和BCL-但是单独的项目。

4
Michael Stum

对原始帖子中的声明进行小评论。我将争辩说,TCK仍然是理论工具,允许Oracle声称Java是开放标准。因为如果您注意到,Apache Harmony几年来一直试图获得“ Java”认证,但未成功。显然,除了与它们相关的开源控制或多或少的控制(OpenJDK),Oracle确实对开放源代码实施不感兴趣。很像Mono,它并不完整(即,没有Java Web Start支持),并且缺少封闭源HotSpot实现中可用的一些优化。

可以这么说,截至2010年。 Java(大多数)是开源的,但不是开放标准,而.NET(大多数)不是开源的,而是开放标准。当然也有例外,DLR,IronPython,IronRuby和F#实际上是开源的。 Mono之所以有趣,是因为它提供了两全其美的开放标准的开源实现。

2
Casper Bang

撇开所有技术因素,在实际编写代码时会发生非常重要的部分。

与任何跨平台技术(Java,Python,Ruby ...)一样,如果编写代码时没有考虑可移植性,则应假定代码正常运行的机会基本上为零(即使这种机会是实际上要高得多),因为奇怪的不良行为可能非常关键。阅读:不要采用随机程序集并在Mono下运行它。

但是对于一个新项目(或一个您可以轻松重构的项目),选择.Net/Mono作为潜在的可移植运行时是有意义的,但是即使项目很早就在Mono上测试代码,也可以节省很多麻烦跨平台的变化很小。如果您使用连续集成服务器,则可以像设置Mono构建节点一样简单。只需养成一个习惯就可以解决许多问题(例如构建路径字符串),并且只需使用理智的做法和一些预见性,就可以在Mono上移植大量代码并进行单元测试。其余的(即单元测试失败)则是特定于平台的(例如使用PInvoke的代码),但应充分封装,以便能够为每个目标平台提供替代实现。这样,当项目最终被移植时,大部分工作几乎是免费完成的,其余部分将在及时开发。

当然,使用Mono中不可用的库(.Net)或不兼容的库(第三方)可以排除任何这种情况,但是在我的领域尚待观察。那就是我们在工作中实际使用的策略,在应用它时,我不用担心声称.Net + Mono是跨平台的。

1
Lloeki

诚实的答案是多种多样的。我已经看到小型Web服务器的东西从IIS)迁移到Apache,几乎没有困难地在mono下运行。我已经在Linux上成功使用Win Forms运行了不变的Windows .Net应用程序。

但是,尽管它可以工作,但是,如果您使用的不是在mono上实现的API调用,那么它将无法正常工作,唯一的解决方案是重写应用程序,坚持使用Windows或在mono中编写其他内容。

0
Michael Shaw