Question

我有另外一个“无法加载文件或程序集或其中一个依赖项”的问题。

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

我不知道造成这种情况的原因或我如何调试它以找到原因。

我已经在我的解决方案目录.csproj文件中搜索过，以及我拥有Unity的所有地方：

参考包括=“Microsoft.Practices.Unity，版本= 2.0.414.0，文化=中立，公钥= 31bf3856ad364e35， ProcessorArchitecture用于= MSIL“

在我的任何项目中找不到任何与1.2.0.0相对应的引用。

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

我也很欣赏如何调试这样的问题的提示。

Answer 1

检查您是否引用了一个程序集，而该程序集又引用旧版本的unity。例如，假设您有一个名为ServiceLocator.dll的程序集，它需要旧版本的Unity程序集，现在当您引用ServiceLocator时，您应该使用旧版本的Unity提供它，这就产生了问题。
可能是所有项目构建其程序集的输出文件夹，具有旧版本的统一。

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

Answer 2

打开IIS管理器

选择应用程序池

然后选择您正在使用的游泳池

转到高级设置（右侧）

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

Answer 3

对我来说，其他解决方案都没有奏效（包括清洁/重建策略）。我找到了另一种解决方法，即关闭并重新打开Visual Studio 。

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

Answer 4

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

Answer 5

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

从http://www.dependencywalker.com/下载 Dependency Walker
启动 Dependency Walker 并打开dll（在我的情况下为NativeInterfaces.dll）
您可以看到一个或多个错误的红色错误打开文件...
这意味着您的系统中缺少此dll;就我而言，dll名称为MSVCR71.DLL
您可以从谷歌下载misll dll并以正确的路径复制（在我的情况下为c:\windows\system32）
此时，您必须在GAC（全局程序集缓存）中注册新的dll：打开DOS终端并写入：
```
cd \Windows\System32
regsvr32 /i msvcr71.dll
```
重新启动您的应用程序！

Answer 6

以下为我工作。

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

Answer 7

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

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

这对我有用。

Answer 8

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 9

尽管5年前发布了原始问题，但问题仍然存在并且相当令人讨厌。

一般解决方案是对所有引用的程序集进行彻底分析，以了解出现了什么问题。为了使这个任务更容易，我创建了一个工具（一个Visual Studio扩展），它允许选择.Net程序集（.ddl或.exe文件），并获得所有引用的程序集的图表，其中包含突出显示的冲突或错过的引用。

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

输出示例：

Answer 10

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

Answer 11

我有类似的问题。 ** Juntos答案是正确的**但你应该注意一个重要提示！

对于统一 2.1.505.2 ，指定了不同的 AssemblyVersion 和 AssemblyFileVersion ：

enter image description here

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?

Answer 12

转到：解决方案 - ＆gt;的封装

点击高级标签（在页面下方查找）

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

Answer 13

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

右键单击解决方案名称

单击“清洁解决方案”

重新启动Visual Studio

转到项目属性＆gt;＆gt;构建

将配置更改为发布

开始调试（F5）

1），2）

4），5）

希望这也会对你有所帮助。

Answer 14

不确定这是否有帮助。

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

Answer 15

在我的案例中，在bin文件夹中是一个名为Unity.MVC3的非引用dll，我试图在visual studio中搜索任何引用但没有成功，所以我的解决方案就像从bin文件夹中删除dll一样简单。 / p>

Answer 16

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

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

Answer 17

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

Answer 18

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

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

Answer 19

以下为我工作。

删除临时文件C：\ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Temporary ASP.NET Files
- 然后右键单击Temporary Asp.net Files＆gt; properties＆gt; security 并提供对IIS以及运行我的项目的所有用户的完全控制访问权限

Answer 20

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

Answer 21

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

Answer 22

对我来说，在没有Unity C的情况下重建团结游戏#Proects Checkmark工作。

Answer 23

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

Answer 24

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

这对我有用：

删除参考
重命名DLL
再次导入参考

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

Answer 25

尝试检查＆＃34;复制到本地＆＃34;引用的属性设置为true，特定版本设置为true。这与Visual Studio中的应用程序相关。

Answer 26

我今天有这个，在我的情况下，问题很奇怪：

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

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

Microsoft.Practices.Unity.Interception.dll

Answer 28

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

然后部署它。

有效！

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

Answer 29

我在Visual Studio 2015中的Web表单项目上一直收到此错误。我关闭了Visual Studio，我杀死了ScriptedSandbox64.exe，Microsoft.VsHub.Server.HttpHostx64.exe，Microsoft.VsHub.Server.HttpHostx.exe * 32，Microsoft.VisualStudio.Web.Host.exe * 32进程，它似乎有助于解决问题。

Answer 30

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

在此增加Assembly和Assembly file的版本并重建。

如果这样不起作用，

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

2-关闭Visual Studio。

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

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

Answer 31

如果您通过在Windows XP上打开应用程序来获取此错误消息，则表示首先安装该应用程序，因为它在没有net framework 4和Service Pack 3的情况下无法运行。你安装了这两个，你又得到了这个错误，所以你应该重新安装该应用程序，但首先从添加和删除

卸载

如果这不起作用请不要虐待我。我也是一名大三学生

Answer 32

我的解决方案是：

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

Answer 33

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

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

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

Answer 34

对我来说，似乎Nuget在我的项目/解决方案中表现不佳。我使用Nuget安装NewtonSoft.Json，该项目文件似乎正确引用了它，当我在解决方案资源管理器/ Dependencies / Nuget中右击dll名称，然后单击“属性”时，我发现该dll存在于应指出的属性所在的位置。

我删除了Nuget软件包，并右键单击Project> Add> Reference，并在以前的Nuget进程安装了dll后浏览了软件包目录中的dll，然后解决方案运行良好。

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

Answer 35

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

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

Answer 36

我有一个名为SetTags的C＃Winforms项目，其中包含使用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 37

对我来说是一个奇怪的修复程序，但我刚刚从源代码管理中撤回了此解决方案。

遇到此错误时，请仔细阅读上面的大多数答案，然后删除解决方案，然后从源代码管理中重新拉出解决方案。

工作。

仅适用于少数几个，但我想我是少数几个之一，因此会有更多。不知道第一次发生了什么，但是当我将它们拉过时，某些组件一定会遇到一些问题。

基本上将其关闭然后再打开。

Answer 38

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

Answer 39

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

恢复到这些旧版本不是一个选择，无论如何，在我们的web.config文件中有一堆bindingRedirect元素可以将对旧DLL的调用重定向到新DLL。回滚.NET版本可以使错误消失，但是我们需要新版本。发生了什么事？

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

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

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

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

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

Answer 40

您项目的csproj文件必须包含Microsoft.Practices.Unity的程序包引用，并且无法在global-packages文件夹（％userprofile％.nuget \ packages）中找到该程序包，运行dotnet restore可解决此问题< / p>

Answer 41

步骤1：删除现有参考第2步：清洁溶液第三步：再次添加项目引用。

及其完成。：）

Answer 42

TLDR；对我来说，解决方案是在Visual Studio中恢复默认设置。

我正在使用Visual Studio 2019社区版，并且在我没有碰过的不同项目中，对于同一个dll文件我遇到了这个问题。

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

Answer 43

我执行以下操作来找出无法找到的依赖项。

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

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

43 个答案: