Mono通常被用来表示“是的，.NET是跨平台的”。该要求的有效性如何？[关闭]

在此时，您将为.NET和Java之间的项目选择什么？我说我会考虑“您将始终部署到Windows吗？” 在新的Web项目中占据先机的最重要的技术决定，如果答案为“否”，我建议使用Java而不是.NET。

一个非常普遍的反论点是“如果我们要在Linux / OS X /任何平台上运行，我们将只运行Mono” ¹，这是表面上一个非常引人注目的论点，但我不同意原因。

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

我知道随着Oracle对Java的新管理，未来并不安全，但是例如IBM为许多平台（包括Linux）提供了JDK。他们只是不是开源的。

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

¹ _{Mark H总结为：“如果声称“我有一个用.NET编写的Windows应用程序，则应在mono上运行”，则不是，这不是有效的声明-但Mono已努力进行此类应用程序的移植更简单。”}

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
• Android个人资料上的Mono
• 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合格的开发人员。

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

首先，您需要区分公共语言基础结构（开放标准）和.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努力使这种应用程序的移植更加简单。

逐点：

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

总之，如果你想建立一个跨平台的应用程序，现在，没有什么错与单从一开始就启动和使用，作为您的框架。如果需要，您甚至可以在Windows上部署mono。

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

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

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

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

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

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

Mono是否与.NET相同？不。我怀疑这里到处都将需要进行细微（也许是主要）调整。例如，您目前无法与其一起运行实体框架。

作为目标，.NET / mono宇宙运行非常快。

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

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

另一方面，Java与小孩子池一样停滞不前。尤其是现在，它是由一家只希望用Java来解决专利诉讼的公司所拥有的，您可以肯定地说，在可预见的将来，语言或运行时将不会发生可检测的变化。Java与FORTRAN一样稳定。如果您希望进行任何形式的改进，那并不是很好，但是如果您尝试部署企业应用程序，那并不是那么糟糕。

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

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

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

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

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

Mono不是Microsoft .net的1：1端口。有Mono根本不会实现或没有计划这样做的技术（例如Workflow Foundation或WPF），而另一方面，它们拥有Microsoft .NET却没有的某些自身技术，例如SIMD Extensions 。

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

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

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

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

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

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

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

诚实的答案会有所不同。我已经看到小型Web服务器的内容从IIS移到了Apache，在单声道下运行几乎没有困难。我已经在Linux上成功使用Win Forms运行了未更改的Windows .Net应用程序。

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