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

Question

我遇到了另一个“无法加载文件或程序集或其依赖项之一”的问题。

附加信息：无法加载文件或程序集“Microsoft.Practices.Unity，Version=1.2.0.0，Culture=neutral，PublicKeyToken=31bf3856ad364e35”或其依赖项之一。 找到的程序集的清单定义与程序集引用不匹配。 （HRESULT 异常：0x80131040）

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

我在我的解决方案 catalogs.csproj 文件中进行了搜索，在我拥有 Unity 的每个地方我都有：

Reference Include="Microsoft.Practices.Unity, Version=2.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL"

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

我应该如何解决此问题的任何想法 go？

Answer 1

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

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

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

Answer 2

打开 IIS 管理器

选择应用程序池

然后选择您正在使用的池

进入高级设置（在右侧）

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

Answer 3

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

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

Answer 4

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

Answer 5

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

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

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

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

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

5. 您可以从 google 下载缺少的 dll 并复制到正确的路径中（在我的情况下是c:\\windows\\system32 ）

6. 此时必须在GAC（Global Assembly Cache）中注册新的dll：打开DOS终端，写入：

    cd \\Windows\\System32 regsvr32 /i msvcr71.dll

7. 重新启动您的应用程序

Answer 6

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

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

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

输出示例：

Answer 7

Microsoft Enterprise Library（由 .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>

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

Answer 8

以下为我工作。

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

Answer 9

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

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

这对我有用。

Answer 10

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

Answer 11

Juntos 的回答是正确的，但您还应该考虑：

对于 unity v2.1.505.2 ，指定了不同的AssemblyVersion和AssemblyFileVersion属性：

NuGet 使用了AssemblyFileVersion ，但 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>

另请参阅： AssemblyVersion、AssemblyFileVersion 和 AssemblyInformationalVersion 之间有什么区别？

Answer 12

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

1. 右键单击解决方案名称
2. 单击清洁解决方案
3. 重新启动 Visual Studio
4. 转到项目属性>>构建
5. 更改配置以发布
6. 开始调试 (F5)

1) , 2)

4) , 5)

希望这也能帮助你。

Answer 13

不确定这是否有帮助。

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

Answer 14

• 转到：解决方案->包
• 单击高级选项卡（在页面下方查找）
• 将您的dll添加到其他程序集（这样我们可以在 sharepoint 中添加外部 dll）。

Answer 15

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

Answer 16

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

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

Answer 17

谢谢 Riddhi M. 以下为我工作。

删除临时文件 C:\\Windows\\Microsoft.NET\\Framework\\v4.0.30319\\Temporary ASP.NET Files Close VSTS and Open Again Remove and Add the same DLLs (注意：你添加了相同的匹配版本)

Answer 18

以下为我工作。

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

Answer 19

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

Answer 20

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

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

Answer 21

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

Answer 22

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

然后部署了它。

它奏效了！

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

Answer 23

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

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

Answer 24

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

Answer 25

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

Microsoft.Practices.Unity.Interception.dll

Answer 26

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

Answer 27

对我来说，在没有 Unity C# Projects Checkmark 的情况下重建 Unity 游戏有效。

Answer 28

就我而言，建议的答案都没有奏效。

这是对我有用的：

1. 删除引用
2. 重命名 DLL
3. 再次导入引用

第二步显然很重要，因为没有它它就无法工作。

Answer 29

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

Answer 30

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

  <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>

更改为以上，瞧！ 一切都恢复了。

Answer 31

清理解决方案，然后右键单击项目和 select Package

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

如果这不起作用，

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

2 - 关闭 Visual Studio。

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

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

Answer 32

好吧，这听起来可能非常愚蠢，但继续尝试其他所有解决方案并在这个愚蠢的事情上过夜后，我是如何解决这个问题的。

我从Bin文件夹中丢失了一些DLL时遇到了同样的错误。 我试图删除，从Team Foundation Server备份所有内容但没有工作。 从我的office-matelocal机器获得了Bin文件夹的副本，并将其替换。 它也没用。 最后，我手动FTP服务器，获得了显示为丢失的DLL副本，然后它开始显示文件列表序列中的下一个文件丢失。

所以我ftped服务器得到了所有Bin文件夹，手动逐个替换每个文件。 （不是Ctrl + All并替换..我试过：它不起作用。）不知何故它起作用了......

Answer 33

我的解决方案是：

我有一个三层应用程序，我忘记将 DLL 也复制到 IIS 的正确路径。 将它复制到正确的位置后，它对我有用。

Answer 34

我在 Visual Studio 2015 中的 web forms 项目中不断收到此错误。我关闭了 Visual Studio 并杀死了 ScriptedSandbox64.exe、Microsoft.VsHub.Server.HttpHostx64.exe、Microsoft.VsHub.Server.HttpHostx.exe .VisualStudio.Web.Host.exe *32 个进程，它似乎有助于解决问题。

Answer 35

我执行以下操作来确定找不到哪个依赖项。

运行 regedit.exe 并导航到：

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion

创建以下内容：

LogFailures set value to 1 (DWORD)
LogResourceBinds set value to 1 (DWORD)
LogPath (String) set value to C:\FusionLog\

现在运行您的程序并等待它引发Could not load file or assembly or one of its dependencies 。

使用资源管理器，导航到C:\FusionLog并且应该有一个包含程序日志的文件夹，显示缺少哪个依赖项。

注意：有些人使用 FUSLOGVW.exe，它是这些 Fusion Logs 的查看器。 在我的机器上可以在多个地方找到它，包括：

C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7.2 Tools\x64\FUSLOGVW.exe

Answer 36

我有这个问题，这个错误实际上很愚蠢。 我为 .dll 文件指定了错误的位置，在将位置更改为正确的位置后，加载正确发生（回答所以其他人不要犯这个错误）。

Answer 37

对我来说，Nuget 似乎对我的项目/解决方案不太好。 I used Nuget to install NewtonSoft.Json The project file seemed to reference it correctly, and when I R-clicked the dll name in Solution Explorer/Dependencies/Nuget, then clicked Properties, I found that the dll existed where properties said it should be .

I deleted the Nuget package and did R-click Project > Add > Reference and browsed to the dll in a packages directory when a former Nuget process had installed it, and then the Solution ran fine.

注意：这个解决方案是一个大杂烩，从 Xamarin.iOS 解决方案开始，并添加一个 .netstandard 项目（这是我在使用 Nuget 时遇到困难的地方）。 解决方案中还有一个“便携式”项目。 我从一个已经离开 3 年的开发人员那里继承了这一切。 哈哈。

Answer 38

我有一个名为 SetTags 的 C# Winforms 项目，其中包含大量 forms，我使用 Visual Studio 2013 进行处理。 在编辑其中一个并尝试构建后，我得到了错误：

Could not load file or assembly 'SetTags Version = 2.1.85.0, Culture=neutral,PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.

当我尝试保存项目或关闭我一直在处理的表单时，也会出现该错误。

我通过删除最近添加的单选按钮控件并注释掉对其的所有引用来解决问题，然后再次添加控件并取消注释代码。 这使我可以保存表单，并在关闭重新启动 VS 时问题消失了。

我的 Visual Studio 环境偶尔会出现许多问题 - 工具箱不显示或仅在 VS 启动时出现，尝试在设计模式下查看表单时无法识别的自定义控件 - 可能是我需要转到更高的 VS 版本。

Answer 39

对我来说是一个奇怪的修复，但我刚刚从源代码管理中提取了这个解决方案。

收到此错误，查看了上面的大部分答案，然后删除了解决方案并从源代码管理中重新提取了解决方案。

工作。

只适用于少数人，但我想我是少数人之一，所以会有更多。 不知道第一次发生了什么，但不知何故，当我把它们拉过来时，某些组件一定有一些问题。

基本上将其关闭并再次打开。

Answer 40

我也在这个问题上浪费了几个令人沮丧的时间。 我们不得不更新我们的 .NET 框架版本，并开始为几个多年未更改的 DLL 获取多个“无法加载文件或程序集或其依赖项之一”。 奇怪的是，在错误消息中搜索的版本都非常旧。 例如，它正在搜索 Newtonsoft.Json 版本 6.0.0，而我们多年来一直使用 8.0.1。

恢复到这些旧版本不是一种选择，无论如何，我们的 web.config 文件中有一堆bindingRedirect元素，它们应该将对旧 DLL 的调用重定向到新的 DLL。 回滚 .NET 版本使错误 go 消失，但我们需要新版本。 到底是怎么回事？

我们的 web.config 文件中的<runtime>元素包含以下元素：

<assemblyBinding appliesTo="v2.0.50727"
    xmlns="urn:schemas-microsoft-com:asm.v1">

似乎被忽略的dependentAssembly元素包含在其中。

罪魁祸首是appliesTo属性。 这意味着bindingRedirect仅适用于 .NET 版本 2.0.50727。 当我们更新 .NET 框架版本时，我们所有的 bindingRedirect 元素都被忽略了。

在我们的案例中，解决方案是完全删除appliesTo属性。

Answer 41

您的项目的 csproj 文件必须包含 Microsoft.Practices.Unity 的 package 引用，并且在 global-packages 文件夹 (%userprofile%.nuget\packages) 中找不到此文件，运行dotnet restore可解决此问题

Answer 42

第 1 步：删除现有参考 第 2 步：清理解决方案 第 3 步：再次添加项目参考。

并完成。 :)

Answer 43

TLDR； 我的解决方案是在 Visual Studio 中恢复默认设置。

---

我在 Visual Studio 2019 社区版上，我在我没有接触的不同项目中遇到了相同的 dll 文件的问题。

在尝试了这个问题的所有答案后（截至 2020-07-22 7:13UTC），我决定修复 Visual Studio 安装（事先备份了我的设置）。 安装后打开有问题的解决方案，问题就消失了。 之后导入我的设置，问题又回来了。因此，无需再次修复 Visual Studio 安装（这需要几分钟 + 一次重启），我只是恢复了 VS 默认设置，然后它就可以工作了。 如果我最终有时间进行调查，我将编辑答案并查明潜在问题

Answer 44

尝试按照建议关闭并重新打开 VS，但没有成功。

我不得不从 MIXED PLATFORMS更改为 ANY CPU 。

Answer 45

我使用了神奇的工具“Fusion++” https://github.com/awaescher/Fusion