已经迁到自己的博客,有兴趣的读者请移步到(http://jhonge.net),谢谢各位支持。

绿色版的Linux.NET——“Jws.Mono”(续)

前一篇文章中,我们简略的介绍了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,其他的可能结构不一样):

直接开始分析吧,如上图所示,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则不行)。


回到起点,开篇的时候,我提到的那个问题,各位读者现在知道是什么原因造成的了吗?

posted @ 2014-07-12 18:19 小蝶惊鸿 阅读(...) 评论(...) 编辑 收藏