部署Linux.NET的4種方式

當前部署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的讀者要求必須掌握的部署方式。

二、一鍵安裝指令碼

由於採用原始碼編譯方式都是直接採用Shell命令來操作，因此有不少的人士將這些Shell命令提取出來重新組裝成一個Shell指令碼，只要執行該指令碼即可完成環境的部署，其中更有愛好者別出心裁，在命令列的基礎上加以改進，提供類似“介面”之流的方式，給予了較好的與使用者的互動。採用指令碼式部署環境是解放生產力的標誌。

但即便如此，採用指令碼安裝的方式仍然存在著相當的不足，那便是採用指令碼安裝其實只是一個“禮盒”，“禮盒”裡面的內容依然是原始碼編譯方式，因此，採用指令碼安裝所遇到的問題不會比採用原始碼安裝的少。同時，採用指令碼安裝仍然存在這“相容性”的問題，這裡值得注意，所謂的“相容性”並不是指指令碼的命令列不通用，而是由原始碼編譯所“繼承”下來的“不相容”，也就是環境的複雜性造成不同的Make Error所帶來的“不相容”。此外，由於每個人都有自己的安裝風格，有的人可能喜歡將東西安裝在“/usr”中（像宇內、善友的教程等），有人喜歡安裝到“/usr/local/”中，也有人喜歡安裝到“/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的庫是向下相容的，因此，在每款的綠色包中，我們都會對“重複”的庫進行剔除，讓包變得足夠精緻。

但金無足赤，綠色包同樣也面臨一些問題，第一就是它無法升級（這項即將得到改善，在下個發行包中提供可用於升級的指令碼），第二就是製作發行包是一項工作量大且耗時的活。我們需要對應編譯並製作相應發行版的包。

不過對於初學者和需要快速部署、大規模部署的讀者來說，綠色包還是最佳選擇，因為它足夠容易，因為它足夠快。