Mono在企业界占有一席之地吗？

对于基于Windows的企业解决方案，.NET有时是最佳选择。那些必须使用Linux（或者更喜欢使用Linux）的企业如何看待Mono？假设开发人员没有问题，并且他们熟悉.NET / Mono和其他可能的竞争对手，例如Java。

一家中型/大型公司是否会在与Java之类的技术相反的服务器上运行Mono？你知道这样的公司吗？

我们在我工作的大公司中使用过它。从项目开始时我们就没有计划它，但它只是以这种方式解决了。

我们有一个用.NET开发的内部项目，一旦进入UAT，企业主便希望向某些客户以及内部人员开放该应用程序。我们大多数的外部（DMZ）服务器都是基于Linux的，而DMZ中的Windows服务器并不适合（太接近容量）。建议不要在Mono上运行该应用程序，而不是购买新硬件。我们花了几天的时间进行自己的测试，然后将应用发布给质量检查部门，然后发布给UAT。我们没有问题。

如果在项目开始时就已经获得了需求，那么我们可能没有选择在.NET中编写它，但这对于非常非常晚的需求更改而言是一个不错的结果。现在我们非常有信心，如果再次出现它，我们可以成功地部署到Mono（尽管我认为最终我们必须调整一些代码，但我认为我们很幸运）。

我没有在商业上使用过mono，但是我私下使用它，因为我在Windows公司工作，但私下是Linux用户（因此我可以重用我在工作中所做的工作）。

总的来说，我同意Miguel de Icaza的话：

• 25％的.NET应用程序可以单声道使用
• 可以使另外25％的工作时间在一天或更短的时间内
• 可以在一周内使另外25％的工作
• 最后25％要求完全重写应用程序（WinForms / COM）

单声道效果很好，但是存在一些问题：

• VB.NET仅支持.NET <= 2.0
• 未执行Windows身份验证
• WPF未实施
• WCF支持不完整
• 实体框架尚未实施，也没有实施计划
• 未实现“ ASP.NET Web部件”
• 不支持COM互操作
• 版本15.5（最新）的Sybase连接不起作用
• C＃类库中的错误和不完整性（例如XML在Mono <2.6中存在错误）
• Linux Web浏览器控件需要GTK＃

然后是小问题：

• Windows窗体可以工作，但并不总是能正确显示
• MonoDevelop无法设计Windows窗体
• MonoDevelop的“逐步调试”实际上没有用
• 5小时后单服务崩溃...

形成我能说的：

• WebServices功能出色
• 如果运行WebApplication，它将运行良好（如果不使用WebParts）。
• 如果您运行WindowsForms，它将看起来并不总是很好（至少可以说）。
• Microsoft Reporting Service没有等效的工作方式（FYIreporting是最接近它的东西，但是它速度慢，错误多端且非常不完整，并且自一年以来没有任何活动）
• 如果您需要创建Word或Excel文档，则会遇到问题。

如果要在Linux上开发.NET

• 您可以在那里开发ASP.NET（调试和逐步调试工作非常糟糕）
• 您不能在Linux上真正开发WinForms
• 您需要使用GTK＃代替WinForms

换一种说法：

• Mono在运行Web应用程序以及WebServices和MailServers中占有一席之地。
• 但是运行WindowsForms应用程序并不可行，您需要使用GTK＃编写应用程序
• 它缺少报告解决方案和MS文件格式支持（因此无法使用库）

编辑（2015年更新）：
我想补充一下，“逐步调试”功能非常出色，您可以使用MonoDevelop在Linux上开发Web应用程序，甚至具有nuGet依赖项。Excel和Word库的问题也消失了，实体框架现在是开源的。其余的几乎都是“按原样”（不知道单一服务是否固定，但我希望如此）。
还改善的是，您现在可以为发行版拥有最新的软件包，这意味着您无需等到Debian / Ubuntu的下一个发行版，就可以得到最新的Mono版本（而不必自己编译它们）。 ）。这是主要的时间安全措施。

另外，随着Roslyn的发布，VB.NET支持将在不久的将来变得更好。

我的公司开发了一个主要的-.NET桌面应用程序，并发布了在Mono上运行的Linux版本，因此我可以说，在基于Windows的企业级解决方案中肯定存在Mono。

我们将Mono与应用程序的安装打包在一起，而不需要用户单独安装（通过这种方式，我们也可以控制版本）。

我认为许多公司最关心的是Mono和Microsoft之间的许可问题。我的理解是，尽管Microsoft正式同意Mono可以使用核心.NET技术，但是在其他方面（包括非常常用的东西），在法律上更像是一个灰色地带，Microsoft在其上没有明确表示任何立场，或者其他。

显然，这很可能使他们下线索要许可费或只是起诉专利侵权。这两种可能性都不大可能发生在他们目前的行为方式上，但是大多数公司不喜欢这种不确定性，尤其是当它带有潜在的负债和成本时。

我认为Mono的空间不大：

Java已经在Linux上建立了平台，拥有庞大的社区以及大量的商业和开源企业质量库和工具。在启动针对Linux（或Mac）的新项目时，除非有特定情况，我认为没有任何理由在Java上选择Mono而不是Java（请参阅Walter的回答）。

在使用mono之前，我们必须确保程序中的路径字符串（使用Path.Combine（））或串行端口的“ COM”前缀（仅接受字符串而不是整数）都没有硬编码的“ \”。

什么有效：

• 控制台应用
• 网络应用

遇到的问题：

• WinForms不稳定：随机崩溃。
• 语言支持：社区可能不太了解每种语言，尤其是某些国家/城市的方言。可能会错过相应的语言环境/排序规则。
• 很少使用的方法可能与.NET具有不兼容的行为。
• xsp仅支持HTTP 1.0。当前它缺乏对HTTP 1.1的支持。
• 浏览器控件无法正常运行。

最好在内部使用Mono（例如ERP系统）作为受控环境。

如果您已经具有需要在跨平台环境中运行的.NET代码，则Mono是一个不错的选择。Mono在商业领域中被广泛使用，专门用于解决此问题。

我反对使用Mono的存在作为借口，以.NET启动项目，您知道这将是跨平台的。这是因为最新的.NET与Mono的开发速度之间存在滞后。

另一方面，如果您确实打算在将来的项目中使用Mono，则我要提醒您以Mono框架为目标并在.NET上作为次要替代方案运行，因为Mono主要是整个.NET功能的子集。