和飞飞鱼一样，我也一直在向一些公司和个人推广Mono。不得不承认，现实世界中，人们一提到Mono，首先的需求就是把Microsoft .Net下的程序移植到Mono.Net。现实和人们的这个期望多少有些差距，虽然这个差距并不大。差距产生的原因是，Microsoft.Net和Mono.Net，并不是“同一个.Net”，它毕竟是“两套不同的.Net”。虽然这两套.Net之间绝大多数特性是可互相兼容、可互相移植的，但依然有一些特性，要么是Microsoft.Net具备而Mono.Net不具备，例如WPF；要么是Mono具备而Microsoft.Net不具备，例如Mono.Unix。要么是Microsoft.Net具备而Mono.Net正在努力追赶，例如WCF。（Mono官方明确表态，WCF是Mono打算去重点支持的，属于Core
Mono的范畴。）总之，必须让人们明白，这两套.Net，它们有各自不同的发展历史和轨迹，所幸的是对于绝大多数的.Net特性，更甚一点说是对于绝大多数C#特性，这两套.Net都提供了完美的支持。必须明白这一点，然后再谈如何去接受Mono这个新鲜事物。
我不知道你怎么样，反正我在明确了这些之后，依然是选择接受了Mono，而且一直在充满激情地充当一个不拿工资的Mono义务宣传员。
此文来自imono.cc上的讨论：http://www.imono.cc/Forums/Thread.aspx?thread=83&mid=38&pageid=20&ItemID=13&pagenumber=1#post274
我只有一次机会在公司的商业项目中应用了Mono（为了在这个项目里推动Mono的应用，我搜集了大量国外的Mono成功案例，也自己写了很多Demo供大家测试），但是那一次我们取得了辉煌的成功，该项目的成功将每年为公司带来上百万的营收。这个项目一开始只有3个程序员在这个项目里写程序，而且这3个人中还有1个人不是full time的。但是在这个项目之后，公司专门成立了一个新部门来继续发展和运营，使之成为一个long term的项目。（出于个人发展原因我已离开该公司）
公司高层甚至有人提出打算成立一家全资控股的新公司来专门发展这个项目。
之所以能够有机会应用Mono，来自于两个条件：
- 我们有明确的需求将产品同时部署在Windows和Linux平台；
- 我在这个项目中，承担了一部分关键的系统架构工作，并在实施阶段带领、主导了服务器端的开发工作。正式因为我有这样的主导权，才得以应用我所认可的Mono方案。
对于这个项目我写过一篇简短的介绍，但这个介绍里面的客户名称不是真的。出于商业利益方面的考虑，我故意用了假名称。不曾把这篇文章正式地放在博客上。以后整理一下我打算写一篇Mono工程实践类的文章，到那时再详细介绍这个项目（适当略去公司和客户的隐私）。
在我自己业余时间琢磨的一些事情上，我可能会尽可能地在Windows环境编写Microsoft.Net程序时尽可能兼容Mono，或者在Linux环境中编写Mono程序时尽可能兼容Microsoft.Net。
要做到这一点并不难，因为Mono已经为我们想到这一点了，它提供了一个兼容性检查工具：
MoMA - Mono Migration Analyzer
http://www.mono-framework.com/MoMA
有了这个工具，我们不仅可以方便地在开发软件之初就经常做兼容性检查，也可以在打算做Porting（无论from Microsoft.net to Mono还是from Mono to Microsoft.Net）时，对可行性做一个正确的评估。
有关兼容性，再多说一点：这个话题，往往和产品设计有关，不仅仅和Microsoft.Net、Mono有关。
对于Java程序的平台兼容性来说也是如此。虽然大家都知道Java是跨平台的，但越是大型的Java应用越不能真正做到跨平台。虽然Java语言本身以及它的虚拟机可以做到跨平台，但host Java程序的Web Server（WebLogic、Apache+Tomcat、Resin）存在平台差异，Java程序所调用的数据库存在平台差异，Java程序所采用的一些第三方类库、中间件更是存在平台差异。所以，实际项目中，那些大型的Java项目往往一开始决定用什么平台，就一直用什么平台，并不做跨平台这种事情。
对于Mono、Microsoft.Net来说亦是如此。
但如果真的有跨平台需求，那么在做架构的时候就要考虑到这一点。比如说原本我们可能用Windows平台上的SQL Server作为后台数据库，为了以后跨平台，就得用一个Windows、Linux都能运行的数据库，比如说Postgresql。（写本文时很高兴地看到Postgresql已经发布9.1
RC1版了。之前应用9.0.4的时候出过一个安装bug，后来我测试了一下9.1 beta 3，发现在9.1 beta 3里面已经fix了这个bug了。所以我对于9.1版本的正式发布是充满了期待的。）
现在已经有越来越多的第三方.Net类库申称其同时兼容Microsoft.Net和Mono。比如说Stack Service。
注：早在2001年就诞生的Mono，按理说已经不是一个新鲜事物了，但是直到今天了解它的人还不多，即使是一些从事.Net开发多年的开发者也未必了解它，所以我依然称它为“新鲜事物”。这里头有多种原因导致它依然是新鲜事物”。在Open Source、GNU、Linux的阵营中，不少人出于对Microsoft的排斥，进而排斥.Net。（这些人的一个显著特征就是在任何场合下拼写Microsoft的时候，必拼写为M$）另一方面，.Net阵营中的一些人也从来没有想过要把优秀的.Net/C#应用在非Windows平台，或者有这种需求的时候自然而然地就想到Java那里去了，也没有认真调研一下，到底.Net能不能运行在Linux上。其实只要大家屏弃一些技术领域中不应有的“宗教式的观念”，再多一些广闻博识，自然就会有强烈的愿望去了解Mono、接触Mono，进而喜欢上Mono。
后记
一、有读者阅读本文后留下了一些指导意见，比如
@cosmo_sei 希望在使用它之前获得一定的话语权。
[quote=cosmo_sei]使用它的第一步是获得话语权。[/quote]
不知您所指的“话语权”是怎样的话语权。这个问题或许关系到Mono的License？建议您阅读一下Mono官方主页上的License说明。
Mono的许可协议已经制定得非常宽松了，用户不仅可以自由地向Mono贡献代码、在遵循许可协议的前提下对Mono进行修改，还可以在商业产品中使用Mono。不知您还想要什么样的话语权？
二、还有一位 @lanzhengpeng2 提到用Native code写的代码如何在Mono/.Net中应用的问题。这位朋友不是对Mono不了解，而是对.Net本身不了解。.Net提供了非常强大的调用Native Code的能力（P/Invoke），Mono同样也在Linux、Unix平台具备这种能力。见以下链接：
Interop with Native Libraries
http://www.mono-project.com/Interop_with_Native_Libraries
另外对于C++/CLI的解决方案，Mono也有提供：http://www.mono-project.com/CPlusPlus
三、不明白为什么本文被“踩”了那么多次。。。当然作为读者您有自由表达意见的权利，可是这些“踩”的同学，能否在评论里面说一下你们的理由，到底哪里使你们感到不满了？有问题咱们可以共同探讨，基本上你们每一条评论我都会回。谢谢您的支持！