在前一篇文章中，我們簡略的介紹了jws.mono的安裝使用，以及我們如何自己動手做一個jws.mono出來。

在文章發表之後的幾天裡，我一直覺得有點不妥之處，直到後來猛然的意識到：我們自己動手做的jws.mono雖然可以見到info頁面，但實際上卻是無法掛載任何的.NET站點的。因此這也有必要寫下這篇的續篇來對前面的疏漏進行填補。

馬上進入本節主題，在本節中我們主要講述：

　　（1）、分析jws.mono的組成及相關元件的作用

　　（2）、此mono非彼mono：bin目錄詳解

1、jws.mono組成及介紹

總的來說，jws.mono包含了兩個部分，jexus以及提供它執行環境的mono。下面是“jws.mono.tar.gz”解壓之後的組成（注：本篇文章針對的是

直接開始分析吧，如上圖所示，jws.mono的根目錄包含了四個目錄，它們的作用分別是：

　　bin：包含Mono編譯器的可執行檔案目錄

　　etc：包含.NET預設配置檔案的目錄（machine.config等）

　　jexus：顧名思義，放jexus的目錄

　　lib：裡面包含了.NET的程式集、我們編譯mono和libgdiplus所得到的so庫檔案

目錄以及結構大概就是這樣，各位讀者分別點選進入相關的目錄之後定會眼前一種熟悉的感覺。

2、bin目錄詳解

點選進入到bin目錄：

各位讀者如果對比自己手上編譯得出的mono/bin目錄，這裡的bin目錄就顯得輕量多了，是的，此處的bin目錄是經過裁剪，僅僅包含了提供.NET執行所需的核心元件，並沒有其他更多的東西。出了mono-sgen，其餘均有指令碼組成，而dmcs、gmcs以及mcs分別供給FramWork版本為4.0、2.0（3.5）以及4.5的程式的程式呼叫。

使用VIM開啟其中一個指令碼檔案：

 這裡面僅包含了一條命令，命令的作用是呼叫同級目錄下的mono，並指定它的framework版本。

回到檔案目錄中，我們再仔細觀察一下檔案“mono”的大小（有興趣的讀者可以看看自己編譯的Linux.NET中可執行檔案“mono”的大小，相差甚大），大小隻有1KB，顯然這個叫“mono”的檔案絕不會是編譯器“mono”，只是一個同名的檔案而已。
我在前文中曾說過，出了mono-sgen以外，其餘的均是指令碼檔案，因此我們仍然可以繼續用Vim開啟它：

 到了這裡，我們已經一目瞭然了，這個“mono”檔案的作用其實就是先設定並載入與Linux.NET執行相關的資原始檔（程式集檔案、machine.config等），然後把處理交給了“mono-sgen”處理（提示：mono-sgen裡面包含了mono的JIT以及Sgen垃圾回收等元件，好東西）。

這一個檔案很重要，我們所有的.NET程式的執行都要經過這一個檔案，因此如果這個檔案裡面的引數（目錄之類的）有任何的差錯，都會導致我們的.NET程式無法編譯執行。

再留意“--runtime”這裡，在此處，無論你使用的是那個版本的framework庫，其實在jws.mono執行時都是使用framework 4.0（事實上目前流行的CLR主要有2.0和4.0兩個版本，而在mono中CLR 4.0是可以相容CLR 2.0的庫，MS.NET則不行）。

回到起點，開篇的時候，我提到的那個問題，各位讀者現在知道是什麼原因造成的了嗎？