标签：
.NET运行机制
1 .NET程序被编译成什么形式的代码
2 JIT是如何工作的
3 简述程序集的加载机制
4 如何配置程序集的版本策略
.NET程序在编写完成后，会经过第一次编译。对于C#而言，无论是VS IDE还是其他任何间接方式，本质上都是执行编译器cse.exe来编译C#代码。在这次编译之后，程序会被编译成中间代码（IL），并且所有必须的元数据和程序集会被一起打包加载到文件头上。编译后的文件是一个标准的PE/COFF应用文件，该文件的最开始的部分包含了PE/COFF头。紧接着，就是.NET特有的头部信息，其中包括程序集版本号、文件名和模块版本号，也包含一些诸如强签名等可选项，这部分内容通常称为CLR头。CLR头之后就是文件的元数据，元数据包含了所有类型的定义、所有的引用以及程序集的清单。再之后，就是中间代码IL。
用.NET自带的ILDasm工具可以查看元数据和IL代码。在VS的命令窗口输入：
ILDasm xxx.exe
中间代码的形式上有点类似于汇编语言，但它是无法被直接运行的。在CLR运行程序集的时候，根据需要会对IL代码进行二次编译，这个过程称为即时编译（JIT，Just in time）。即时编译概念上更加符合传统意义上的编译，CLR会查看元数据来判断要加载那些中间代码，并且实时地对需要的程序集的中间代码进行编译，而这次编译的结果就是最终在CLR上可以执行的机器码。
即时编译是最常见的执行方法，但并不是唯一一种。.NET 提供了另外一种部署方法，即在部署的时候就立即编译中间代码来生成机器码，并存储在缓存中，当CLR需要加载该程序集时，就可直接加载已经编译好的机器码。但无论如何，第二次编译的本质是不变的。
.NET程序在第一次编译后，形成CLR头、元数据和中间代码。在实施运行和部署时，将经过二次编译，编译的结果是在CLR中可执行的机器代码。
在编译IL代码时，.NET提供了两种可选方式：
CLR的加载顺序，当CLR需要执行某个方法时，本地缓存，并且确定本地缓存是最新的版本。如果缓存的版本不是最新的，CLR将忽略缓存的机器代码而去寻找最新版本的中间代码。另外，如果CLR没有发现任何缓存代码，也会去寻找适合的中间代码并且用实时编译（JIT）的方式来编译中间代码。
实时编译不仅需要编译被调用的方法，并且需要编译或在本地缓存中寻找所有被该方法使用的类型。
在实时编译过程中，JIT引擎会查找一个包含该类型所有方法存根的数据结构，对于未编译成机器代码的方法，存根会包含一个调用JIT的简单命令，当该方法的实时编译结束后，存根的命令会被替换成一条简单的Jmp指令，使得代码跳转到该方法的机器代码位置。
在实际环境下，不同类型的方法JIT的原理机制是有所不同的，例如虚方法、委托方法、抽象方法等。
JIT引擎在编译中间代码之前，会寻找方法的本机机器代码缓存并且判断其是否可用，如果可用则直接加载，如果不可用，JIT引擎会查找类型中的方法存根，找到该中间代码并且进行编译。
1．程序集的主动加载方式
程序集的加载可以完全忽略任何策略，而由程序员在程序中显式地通过位置进行加载。System.Reflection.Assembly.LoadFrom（string assemblyfile）就提供了这样的功能。这个方法接受一个CODEBASE风格的字符串，用以指定要加载的程序集的位置。
CODEBASE是.NET中指定路径的一种方式，其值记录了模块所在的位置，可以是一个URL，也可以通过file://来指定到本地位置。
using System; using System.Collections.Generic; using System.Text; using System.Reflection; namespace NET.MST.Second { class LoadFrom { static void Main(string[] args) { //需要针对不同的主机目录结构进行修改 String codebase = @"..\..\..\..\2-4 Compile\Compile\Compile.dll"; //从指定位置加载程序集 Assembly compiledll = Assembly.LoadFrom(codebase); //创建对象 Object compile = compiledll.CreateInstance("NET.MST.Second.Compile"); Console.WriteLine(compile); Console.Read(); } } }
在代码中，程序主动加载了位于Compile程序集目录下的Compile.dll。然后通过CreateInstance方法创建了一个Compile的类型。注意这里调用的是无参数的构造方法。
通过位置加载程序集确实非常方便，但它却带有以下一些弊端：
2．通过名称、版本、文化和公钥来加载程序集
除了通过位置来加载程序集，.NET也提供了通过程序集的名称、版本、文化和公钥来加载程序集的机制。首先要做的事是通过这四个元素来找到唯一的程序集。
当一个程序集被按照名称、版本、文化和公钥来加载时，首先会被应用版本策略来确定所有能够胜任的版本，接着CLR会在CODEBASE指定的位置进行寻找，如果失败则接着在应用程序域目录下进行寻找，然后会在应用程序目录下进行寻找，最后把得到的程序集传递给加载器，进行加载和编译。
图中的应用程序域目录是指AppDomain.BaseDirectory返回的目录，而应用程序目录是指包含了应用程序配置文件的目录。
CLR提供了程序接口，允许程序员主动地按照程序集的名称、版本、文化和公钥来加载程序集。System.Reflection.Assembly.Load方法就是这个接口。
using System; using System.Collections.Generic; using System.Text; using System.Reflection; namespace Load { class Load { static void Main(string[] args) { //需要针对不同的主机安装情况进行修改 String assemblyname = @"Compile, " + "Version=0.0.0.0, " + "Culture=Neutral, " + "PublicKeyToken=60c29e5f0af3e9bb"; //根据程序集的四要素加载程序集 Assembly compiledll = Assembly.Load(assemblyname); //创建对象 Object compile = compiledll.CreateInstance ("NET.MST.Second.Compile"); Console.WriteLine(compile); Console.Read(); } } }
CLR通过System.Reflection.Assembly.LoadFrom和System.Reflection.Assemblty.Load来主动地加载程序集。前者通过位置而后者则通过唯一标识强命名程序集的4个元素来标识程序集。CLR的加载机制和Load方法一致，其内在策略是依次通过版本策略、CODEBASE位置、应用程序域位置和应用程序位置来查找程序集。
当一个程序集通过名字、版本、文化和公钥进行加载时，CLR允许程序员指定该程序集的哪些版本可以代替目前版本进行加载。这些都是通过版本策略来实现的。所谓的版本策略，就是一个程序集版本的重定向，把加载当前这个版本定向到加载可替代的版本。版本策略可以在以下三个级别上进行配置：
这三个级别的版本策略都可以通过XML文件来进行配置。
1．应用程序策略
应用程序策略可以在应用程序配置文件中进行配置，应用程序配置文件位于应用程序目录下。对于.EXE应用程序，其配置文件由exe文件名加上.config后缀名构成，例如一个test.exe的应用程序，其配置文件就是test.exe.config。而对于任何一个Web应用程序来说，其配置文件的文件名都是web.config。
版本策略都记录在配置文件的assemblyBinding节点下。如下代码是一个应用程序的配置文件例子，这里只选取了本节所关心的版本策略部分内容。
Web.Config
<?xml version="1.0"?> <configuration> <runtime> <assemblyBinding> <!--对这个程序集进行版本重定向--> <dependentAssembly> <assemblyIdentity name="NET.MST.Second.Compile" publicKeyToken="60c29e5f0af3e9bb"> </assemblyIdentity> </dependentAssembly> <!--重定向的策略--> <bindingRedirect oldversion="0.0.0.0-12.2.2.2" newversion="12.3.0.0"> </bindingRedirect> </assemblyBinding> </runtime> </configuration>
在这个配置文件中，指定了NET.MST.Second.Compile，60c29e5f0af3e9bb这个组件的版本策略，这个策略将0.0.0.0到12.2.2.2之间的所有版本重定向到12.3.0.0版本上。
2．发行者策略
发行者策略是针对那些被放入全局程序集缓存（GAC）中的程序集。发行者策略配置文件的文件名非常古怪，它是这样的一个字符串：主版本号.次版本号.程序集名.dll。正因为如此，一个程序集的每个主版本/次版本号只能有一个发行者策略。
3．计算机策略
同样地，计算机策略同样由一个配置文件表示，它的格式也和代码2-7基本类似。计算机级版本策略配置文件的文件名为：machine.config，它被存储在%SystemRoot%\ Microsoft.NET\ Framework\v****\CONFIG\目录下。
读到这里，读者可能会有这样的疑问：版本策略可以在3个级别进行配置，那这些策略是如何协作的呢？按照.NET的机制，3个级别的版本策略将会按照顺序依次执行，而上一级别的执行结果将会被作为下一级别的执行输入。
如图，3个级别版本策略被依照：应用程序、发行者、计算机的顺序依次执行。而其中，发行者策略是可选的，在以下两种情况下发行者策略将不会被执行。
在第一种情况下，根本就不存在发行者策略配置文件，当然CLR也就不会执行发行者策略。而第二种情况，是程序员在应用程序策略中指定忽略发行者策略，具体做法是在应用程序配置文件中加入publisherPolicy节点，并且把apply属性值设置为no。
Web.Config
<?xml version="1.0"?> <configuration> <runtime> <assemblyBinding> <!--对这个程序集进行版本重定向--> <dependentAssembly> <assemblyIdentity name="NET.MST.Second.Compile" publicKeyToken="60c29e5f0af3e9bb"> </assemblyIdentity> </dependentAssembly> <!--重定向的策略--> <bindingRedirect oldversion="0.0.0.0-12.2.2.2" newversion="12.3.0.0"> </bindingRedirect> <!--指定忽略发行者策略--> <publisherPolicy apply="no"> </publisherPolicy> </assemblyBinding> </runtime> </configuration>
CLR支持在3个级别上设定版本策略，依次是：应用程序策略、发行者策略和计算机策略。所有策略的设置都是通过修改配置文件来实现。3个级别的策略依次会被CLR执行，而上一个策略的执行结果将被作为下一个策略的输入。发行者策略仅仅针对那些放入GAC的程序集，并且可以在应用程序策略中被指定忽略。
转载请注明出处：
作者：JesseLZJ
出处：http://jesselzj.cnblogs.com
标签：
原文地址：http://www.cnblogs.com/jesselzj/p/4782183.html
