到底应该选择哪种Linux.NET的部署方式？

当前部署Linux.NET环境的方式可谓是五花八门，既有传统的源码编译的方式、又有各式各样的一键安装脚本、还有绿色包安装方式，而随着Mono官方的新站上线，更增加了采用RPM包的部署方式。那对于一名Linux.NET的初学者来说，我们又该如何选择？下面，本文将对这几种的安装方式进行优缺点的比较，从而协助各位读者选择出最佳的部署方式。

本文中，我们将对下列的部署方式展开讨论：

1、源码编译

2、一键安装脚本

3、RPM包

4、绿色包 

一、源码编译

通过源代码编译安装部署Linux.NET可谓是最传统并且最原始可靠的方式，通过获取源代码，并在物理机（虚拟机）中进行编译，编译器能够有针对性的给机器编译出最适合改机器运行的二进制执行文件。同时，通过源代码编译的方式也是所有部署方式中最稳定靠谱的方式。同时，采用源码编译的方式部署也是最灵活的。要想深入学习的读者必须要掌握此方式部署。

想要通过源码编译的方式安装部署Linux.NET，我们需要事先Get到一份源代码，目前获得Mono源代码的方式主要分为两种，一种是通过GitHub将Mono的托管代码Pull下来执行autogen再执行make install的方式进行编译安装部署，另外一种则是通过Mono/Source所发行的源码包（tar.gz或者tar.bz2包）进行./Configuration再执行make install的方式编译。

事实上，如果读者们采用前者（也就是Git Pull的方式）来编译部署环境，所获取到的版本一般都会比从Mono/Source中发行的版本高（当然在能够编译的情况下），对希望能够尽快使用最高版本或者想尝鲜的读者，使用这种方式不失为一个好选择。但选择这个方式也有一定的缺点，那就是我们在编译之前需要先进行Git Clone或者Git Pull代码，这将使我们可能面临上G的Git代码仓库需要下载，同时由于Mono中的external目录下又包含了其他.NET项目的GIT仓库，执行autogen时，系统会检查包括external目录的代码是否完整，因此编译时系统也有可能再次的执行Git Pull拉去相关代码。另外还有一点，在我们进行Git Pull Master之后，我们也未必可以编译通过。所幸的是，文章发布之后，LexLi给予了一些提醒，通过他的思路，我们发现了其实GitHub/Mono的Readmd中是有一盏当前代码是否能够编译的“提示灯”，通过观察此“灯”所显示的颜色我们就可以知道当前的代码是否可以编译，另外在这里也有一个版本编译测试历史记录，我们也可以根据它的编译测试记录获知那一个提交版本的的源码是可以编译，然后只需把代码ReSet到此版本即可再次进行编译。

而采用Mono/Source所发行的源码包编译的读者，可靠性则大幅度提高，毕竟这个是Release版本。虽然当中有个别的发行包因为文件缺失无法编译，但是总得来说还是最可靠的，并且源码包发行版大小一般都在百兆以内，相比于Git仓库的上G代码可谓是小巧得多。

最后，各位读者无论是采用以上两种方式中的那种，都需要花费一段或漫长或短暂的编译等待时间，并且编译时可能会遇到一些Make Error的现象，这都需要各位读者自己进行克服处理。但无论怎么样，这还是对想深入学习Linux.NET的读者要求必须掌握的部署方式。（有需要的读者可以参详《Linux.NET学习手记》）

二、一键安装脚本

由于采用源码编译方式都是直接采用Shell命令来操作，因此有不少的人士将这些Shell命令提取出来重新组装成一个Shell脚本，只要执行该脚本即可完成环境的部署，其中更有爱好者别出心裁，在命令行的基础上加以改进，提供类似“界面”之流的方式，给予了较好的与用户的交互。采用脚本式部署环境是解放生产力的标志。

但即便如此，采用脚本安装的方式仍然存在着相当的不足，那便是采用脚本安装其实只是一个“礼盒”，“礼盒”里面的内容依然是源代码编译方式，因此，采用脚本安装所遇到的问题不会比采用源码安装的少。同时，采用脚本安装仍然存在这“兼容性”的问题，这里值得注意，所谓的“兼容性”并不是指脚本的命令行不通用，而是由源码编译所“继承”下来的“不兼容”，也就是环境的复杂性造成不同的Make Error所带来的“不兼容”。此外，由于每个人都有自己的安装风格，有的人可能喜欢将东西安装在“/usr”中（像宇内、善友的教程等），有人喜欢安装到“/usr/local/”中（我的风格，《Linux.NET学习手记》的教程路径），也有人喜欢安装到“/opt”中……总而言之，脚本中所编写的安装路径纯属由撰写者决定，安装目录可能并不是各位读者所希望的路径，这点也有一定的不足。

三、RPM包

伴随着Mono新版官网的上线，依赖于Yum的RPM安装方式也悄悄的出现在各位读者的视野，一段时间以来，不少朋友开始或是为了尝鲜（没办法，体验到Yum的甜头之后恐怕很难回头了）或是收到“官方”的指引纷纷采用了此种办法部署Linux.NET环境。

我没有尝试过这种方式（懒得自己添加镜像源），不过从不少朋友反（bao）馈（yuan）回（ma）来（niang）的信息来看，这种方式似乎是几种方法中最残（zi）念（sha）的了。由于RPM包隶属于二进制包的一种，安装路径已经在包中预配置，无法更改，我们也无法获知它到底安装到哪里（只能find了），从一些通过此方式安装的朋友所提供的资料来看，基本上会安装到“/opt”目录中（不过没有具体目录，有“/opt/”、“/opt/mono”甚至“/opt/201408xx/”目录）。此外，采用RPM包方式安装还有一项非常严重的问题，那就是采用此种方式安装竟然没有向环境变量注册Mono/bin路径，导致系统无法找到mono。

因此，我个人尤其不推荐此中安装方式。

四、绿色包（jws.mono）

以上三种方式都有一个共同的特点，那就是都需要在有网络条件的情况下进行。而绿色包与前者不同，绿色包是从使用源码编译好的机器中进行抽取重组并进行适当的修改变成新的解压即可运行的绿色版的Linux.NET运行环境。

使用绿色包具有以下的几项优点：

（1）、快速部署，由于采用此方式部署仅仅需要执行一条解压命令（有需要的可自行注册环境变量），没有编译过程，大大节省了因为环境部署所需要消耗的宝贵时间。

（2）、针对性强：由于每一款的绿色包都是针对其标注的Linux发行版进行编译，因此绿色包具有比较强的发行版针对性。

（3）、精致而不失功能：使用过绿色包的读者可能会发现，它的打包文件大小甚至会比Mono/Source所发行的源码包还会小，但功能却又没有减少。这个秘密就在于Mono与MS.NET不同，Mono的库是向下兼容的，因此，在每款的绿色包中，我们都会对“重复”的库进行剔除，让包变得足够精致。

但金无足赤，绿色包同样也面临一些问题，第一就是它无法升级（这项即将得到改善，在下个发行包中提供可用于升级的脚本），第二就是制作发行包是一项工作量大且耗时的活。我们需要对应编译并制作相应发行版的包。

不过对于初学者和需要快速部署、大规模部署的读者来说，绿色包还是最佳选择，因为它足够容易，因为它足够快。 

当然了，仁者见仁智者见智，以上观点乃我利用Linux.NET编译的时间写出的（已经失败了差不多十次）的主观观点和建议，不喜勿弹哈，谢谢。