net core手动加载dll,无法自动加载其依赖项

用的net core版本是2.1,也许在后续的版本中已经修复了这个问题

今天在尝试用net core写demo的时候,发现了这个问题。因为都是使用DI,所以就没有我的网站项目里直接引用一些实现类库,而是放到了同一个目录下,在网站启动的时候用代码去加载进来。然而在实际的运行过程成中发现,指定的dll会自动加载,但是其依赖的nuget包里的dll不会被加载进来,在Google了很久,也发现了很多人提出过这个问题,在GitHub上也有人提过https://github.com/dotnet/corefx/issues/21982,但是都没有直接的解决方案,其中有一个差不多的解决方案https://www.codeproject.com/Articles/1194332/Resolving-Assemblies-in-NET-Core,我的解决方案也是依据这个改进而来的。

代码的核心思路是去找需要手动加载的DLL的依赖项,尝试去找到该依赖项所在的位置,然后再加载进来。详细代码如下:

using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.DependencyModel;
using Microsoft.Extensions.DependencyModel.Resolution;
using System;
using System.Collections.Concurrent;
using System.Collections.Generic;
using System.Linq;
using System.Reflection;
using System.Runtime.Loader;
using ZRB.Blog.Configurations;

namespace ZRB.Blog.Injection
{
    public static class AssemblyLoader
    {
        private static readonly ICompilationAssemblyResolver AssemblyResolver;
        private static readonly ConcurrentDictionary<string, CompilationLibrary> DependencyDLL;

        static AssemblyLoader()
        {
            AssemblyLoadContext.Default.Resolving += Default_Resolving;
            AssemblyResolver = new CompositeCompilationAssemblyResolver(
                new ICompilationAssemblyResolver[]{
                    new AppBaseCompilationAssemblyResolver(AppDomain.CurrentDomain.BaseDirectory),
                    new ReferenceAssemblyPathResolver(),
                    new PackageCompilationAssemblyResolver()
                });
            DependencyDLL = new ConcurrentDictionary<string, CompilationLibrary>();
        }

        private static Assembly Default_Resolving(AssemblyLoadContext assemblyLoadContext, AssemblyName assemblyName)
        {
            if(DependencyDLL.ContainsKey(assemblyName.Name))
            {
                var compilationLibrary = DependencyDLL[assemblyName.Name];
                var assemblies = new List<string>();
                if (AssemblyResolver.TryResolveAssemblyPaths(compilationLibrary, assemblies) && assemblies.Count > 0)
                {
                    var assembly = assemblyLoadContext.LoadFromAssemblyPath(assemblies[0]);
                    FindDependency(assembly);
                    return assembly;
                }
            }
            return null;

        }

        public static Assembly GetAssembly(string assemblyName)
        {
            string assemblyFileName = AppDomain.CurrentDomain.BaseDirectory + assemblyName + ".dll";
            Assembly assembly = AppDomain.CurrentDomain.GetAssemblies().FirstOrDefault(a => a.FullName?.Split(‘,‘)[0] == assemblyName) ?? AssemblyLoadContext.Default.LoadFromAssemblyPath(assemblyFileName);
            FindDependency(assembly);
            return assembly;
        }

        private static void FindDependency(Assembly assembly)
        {
            DependencyContext dependencyContext = DependencyContext.Load(assembly);
            if(dependencyContext!= null)
            {
                foreach (var compilationLibrary in dependencyContext.CompileLibraries)
                {
                    if (!DependencyDLL.ContainsKey(compilationLibrary.Name)
                    && !AppDomain.CurrentDomain.GetAssemblies().Any(a => a.FullName.Split(‘,‘)[0] == compilationLibrary.Name))
                    {
                        RuntimeLibrary library = dependencyContext.RuntimeLibraries.FirstOrDefault(runtime => runtime.Name == compilationLibrary.Name);
                        var cb = new CompilationLibrary(
                            library.Type,
                            library.Name,
                            library.Version,
                            library.Hash,
                            library.RuntimeAssemblyGroups.SelectMany(g => g.AssetPaths),
                            library.Dependencies,
                            library.Serviceable);

                        DependencyDLL[library.Name] = cb;
                    }
                }
            }
        }
    }
}

原文地址:https://www.cnblogs.com/zhurongbo/p/10423231.html

时间: 2025-01-07 15:17:23

net core手动加载dll,无法自动加载其依赖项的相关文章

“未能加载文件或程序集file:///E:/MoneySet.dll或它的某一个依赖项,试图加载格式不正确的程序,行203,位置5. 文件:MReportSet.resx”,

http://bbs.csdn.net/topics/390334265 "未能加载文件或程序集file:///E:/MoneySet.dll或它的某一个依赖项,试图加载格式不正确的程序,行203,位置5. 文件:MReportSet.resx",

未能加载文件或程序集“file:///D:/Program Files (x86)/ArcGIS/DeveloperKit10.0/DotNet/ESRI.ArcGIS.3DAnalyst.dll”或它的某一个依赖项。试图加载格式不正确的程序。 行 129,位置 5。

能加载文件或程序集“file:///C:/Program Files (x86)/ArcGIS/DeveloperKit10.0/DotNet/ESRI.ArcGIS.ADF.Local.dll”或它的某一个依赖项.试图加载格式不正确的程序. 我们经常会遇到这样的错误,这是由于.NET版本引起的,改正方案就是在“解决方案管理”选择“项目”,然后右键选择“属性”,选择“应用程序”页,将”目标框架“改为正确的.NET平台即可.VS2010中改为.NETFrameWork 4.0 Client Pro

Delphi静态加载DLL和动态加载DLL示例

下面以Delphi调用触摸屏动态库xtkutility.dll为例子,说明如何静态加载DLL和动态加载DLL. 直接上代码. 1.静态加载示例 unit Unit1; interface uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls; type TForm1 = class(TForm) btnEnableTouch: TButton; btnDi

未能加载文件或程序集“SharpSvn.dll”或它的某一个依赖项。找不到指定的模块。

---恢复内容开始--- 在C#工程中使用sharpSVN进行SVN相关功能开发的时候,遇到了“未能加载文件或程序集“SharpSvn.dll”或它的某一个依赖项.找不到指定的模块. ”这样一个错误 经过一番尝试和搜索后,得出一下几个要点: 确保自己安装的SharpSVN版本和tortoisesvn版本保持大版本一致,不然会报SVN仓库的copy format不兼容的问题,这个时候使用相同大版本的SharpSVN和tortoiseSvn即可解决问题 确保自己的工程的编译选项和SharpSvn的编

php 自动加载函数、自动加载方法、自动加载类

在PHP开发过程中,如果希望从 外部引入一个class,通常会使用include和require方法,去把定义这个class的文件包含进来.这个在小规模开发的时候,没什么大问 题.但在大型的开发项目中,这么做会产生大量的require或者include方法调用,这样不因降低效率,而且使得代码难以维护,况且 require_once的代价很大. 在PHP5之前,各个PHP框架如果要实现类的自动加载,一般都是按照某种约定自己实现一个遍历 目录,自动加载所有符合约定规则的文件的类或函数. 当然,PHP

asp.net提示“未能加载文件或程序集“XXXXXXXX.dll”或它的某一个依赖项。找不到指定的模块。”

1.查看项目代码中指定程序集是否存在,若不存在,请重新添加 2.程序集存在,但依赖项找不到? 解决方案:下载程序集检测工具:depends (可选择检测某个dll的依赖情况) 图中红色的表示依赖项不存在,可以访问通过的电脑主机中查找这些依赖项,32位:C:\Windows\System32:64位:C:\Windows\SysWOW64,然后复制到相同位置 原文地址:https://www.cnblogs.com/yxcn/p/11429796.html

win 8系统:System.IO.FileNotFoundException: 未能加载文件或程序集“CefSharp.Core.dll”或它的某一个依赖项。找不到指定的模块

最近用CefSharp做了一个chrome核心的浏览器. 在win 7.win 10系统上都正常运行,但是在win 8系统上报错了. 安装了N次虚拟机试了好多次终于找到原因了.需要先下载安装  Visual C++ Redistributable Packages for Visual Studio 2013 x86 下载地址:  https://www.microsoft.com/zh-cn/download/details.aspx?id=40784 原文地址:https://www.cnb

Core 2.0 的dll实时更新、https、依赖包变更问题及解决

今天所有开发环境已经迁移到mac OS下的Visual Studio Code + 命令行编译发布,而运行服务器是CentOS7,和windows没什么关联了. 只要你Relese编译并在本地有一个与服务器相同的运行环境中运行成功了,迁移到真实服务器不会有什么难度. 下面是迁移到 2.0 版本之后遇到的3个问题及解决办法 1:有时候dll不会实时更新(不是每次都会遇到,并且这事情仅发生在Centos上)有时候你需要把与dll相关的所有边缘文件一同传上去(例如配套的xxx.config.json.

未能加载文件或程序集或某一个依赖项

最近看一个开源项目的时候由于自己电脑是32位的,运行项目就报这个错,于是网上找了一下发现这个问题解决方法下面这种最不错的就贴出来或许以后用得上 1.右键卸载项目 2.右键选择编辑工程文件加以下内容: 1 <PropertyGroup> 2 <ForceResGen32Bit Condition="'$(MSBuildToolsVersion)'=='4.0' And '$(PROCESSOR_ARCHITEW6432)'!='' And '$(TargetingClr2Fram