网友sparkie首先回应了上述问题：
首先，CLI（公共语言基础设施）和.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 将提供相应的实现。
WinForms 尚未完全移植，因为它们是 .NET 功能而不是 CLI 的一部分。 CLI 中没有定义特定的组件库。 有一些跨平台的组件库，例如 GTK# 和 Silverright。 如果您从编写应用程序之初就考虑可移植性，则不应使用 WinForm/WPF。 此外，Mono 提供了薄的封装层，以便现有的 WinForm 应用程序可以相对轻松地移植到 GTK#（无需完全重写）。
Mono提供了一个工具：Mono迁移分析器（MoMA），它可以检查.NET应用程序是否可以移植到Mono（例如，是否使用不可移植的类库，或P/Invoke）。
对于不愿意使用开源产品的商业应用程序.net 开发安卓游戏，Mono 可以使用另一种许可方案。 此时，Novell 负责 Mono 代码的所有权。 目前，许可方案不是 LGPL。
因此，如果您想考虑“.NET 是否可移植？”这个命题。 如果从一开始就考虑框架的可移植性，我认为确实如此。 但如果您说“我有一个用 .NET 开发的 Windows 应用程序，它应该在 Mono 上运行”，那是不正确的 - 但 Mono 使移植此类应用程序变得更加容易。
Lloeki 随后谈到了他的工作方法：
除了技术方面之外，关键在于你编写代码的方式。
无论是哪种跨平台应用程序（例如Java、Python、Ruby...），如果在编写代码时不考虑可移植性，那么你应该假设这些代码跨平台直接执行的可能性为零（即使实际上这种可能性要高得多）。 你不能仅仅获得一个程序集并保证它在 Mono 下正确执行。
但对于一个新的项目（或者一个你可以轻松重构的项目），选择.NET/Mono作为可移植的解决方案之一是明智的，但对于跨平台的代码.net 开发安卓游戏，你仍然需要不断地测试.NET/Mono。 如果您使用持续集成，只需创建一个 Mono 构建的节点即可。 只要养成良好的习惯（比如路径分隔符），很多问题在开发阶段就可以解决，而且大部分代码都可以通过使用单元测试等常见做法，再加上一点提前规划来解决。 获得出色的跨平台功能。 其余的，如平台相关的代码（如P/Invoke），可以进行封装，为不同平台提供有针对性的实现。 这样制作出来的项目几乎不需要额外的成本就能实现良好的可移植性。
当然，使用不存在或者与Mono不兼容的类库是另一回事3D角色，但我个人还没有遇到过这样的情况。 这些是我们在工作中实际使用的实践，我可以有把握地说“.NET+Mono”是一个跨平台的解决方案。
关于 Mono 对 .NET 功能的支持程度，Robert 和 Michael 谈到：
我使用过 Mono，我认为它与任何其他开源平台一样好，只是它不受 Microsoft 直接支持。 如果您可以接受 Clojure 或 Scala 等开源项目，那么 Mono 也会满足您。 有关 Mono 对 .NET 的支持，请参阅 Mono 路线图页面。 Mono 与 .NET 不同。 它们或多或少是不同的。 例如，您还不能使用实体框架。
Mono 不是 .NET 的端口。 有一些技术 Mono 没有或不打算实现（例如 Workflow Foundation 或 WPF）。 此外，他们还提供了 Microsoft .NET 之外的一些其他技术，例如 SIMD 扩展。 简单地说，Mono 和 Microsoft .NET 是基于相同基础（CIL 和 BCL）的两个不同项目。
在讨论中，Mono创始人Miguel de Icaza给出了最详细的回应：
“.NET 是跨平台的吗？” 这是一个模糊的说法，无论是框架本身还是整体环境都在不断变化。
简单来说，作为.NET的基础设施，CLI标准是跨平台的，但如果想在不同平台上获得最佳体验，就必须在各自平台上使用有针对性的API。 CLI技术家族从来没有尝试过“一次编写，随处执行”，就像手机和大型机之间的区别实在是太大了。 与其为不同平台提供统一的API和运行时，不如提供最正确的工具，以在各个平台上获得最佳体验。 想想那些不是 Windows PC 或 Unix 服务器的程序员，你要知道还有那么多令人兴奋的平台，比如游戏设备、手机、机顶盒、分布式集群等。
微软的.NET框架不是一个跨平台的产品，只能运行在Windows上。 其他系统上的 .NET Framework 有多种变体，例如 Windows Phone 7、XBox 360 和浏览器中的 Silverlight，它们的配置文件都略有不同。
如今，您可以在所有主要操作系统、电话、移动设备、嵌入式系统或服务器上使用基于 .NET 的技术。 以下是各种 CLI 实现的列表。 虽然不完整，但应该涵盖了99%。 健康）状况：
ARM 计算机： PowerPC 计算机： S390、S390x、Itanium、SPARC 计算机： 其他嵌入式操作系统：
有时很难在任何地方运行相同的代码。 例如，XNA 代码不会在每个桌面上运行，反之亦然。 为了在.NET的不同配置中运行，您需要修改一些代码。 以下是我所知道的一些配置：
上面的配置都有些不同，这并不是坏事。 每一种配置都是为了适应其平台而设计的，删除任何一种配置都是不明智的。 比如Silverlight API可以控制浏览器，与手机无关； 由于缺乏适当的支持，XNA 的着色功能在 PC 硬件上没有多大意义。 您越早认识到 .NET 不是将开发人员与特定硬件或平台联系在一起的解决方案，您就能越早成为更好的开发人员。
这意味着某些API或解决方案可以在多个平台上使用。 例如，ASP.NET可以在Windows、Linux、Solaris、MacOS X上使用，因为.NET和Mono都提供了这些API。 同时，ASP.NET无法在某些微软支持的平台上使用，例如XBox或Windows 7，也不支持Mono的Wii和iPhone配置。
其他解决方案的本质都是一样的。 这些技术的完整列表需要一个复杂的表格，我不知道如何在这里表示，但这里是特定技术和特定平台的列表：
核心运行时引擎（所有平台）：
语言：
服务器技术：
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。
图形用户界面技术：
图片库：
Mono类库——跨平台，可以在.NET中使用，但需要手动编译：
MonoTouch是在iPhone上运行的Mono，MonoDroid是在Android上运行的Mono。 PS3 和 Wii 端口仅适用于索尼和任天堂认证的开发人员。
Miguel de Icaza还在讨论中表示，IBM已经完成了至少两次针对AIX的Mono移植，但他们的移植团队没有获得反馈其结果的许可。
