无法加载文件或程序集或其依赖项之一

Posted 2023-03-31

【中文标题】无法加载文件或程序集或其依赖项之一

【英文标题】：Could not load file or assembly or one of its dependencies

【发布时间】：2021-12-12 11:06:26

【问题描述】：

我遇到了另一个“”问题。

附加信息：无法加载 文件或程序集 'Microsoft.Practices.Unity, 版本=1.2.0.0，文化=中性， PublicKeyToken=31bf3856ad364e35' 或 它的依赖项之一。位于 程序集的清单定义确实 与程序集引用不匹配。 （HRESULT 异常：0x80131040）

我不知道是什么原因造成的，也不知道如何调试它以找到原因。

我已经在我的解决方案目录 .csproj 文件中进行了搜索，并且在我拥有 Unity 的每个地方都进行了搜索：

参考 包括="Microsoft.Practices.Unity, 版本=2.0.414.0，文化=中性， PublicKeyToken=31bf3856ad364e35, 处理器架构=MSIL"

在我的任何项目中都找不到任何违反 1.2.0.0 的参考。

任何想法我应该如何解决这个问题？

【问题讨论】：

您引用的任何程序集是否都在使用旧 Unity 库中的某些内容？

可能...但是我怎样才能找到哪些程序集？我的解决方案中有很多项目，还有很多潜在的嫌疑人......试错蛮力似乎有点绝望......

不是程序集参考，你参考的是2.0版。但是在运行时，CLR 会找到 1.2，一个旧版本。如果在构建目录中没有看到旧 DLL，则使用 Fuslogvw.exe 找出 CLR 是如何找到这个旧副本的。

查看项目的 bin 文件夹，看看项目的 dll 名称是否有冲突。只需删除那个，然后重建您的解决方案。这对我有用。

“或其依赖项之一”是真正让我烦恼的部分。如果它无法加载“其依赖项之一”，则错误应说明无法加载哪个“其依赖项之一”。现在的form没用，还不如说can't load thinggy

【参考方案1】：

检查您是否引用了一个程序集，而该程序集又引用了旧版本的统一。例如，假设您有一个名为 ServiceLocator.dll 的程序集需要旧版本的 Unity 程序集，现在当您引用 ServiceLocator 时，您应该为它提供旧版本的 Unity，这就产生了问题。

可能是所有项目构建其程序集的输出文件夹，具有旧版本的 unity。

您可以使用FusLogVw 找出谁在加载旧程序集，只需定义日志路径，然后运行您的解决方案，然后检查（在 FusLogvw 中）加载 Unity 程序集的第一行，双击它并查看调用程序集，然后就可以了。

【讨论】：

FuseLogVw的日志文件在哪里

为避免不得不查找日志文件，可以指定自定义日志路径：设置，勾选启用自定义日志路径复选框，输入自定义日志路径，刷新。

【参考方案2】：

打开 IIS 管理器

选择应用程序池

然后选择您正在使用的池

进入高级设置（在右侧）

将启用 32 位应用程序 false 的标志更改为 true。

【讨论】：

IIS -> 选择每个ApplicationPool -> Basic Settings -> 检查“.NET Framework version”下拉列表下是否选择了最新的framework

您也可以在 VS 中右键单击您的项目。并删除首选 32 位复选标记

谢谢。有效。好吧，就我而言，它已经是 True 了，只是为了尝试。我把它设置为 False 并且它起作用了。

当我将一个项目从一台服务器合并到另一台服务器时，该标志确实再次为 False，感谢您的解决方案！

【参考方案3】：

对我来说，其他解决方案都不起作用（包括清理/重建策略）。我找到了另一种解决方法，即关闭并重新打开 Visual Studio。

我猜这会迫使 Visual Studio 重新加载解决方案和所有项目，重新检查过程中的依赖关系。

【讨论】：

是的，这里也一样，结合了清洁解决方案。在我这样做之后，VS 突出显示了一个之前没有出现的构建错误。以前它说重建后重建全部成功 - 我为一个类引用了错误的命名空间。

【参考方案4】：

尝试清理解决方案中的 Debug 和 Release 文件夹。然后再次删除并添加unity。

【讨论】：

这个问题可能是由很多原因引起的……您的解决方案解决了我的问题，也可能解决其他人的问题。

@ScottRippey 这对我有用。我首先删除了所有 .pdb 文件，然后重新加载我的项目并重建它。

为我工作，我刚刚删除了bin/ 文件夹并再次构建了解决方案。

【参考方案5】：

在 99% 的情况下，无法加载文件或程序集或其依赖项之一问题是由依赖项引起的！我建议您按照以下步骤操作：

从http://www.dependencywalker.com/下载Dependency Walker

启动 Dependency Walker 并打开 dll（在我的情况下为 NativeInterfaces.dll）

您可以看到一个或多个带有红色错误的dll 打开文件时出错...

这意味着你的系统中缺少这个dll；在我的情况下，dll 名称是 MSVCR71.DLL

您可以从谷歌下载缺失的 dll 并复制到正确的路径（在我的情况下为 c:\windows\system32）

此时，你必须在GAC（全局程序集缓存）中注册新的dll：打开一个DOS终端并写入：

 cd \Windows\System32
 regsvr32 /i msvcr71.dll

重新启动您的应用程序

【讨论】：

Dependency walker 很棒，但是将随机 DLL 从 Internet 复制到 Windows 就不太好。最好尝试找到提供这些 dll 的安装程序。

我有几个文件 (API-MS-WIN-CORE-KERNEL32-PRIVATE-L1-1-1.DLL) 没有找到，并把我带到了this *** question。基本上请记住，可能会查看某些文件的误报，链接提供了更多详细信息。

【参考方案6】：

尽管最初的问题是五年前发布的，但问题仍然存在并且相当烦人。

一般的解决方案是彻底分析所有引用的程序集，以了解发生了什么问题。为了使这项任务更容易，我制作了一个工具（Visual Studio 扩展），它允许选择 .NET 程序集（.dll 或 .exe 文件）以获取所有引用程序集的图表，同时突出显示冲突或丢失的引用。

该工具在 Visual Studio 库中可用：https://marketplace.visualstudio.com/vsgallery/051172f3-4b30-4bbc-8da6-d55f70402734

输出示例：

【讨论】：

不适用于 Visual Studio 的社区版

我相信应该还有另一个问题，与 Visual Studio 版本无关。我在 VS 2017 和 VS 2015 社区版上测试了扩展。实际上它是通过 VS 2017 社区版开发的。

啊哈。您是否安装了任何其他扩展程序？这个页面说VS社区不支持DGML：msdn.microsoft.com/en-us/library/hh871439.aspx#VersionSupport

社区版中没有架构工具，但 DGML 编辑器本身可用。您可以通过 Visual Studio Installer -> Modify

在“Individual Components”->“Code Tools”下选择“Install DGML editor”安装它

【参考方案7】：

以下对我有用。

删除临时文件 C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files 关闭 VSTS 并重新打开 删除和添加相同的 DLL（注意：添加相同的匹配版本）

【参考方案8】：

Microsoft 企业库（由 .NetTiers 引用）是我们的问题，它又引用了旧版本的 Unity。为了解决这个问题，我们在 web.config 中使用了如下绑定重定向：

<configuration>
    <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <dependentAssembly>
                <assemblyIdentity name="Microsoft.Practices.Unity" publicKeyToken="31bf3856ad364e35" culture="neutral" />
                <bindingRedirect oldVersion="1.0.0.0-2.0.414.0" newVersion="2.1.505.0" />
            </dependentAssembly>
            <dependentAssembly>
                <assemblyIdentity name="Microsoft.Practices.Unity.Configuration" publicKeyToken="31bf3856ad364e35" culture="neutral" />
                <bindingRedirect oldVersion="1.0.0.0-2.0.414.0" newVersion="2.1.505.0" />
            </dependentAssembly>
        </assemblyBinding>
    </runtime>
</configuration>

或者，您可能只想将企业库更新到最新版本。

【参考方案9】：

检查项目中的 Web.config/App.config 文件。查看版本号是否正确。

<bindingRedirect oldVersion="X.X.X.X-X.X.X.X" newVersion="X.X.X.X" />

这对我有用。

【讨论】：

这对我有用，虽然它是 web.config，而不是 app.config

【参考方案10】：

在解决方案资源管理器中右键单击项目（不是解决方案），在构建选项卡中选择平台目标：“任何 CPU”。

【讨论】：

检查应用程序池后，“启用 32 位应用程序”设置为 False，但我的平台目标是 x86。将其更改为 Any CPU OR x64 解决了我的问题。

【参考方案11】：

Juntos 的答案是正确的，但您也应该考虑：

为统一 v2.1.505.2 指定了不同的 AssemblyVersion 和 AssemblyFileVersion 属性：

AssemblyFileVersion 被 NuGet 使用，但 CLR 并不关心它！ CLR 将只使用 AssemblyVersion！

因此，您的重定向应该应用于 AssemblyVersion 属性中指定的版本。所以应该使用2.1.505.0

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
 <assemblyIdentity name="Microsoft.Practices.Unity" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.1.505.0" newVersion="2.1.505.0" />
</dependentAssembly>
</assemblyBinding>

另请参阅： What are differences between AssemblyVersion, AssemblyFileVersion and AssemblyInformationalVersion?

【参考方案12】：

我也遇到了这个可怕的错误，并找到了解决方案......

右键单击解决方案名称 点击清理解决方案 重启 Visual Studio 转到项目属性 >> 构建 将配置更改为发布 开始调试 (F5)

1) , 2)

4) , 5)

希望这对你也有帮助。

【参考方案13】：

我遇到了同样的问题，我通过以下说明解决了它：

打开工具菜单并选择选项 在选项中，窗口转到项目和解决方案/Web 项目 检查use the 64bit version of IIS ...

【参考方案14】：

转到：

解决方案

->

包

点击

高级

标签（在页面下方查找） 将您的

dll

添加到其他程序集（这样我们可以在 sharepoint 中添加外部 dll）。

【讨论】：

我的 VS2010 项目中没有“解决方案 -> 包”

【参考方案15】：

不确定这是否有帮助。

检查程序集名称和程序集中属性中的默认命名空间是否匹配。这解决了我产生相同错误的问题。

【讨论】：

太棒了！我的dll文件名和命名空间不同，我复制了命名空间并重命名了我的dll。

【参考方案16】：

在我的 bin 文件夹中是一个名为 Unity.MVC3 的非引用 dll，我尝试在 Visual Studio 中搜索对此的任何引用但没有成功，所以我的解决方案非常简单，只需从 bin 文件夹中删除该 dll。

【参考方案17】：

感谢 Riddhi M。 以下对我有用。

删除临时文件 C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files 关闭 VSTS 并再次打开 删除和添加相同的 DLL（注意：添加相同的匹配版本）

【讨论】：

花了这么长时间，我不敢相信这是答案。当您在 VS 中看到一些奇怪的行为时，这通常是一个很好的解决方案。谢谢。

【参考方案18】：

您说您的解决方案中有很多项目......好吧，从构建顺序顶部附近的一个开始。得到那个来构建，一旦你弄清楚了，你就可以对其余的应用相同的修复。

老实说，您可能只需要刷新您的参考。听起来您要么更新了版本，但没有更新引用，或者如果您将解决方案保留在源代码管理中，这是一个相对路径问题。只需验证您的假设，然后重新添加参考。

【参考方案19】：

如果您通过在 windows xp 上打开应用程序而收到此错误消息，则意味着您首先安装了该应用程序，因为它在没有 net framework 4 和 service pack 3 的情况下无法工作。您一次又一次地安装了此错误，因此您应该再次重新安装该应用程序，但首先从添加和删除中卸载

如果这不起作用，请不要辱骂我。我也是小学生

【参考方案20】：

以下对我有用。

删除临时文件 C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files 然后右键单击 Temporary Asp.net Files>properties>security 并授予对 IIS 和运行我的项目的所有用户的完全控制访问权限

【参考方案21】：

这个问题发生在我身上，当父库期望编译“x64”时，我的一个依赖库正在使用“任何 CPU”编译 DLL。

【讨论】：

***.com/questions/516730/…

【参考方案22】：

您必须从输出文件夹中删除您的 appname.dll 文件。 清理调试和发布文件夹。 重建并复制到输出文件夹重新生成dll文件。

【参考方案23】：

我“设置为启动项目”卸载/未找到的库/项目。

然后部署它。

成功了！

我认为它找不到 .dll，因为它最初不在程序集中。

【参考方案24】：

另一个可能的原因：确保您没有不小心在项目属性中为两个项目指定了相同的程序集名称。

【讨论】：

这花了我几个小时才弄明白......我不小心将我的单元测试项目命名为与主项目相同的名称，所以单元测试项目 dll 一定是覆盖了项目 dll

【参考方案25】：

我使用 Enterprise Library 5 的 .NET 4.0 解决方案是添加对以下内容的引用：

Microsoft.Practices.Unity.Interception.dll

【参考方案26】：

注意有冲突的引用。即使在清理和重建之后，冲突的引用仍然会导致问题。我的问题是在 AForge 和 Accord 之间。我删除了两个引用，并重新添加了重新选择特定引用的引用（特别是我的情况，只是 Accord）。

【参考方案27】：

就我而言，建议的答案都不起作用。

这对我有用：

删除引用 重命名 DLL 再次导入引用

第二步显然很重要，因为没有它就行不通。

【参考方案28】：

尝试检查引用的“复制到本地”属性是否设置为 true，并且特定版本是否设置为 true。这与 Visual Studio 中的应用程序有关。

【参考方案29】：

我今天遇到了这个问题，就我而言，这个问题很奇怪：

  <dependentAssembly>
    <assemblyIdentity name="Microsoft.Owin.Host.SystemWeb" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.1.0" newVersion="3.1.0.0" />
  </dependentAssembly>0.

请注意 XML 末尾的杂散字符 - 不知何故，这些字符已从版本号移到此 XML 块的末尾！

  <dependentAssembly>
    <assemblyIdentity name="Microsoft.Owin.Host.SystemWeb" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.1.0.0" newVersion="3.1.0.0" />
  </dependentAssembly>

更改为上述内容，瞧！一切都恢复正常了。

【参考方案30】：

清理解决方案，然后右键单击项目并选择Package

这里增加 Assembly 和 Assembly file 版本并重建。

如果这样不行，

1 - 在文件资源管理器中打开解决方案。

2 - 关闭 Visual Studio。

3 - 删除所有 bin 和 obj 文件夹。

4 - 重新打开项目并构建它。