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

Question

当前部署 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 编译的时间写出的（已经失败了差不多十次）的主观观点和建议，不喜勿弹哈，谢谢。