最近在工作中牵涉到了.NET下的一个古老的问题:Assembly的加载过程。虽然网上有很多文章介绍这部分内容,很多文章也是很久以前就已经出现了,但阅读之后发现,并没能解决我的问题,有些点写的不是特别详细,让人看完之后感觉还是云里雾里。最后,我决定重新复习一下这个经典而古老的问题,并将所得总结于此,然后会有一个实例对这个问题进行演示,希望能够帮助到大家。
.NET下Assembly的加载,最主要的一步就是确定Assembly的版本。在.NET下,托管的DLL和EXE都称之为Assembly,Assembly由AssemblyName来唯一标识,AssemblyName也就是大家所熟悉的Assembly.FullName,它是由五部分:名称、版本、语言、公钥Token、处理器架构组成的,这一点相信大家都知道。有关Assembly Name的详细描述,请参考:https://docs.microsoft.com/en-us/dotnet/framework/app-domains/assembly-names。那么版本,就是AssemblyName中的一个重要组成部分。其它四部分相同,版本如果不同的话,就不能算作是同一个Assembly。设计这样一个Assembly的版本策略,微软本身就是为了解决最开始的DLL Hell的问题,在维基百科上着关于这段黑历史的详细描述,地址是:https://en.wikipedia.org/wiki/DLL_Hell,在此也就不多啰嗦了。
.NET下Assembly的加载过程,其实也是Assembly版本的确定和Assembly文件的定位过程,步骤如下:
至此,Assembly的最终版本已被确定,接下来就是搜索Assembly文件并进行加载的过程了。
现在,CLR已经开始加载确定版本的Assembly了,接下来就是搜索Assembly文件的过程。这个过程也叫作Assembly Probing。CLR会做以下事情:
在加载Assembly文件失败的时候,AppDomain会触发AssemblyResolve的事件,在这个事件的订阅函数中,允许客户程序自定义对加载失败的Assembly的处理方式,比如,可以通过Assembly.LoadFrom或者Assembly.LoadFile调用“手动地”将Assembly加载到AppDomain。
在.NET SDK中带了一个fuslogvw.exe的应用程序,通过它可以查看详细的Assembly加载过程。使用方法非常简单,使用管理员身份启动Visual Studio 2017 Developer Command Prompt,然后在命令行输入fuslogvw.exe,即可启动日志查看器。启动之后,点击Settings按钮,以启用日志记录功能:
日志启动之后,点击Refresh按钮,然后启动你的.NET应用程序,就可以看到当前应用程序所依赖的Assembly的加载过程日志了:
接下来,我会做一个例子程序,然后使用这个工具来分析Assembly的加载过程。
理论结合实际,看看如何通过实际代码来诠释以上所述Assembly的加载过程。一个比较好的例子就是设计一个简单的插件系统,并通过观察系统加载插件的过程,来了解Assembly加载的来龙去脉。为了简单直观,我把这个插件系统称为PluginDemo。这个插件很简单,主体程序是一个控制台应用程序,然后我们实现两个插件:Earth和Mars,在不同的插件的Initialize方法中,会输出不同的字符串。
整个应用程序的项目结构如下:
该插件系统包含4个C#的项目:
注意:除了PluginDemo.Common之外的其它三个项目,都对PluginDemo.Common有引用关系。而PluginDemo.App项目仅仅在项目本身依赖于PluginDemo.Plugins.Earth和PluginDemo.Plugins.Mars,它不会去引用这两个项目。目的就是为了当PluginDemo.App被编译时,其余两个插件项目也会同时被编译并输出到指定位置。
在Earth插件的CustomAddIn类中,我们实现了Initialize方法,并在此输出一个字符串:
public class CustomAddIn : AddIn { public override string Name => "Earth AddIn"; public override void Initialize() { Console.WriteLine("Earth Plugin initialized."); } }
在Mars插件的CustomAddIn类中,我们也实现了Initialize方法,并在此输出一个字符串:
public class CustomAddIn : AddIn { public override string Name => "Mars AddIn"; public override void Initialize() { Console.WriteLine("Mars AddIn initialized."); } }
那么,在插件系统主程序中,就会扫描Modules子目录下的module.xml文件,然后解析每个module.xml文件获得每个插件类的Assembly Qualified Name,然后通过Type.GetType方法获得插件类,进而创建实例、调用Initialize方法。代码如下:
static void Main() { var directory = new DirectoryInfo("Modules"); foreach(var file in directory.EnumerateFiles("module.xml", SearchOption.AllDirectories)) { var addinDefinition = AddInDefinition.ReadFromFile(file.FullName); var addInType = Type.GetType(addinDefinition.FullName); var addIn = (AddIn)Activator.CreateInstance(addInType); Console.WriteLine($"{addIn.Id} - {addIn.Name}"); addIn.Initialize(); } }
接下来,修改App.config文件,修改为:
<?xml version="1.0" encoding="utf-8" ?> <configuration> <runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <probing privatePath="Modules\Earth;Modules\Mars;" /> </assemblyBinding> </runtime> </configuration>
此时,运行程序,可以得到:
目前没有什么问题。接下来,对两个AddIn分别做一些修改。让这两个AddIn依赖于不同版本的Newtonsoft.Json,比如,Earth依赖于7.0.0.0的版本,Mars依赖于6.0.0.0的版本,然后分别修改两个CustomAddIn的Initialize方法,在方法中各自调用一次JsonConvert.SerializeObject方法,以触发Newtonsoft.Json这个Assembly的加载。此时再次运行程序,你将看到下面的异常:
现在,刷新fuslogvw.exe,找到Newtonsoft.Json的日志:
双击打开日志,可以看到如下信息:
从整个过程可以看出:
那么接下来,改一改App.config文件,将privatePath下的两个值换个位置呢?
再试试:
此时,Earth AddIn又出错了。那么,我们加上版本重定向的配置,指定当程序需要加载7.0.0.0版本的Newtonsoft.Json时,让它重定向到6.0.0.0的版本:
再次执行,成功了:
看看日志:
版本已经被重定向到6.0.0.0,并且在Mars目录下找到了6.0.0.0的Newtonsoft.Json,加载成功了。
这个案例的源代码可以。
本文详细介绍了.NET下Assembly的版本确定和加载过程,最后给出了一个实例,对这个过程进行了演示。
如对本文有疑问, 点击进行留言回复!!
网友评论