重温.NET下Assembly的加载过程

最近在工作中牵涉到了.NET下的一个古老的问题:Assembly的加载过程。虽然网上有很多文章介绍这部分内容,很多文章也是很久以前就已经出现了,但阅读之后发现,并没能解决我的问题,有些点写的不是特别详细,让人看完之后感觉还是云里雾里。最后,我决定重新复习一下这个经典而古老的问题,并将所得总结于此,然后会有一个实例对这个问题进行演示,希望能够帮助到大家。

.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,在此也就不多啰嗦了。

Assembly版本的重定向和最终确定

.NET下Assembly的加载过程,其实也是Assembly版本的确定和Assembly文件的定位过程,步骤如下:

  1. 在一个Assembly被编译的时候,它所引用的Assembly的全名(FullName)就会被编译器强行写入Assembly的Metadata,这个值是死的,从ILSpy可以看到,每个Reference都有它的全名信息:

    例如上图,System.Data依赖System.Xml,它所需要的版本是4.0.0.0,那么当CLR加载System.Data的时候,就可以暂且认为接下来需要加载的System.Xml版本是4.0.0.0。这里强调“暂且认为”,是因为这只是确定Assembly版本的第一步,那么最终System.Xml到底是不是使用4.0.0.0的版本呢?就需要看接下来这步的处理结果,也就是Assembly版本的重定向

  2. 首先,检查应用程序的配置文件,看是否存在Assembly版本重定向的设定。我们暂时先讨论应用程序配置文件就在AppDomain内的情况(如果在AppDomain之外,则需要首先下载配置文件,再继续,这里先不深入讨论)。应用程序配置文件常见的有.exe.config和web.config两种。在配置文件中,可以在runtime节点下的assemblyBinding中进行配置。例如:

    在这个例子中,asm6 Assembly的版本号被重定向到2.0.0.0。那么假设这就是asm6的最终版本号,那么接下来当CLR开始加载asm6的时候,如果2.0.0.0的版本没有找到,则直接抛出FileLoadException(即使3.0.0.0的版本是存在的),整个Assembly加载过程结束。FileLoadException的详细信息类似于:Could not load file or assembly 'asm6, Version=3.0.0.0, Culture=neutral, PublicKeyToken=c0305c36380ba429' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference

  3. 如果在配置文件中找到了对应的版本重定向设定,那么,再接着查看Publisher Policy文件。Publisher Policy文件是一个仅包含配置文件的.NET Assembly,被安装到GAC里。它的Assembly版本重定向配置内容跟上面的应用程序配置文件的配置内容相同,不同的是,它的作用域是所有使用了该Assembly的应用程序。这种做法对于开发系统级通用框架的Assembly升级非常有用,比如.NET Framework。下面就是安装在GAC里的Publisher Policy文件的样本,需要注意:Publisher Policy会override应用程序配置信息中的版本重定向配置,而不是相反。换言之,假如asm6在上面这一步被确定为2.0.0.0,而所对应的Publisher Policy文件又将其确定为2.5.0.0,那么,暂且认为,CLR应该要加载2.5.0.0的版本。同理,“暂且认为”这个词表示,版本确定的过程还未结束


  4. 接下来,查找machine.config文件。同理,如果machine.config文件中存在版本重定向的设定,那么就会使用machine.config文件中的这个值,作为CLR应该去加载的Assembly的版本

至此,Assembly的最终版本已被确定,接下来就是搜索Assembly文件并进行加载的过程了。

Assembly文件的搜索和加载过程

现在,CLR已经开始加载确定版本的Assembly了,接下来就是搜索Assembly文件的过程。这个过程也叫作Assembly Probing。CLR会做以下事情:

  1. 首先,查看所需的Assembly是否已经加载过,如果已经加载了,那就直接使用那个已经加载的Assembly的版本与当前所需的版本进行比对,如果匹配,则使用那个已经加载的Assembly,如果不匹配,则抛出FileLoadException,执行结束

  2. 然后,看Assembly是否已被强签名(Strongly Named),如果是,则去GAC里查找Assembly。如果找到,则直接加载,整个Assembly加载过程结束。如果没有找到,那么就进行下一步,继续搜索Assembly文件。当然,如果Assembly没有进行强签名,那么就跳过这一步,直接继续

  3. 接着,CLR开始搜索(Probing)可能的Assembly位置,这又要分多种情况:

    1. 首先,查看文件中是否有指定<codeBase>,codeBase配置允许应用程序针对Assembly的不同版本指定装载地址,遵循如下规律:

      1. 如果所指定的Assembly文件位于当前应用程序域的启动目录(或其子目录)下,则使用相对路径指定href的值

      2. 如果所指定的Assembly文件位于其它目录,或任何其它地方,则href必须给出全路径,并且Assembly必须强签名的

    2. 然后,CLR对应用程序域的根目录以及相关的子目录进行探索:

      1. 假设Assembly的名字是abc.dll,那么CLR会探索以下目录:

        1. [appdomain_base]\abc.dll

        2. [appdomain_base]\abc\abc.dll

      2. 假设abc.dll还有语言设置(culture不是neutral),那么CLR会探索以下目录:

        1. [appdomain_base]\[culture]\abc.dll

        2. [appdomain_base]\[culture]\abc\abc.dll

    3. 如果找到符合版本的Assembly,则加载,否则进入下一步

  4. 最后,CLR会查看应用程序配置文件中是否有<probling>节点,如果有,则按probling节点所指定的privatePath值进行逐一探索。这个过程也会考虑culture的因素,类似于上面这步这样,对相应的子目录进行搜索。如果找到对应的Assembly,则加载,否则抛出FileLoadException,整个加载过程结束。注意,这里“逐一探索”的过程,不是遍历并找最佳匹配的过程。CLR仅根据Assembly的名字(不带版本号的名字)在privatePath下查找Assembly的文件,找到第一个名字匹配但是版本不匹配的话,就抛异常并终止加载了,它不会继续搜索privatePath中余下的其它路径

在加载Assembly文件失败的时候,AppDomain会触发AssemblyResolve的事件,在这个事件的订阅函数中,允许客户程序自定义对加载失败的Assembly的处理方式,比如,可以通过Assembly.LoadFrom或者Assembly.LoadFile调用“手动地”将Assembly加载到AppDomain。

fuslogvw Assembly绑定日志查看器

在.NET SDK中带了一个fuslogvw.exe的应用程序,通过它可以查看详细的Assembly加载过程。使用方法非常简单,使用管理员身份启动Visual Studio 2017 Developer Command Prompt,然后在命令行输入fuslogvw.exe,即可启动日志查看器。启动之后,点击Settings按钮,以启用日志记录功能:

日志启动之后,点击Refresh按钮,然后启动你的.NET应用程序,就可以看到当前应用程序所依赖的Assembly的加载过程日志了:

接下来,我会做一个例子程序,然后使用这个工具来分析Assembly的加载过程。

插件系统的实现与Assembly加载过程的分析

理论结合实际,看看如何通过实际代码来诠释以上所述Assembly的加载过程。一个比较好的例子就是设计一个简单的插件系统,并通过观察系统加载插件的过程,来了解Assembly加载的来龙去脉。为了简单直观,我把这个插件系统称为PluginDemo。这个插件很简单,主体程序是一个控制台应用程序,然后我们实现两个插件:Earth和Mars,在不同的插件的Initialize方法中,会输出不同的字符串。

整个应用程序的项目结构如下:

该插件系统包含4个C#的项目:

  • PluginDemo.Common:它定义了AddIn抽象类,所有的插件实现都需要继承于这个抽象类。此外,AddInDefinition类是一个用来保存插件Metadata的类。为了演示,插件的Metadata仅仅包含插件类型的Assembly Qualified Name

  • PluginDemo.App:插件系统的应用程序。这个程序执行的时候,会扫描程序目录下Modules目录中的DLL,并根据module.xml的Metadata信息,加载相应的插件对象,并执行Initialize方法

  • PluginDemo.Plugins.Earth:其中的一个插件实现

  • PluginDemo.Plugins.Mars:另一个插件实现

注意:除了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的日志:

双击打开日志,可以看到如下信息:

从整个过程可以看出:

  1. PluginDemo.App.exe正在试图加载PluginDemo.Plugins.Mars Assembly

  2. PluginDemo.Plugins.Mars开始调用Newtonsoft.Json

  3. 扫描应用程序配置文件、Host配置文件以及machine.config文件,均无找到Newtonsoft.Json的重定向信息,此时,Newtonsoft.Json版本确定为6.0.0.0

  4. GAC扫描失败,继续查找文件

  5. 首先查找应用程序当前目录下有没有Newtonsoft.Json,以及Newtonsoft.Json子目录下有没有Newtonsoft.Json.dll,发现都没有,继续

  6. 然后,通过App.config中的probing的privatePath设定,首先查找Modules\Earth目录(因为这个目录放在privatePath的第一个),找到了一个叫做Newtonsoft.Json.dll的Assembly,于是,判断版本是否相同。结果,找到的是7.0.0.0,而它需要的却是6.0.0.0,版本不匹配,于是就抛出异常,退出程序

那么接下来,改一改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的版本确定和加载过程,最后给出了一个实例,对这个过程进行了演示。

原文:https://www.cnblogs.com/daxnet/p/8525249.html


.NET社区新闻,深度好文,欢迎访问公众号文章汇总 http://www.csharpkit.com

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/321984.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

jzoj3410-[GDOI2014模拟]Tree【最小生成树,贪心】

正题 题目大意 在一张图中选择一颗生成树使得边权的方差最小。 解题思路 我们很容易想到一种贪心&#xff0c;那就是在按照边权排好序后选择一段连续的区间然后使用这段区间构成最小生成树&#xff0c;这样时间复杂度是O(m3log⁡m)O(m^3\log m)O(m3logm)&#xff0c;时间复杂…

看eShopOnContainers学一个EventBus

最近在看微软eShopOnContainers 项目&#xff0c;看到事件总线觉得不错&#xff0c;和大家分享一下看完此文你将获得什么&#xff1f;eShop中是如何设计事件总线的实现一个InMemory事件总线eShop中是没有InMemory实现的&#xff0c;这算是一个小小小的挑战发布订阅模式发布订阅…

jzoj3682-Points and Segments【模型转化,欧拉回路】

正题 题目大意 给出若干个区间&#xff0c;然后给每个区间涂颜色(蓝或红)&#xff0c;求一种方案使得每个点的颜色数量差不超过111。 解题思路 我们可以从每个lll向rrr连一条双向边&#xff0c;若此时我们可以跑出欧拉回路&#xff0c;那么这就满足颜色差为0(从l∼rl\sim rl∼…

常用解题算法总结

一、四大基本算法 分治法 动态规划&#xff08;一次买卖股票、多次买卖股票、最大连续子序列和、最大连续子序列积、最长公共子序列&#xff09; 贪心算法 穷举法 二、常用便捷算法 异或法&#xff08;单次偶次数、顺序单次偶次数&#xff09; 位运算&#xff08;单次k次…

创建基于MailKit和MimeKit的.NET基础邮件服务

邮件服务是一般的系统都会拥有和需要的功能&#xff0c;但是对于.NET项目来说&#xff0c;邮件服务的创建和使用会较为的麻烦。.NET对于邮件功能提供了System.Net.Mail用于创建邮件服务&#xff0c;该基础服务提供邮件的基础操作&#xff0c;并且使用也较为的简单。对于真正将该…

欢乐纪中A组赛【2019.8.23】

前言 我好菜 成绩 %%%TRXdalao\%\%\% TRXdalao%%%TRXdalao RankRankRankPersonPersonPersonScoreScoreScoreAAABBBCCC888(H−2)TRX(H-2)TRX(H−2)TRX120120120202020100100100000121212(H−2)HJW(H-2)HJW(H−2)HJW100100100100100100000000181818(J−3)XXY(J-3)XXY(J−3)XXY80…

Java JVM总结

一、jvm参数 1&#xff09;内存 -Xms -Xmx -Xss -Xloggc:file -Xprof -XX:DisabledExplicitGC -XX:PreBlockSpin -XX:CompileThreshold 2&#xff09;Parallel -XX:SurvivorRatio -XX:PreTenureSizeThreshold -XX:MaxTenuringThreshold -XX:ParallelGCThreads -XX:Us…

EF Core下利用Mysql进行数据存储在并发访问下的数据同步问题

小故事在开始讲这篇文章之前&#xff0c;我们来说一个小故事&#xff0c;纯素虚构&#xff08;真实的存钱逻辑并非如此&#xff09;小刘发工资后&#xff0c;赶忙拿着现金去银行&#xff0c;准备把钱存起来&#xff0c;而与此同时&#xff0c;小刘的老婆刘嫂知道小刘的品性&…

牛客练习赛50-记录

正题 比赛链接:https://ac.nowcoder.com/acm/contest/1080#question 成绩 本届 升高二届 总结 以后还是不要写太多自己不擅长的写法&#xff0c;空间要多检查&#xff0c;不要像个傻逼一样啥都写错。 尽量不要为了省一点空间和时间写一些不舒服的东西&#xff0c;尽量在能…

物联网框架ServerSuperIO在.NetCore实现跨平台的实践路线

正所谓天下大势&#xff0c;不跟风不行。你不跨平台&#xff0c;很low嘛。java说&#xff1a;你们能跨嘛&#xff0c;跨给我看看。C#说&#xff1a;不要强人所难嘛。java说&#xff1a;能部署在云上吗&#xff1f;docker&#xff1f;微服务&#xff1f;C#说&#xff1a;不要强人…

Spring Aop总结

一、什么是AOP 面向方面的编程&#xff08;AOP&#xff09;是一种编程技术&#xff0c;是面向对象编程的补充&#xff0c;它也提供了模块化。 在面向对象编程中&#xff0c;关键的单元是对象&#xff0c;AOP的关键单元是切面&#xff0c;或者说关注点。一些切面可能有集中的代…

P3750-[六省联考2017]分手是祝愿【期望dp】

正题 题目链接:https://www.luogu.org/problem/P3750 题目大意 nnn盏灯和按钮&#xff0c;每次随机选择一个xxx按下后会让xxx的倍数的灯都取反&#xff0c;然后若最少kkk步就可以将所有灯关闭那么直接选择最优策略&#xff0c;求关闭所有灯的期望次数。 解题思路 做期望dpdpd…

使用WebApiClient请求和管理Restful Api

前言本篇文章的内容是WebApiClient应用说明篇&#xff0c;如果你没有了解过WebApiClient&#xff0c;可以先阅读以下相关文章&#xff1a;WebApi client 的面向切面编程我来给.Net设计一款HttpClient.Net45下HttpClient的几个缺陷.net的retrofit--WebApiClient库.net的retrofit…

Spring MVC总结

一、Spring MVC &#xff08;1&#xff09;介绍 Spring MVC是一个基于Java的实现了MVC设计模式的请求驱动类型的轻量级Web框架。 通过把Model&#xff0c;View&#xff0c;Controller分离&#xff0c;将web层进行职责解耦&#xff0c;把复杂的web应用分成逻辑清晰的几部分&…

拥抱.NET Core系列:MemoryCache 缓存选项

MSCache项目MSCache 目前最新的正式版是 2.0.0&#xff0c;预览版是2.1.0&#xff0c;会与 .NETCore 2.1 一起发布。本篇用了2.0.0版本开源在 GitHub 上&#xff0c;仓库地址是&#xff1a;https://github.com/aspnet/CachingNuGet地址为&#xff1a;https://www.nuget.org/pac…

牛客练习赛51-记录

正题 比赛链接:https://ac.nowcoder.com/acm/contest/1083#question 成绩 可怜的zycT3zycT3zycT3被n0n0n0卡了半天&#xff0c;这里感谢一下排雷 总结 比赛状态较好&#xff0c;后面没有T6T6T6的题解 T1:abcT1:abcT1:abc 题目大意 给出一个字符串&#xff0c;求有多少个abc…

SpringBoot总结

一、SpringBoot &#xff08;1&#xff09;简介 SpringFramework&#xff1a;最重要的特征是依赖注入。所有 SpringModules 不是依赖注入就是 IOC 控制反转。使用 DI 或者是 IOC 的时候&#xff0c;可以开发松耦合应用。松耦合应用的单元测试可以很容易的进行。 Spring MVC&…

Metrics.net + influxdb + grafana 构建WebAPI的自动化监控和预警

前言这次主要分享通过Metrics.net influxdb grafana 构建WebAPI的自动化监控和预警方案。通过执行耗时&#xff0c;定位哪些接口拖累了服务的性能&#xff1b;通过请求频次&#xff0c;设置适当的限流和熔断机制&#xff0c;拦截非法或不合理的请求&#xff0c;保障服务的可用…

jzoj6342-[NOIP2019模拟2019.9.7]Tiny Counting【树状数组,容斥】

正题 题目大意 一个序列SSS&#xff0c;求有多少个互不相同的4元组(a,b,c,d)(a,b,c,d)(a,b,c,d)使得a<b且Sa<Sba<b且S_a<S_ba<b且Sa​<Sb​ c<b且Sc>Sdc<b且S_c>S_dc<b且Sc​>Sd​ 解题思路 若可以重复其实答案就是逆序对个数乘上正序对…

jzoj6343-[NOIP2019模拟2019.9.7]Medium Counting【记忆化dfs,dp】

正题 题目大意 给出nnn个字符串SiS_iSi​&#xff0c;然后有些???号可以进行随便填字母。 然后要求Si<Si1S_i<S_{i1}Si​<Si1​的情况下求方案数。 解题思路 定义fl,r,p,cf_{l,r,p,c}fl,r,p,c​表示只考虑l∼rl\sim rl∼r的字符串&#xff0c;只考虑ppp往后的字…