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

238

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

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

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

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

参考Include =“ Microsoft.Practices.Unity，版本= 2.0.414.0，文化=中性，PublicKeyToken = 31bf3856ad364e35，processorArchitecture = MSIL”

在我的任何项目中都找不到任何与1.2.0.0背离的参考。

有什么想法我应该去解决这个问题吗？

通常，我还将感谢有关如何调试此类问题的技巧。

c#  .net  reference  compiler-errors 
— 罗纳格
source
1
您引用的任何程序集都可以在旧Unity库中使用某些东西吗？
— decyclone 2010年
3
可能...但是如何找到哪个程序集？我的解决方案中有很多项目，而且有很多潜在的嫌疑人...反复试验的暴力
— 破解
3
它不是程序集参考，而是参考2.0版。但是在运行时，CLR正在找到1.2（旧版本）。如果在构建目录中没有看到旧的DLL，请使用Fuslogvw.exe找出CLR如何找到此旧副本。
— 汉斯·帕桑
2
查看项目的bin文件夹，查看项目的dll名称是否冲突。只需删除一个，然后重建您的解决方案。那对我有用。
— coggicc
11
“或它的依赖项之一”确实让我很烦。如果它无法加载“其依赖项之一”，则错误应说明无法加载“其依赖项之一”。当前形式是无用的，它可能还说不能加载东西
— Paul McCarthy

Answers:

116

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

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

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

— 努尔·萨布尼（Nour Sabouny）
source
6
FuseLogVw的日志文件在哪里
— Stiger 2014年
1
为了避免找到日志文件，您可以指定一个自定义日志路径：设置，选中“启用自定义日志路径”复选框，输入一个自定义日志路径，然后刷新。
— RedGreenCode 2015年
82

打开IIS管理器

选择应用程序池

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

转到高级设置（在右侧）

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

— 肯兰西
source
IIS->选择每个ApplicationPool->基本设置->检查是否在“ .NET Framework版本”下拉列表中选择了最新的框架
— Martin
您也可以在VS中右键单击您的项目。并删除首选的32位选中标记
— eran otzap 2014年
谢谢。有效。好吧，对于我来说，这已经是True了，只是为了尝试。我把它弄错了，它奏效了。
— meekash55
当我将一个项目从一台服务器合并到另一台服务器时，此标志确实再次为False，感谢您的解决方案！
— Appsum Solutions
69

对我而言，其他解决方案均无效（包括清除/重建策略）。我找到了另一个解决方法，即关闭并重新打开Visual Studio。

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

— 机器人技术
source
33
如果您不相信这行得通，请至少尝试一下。直到我自己都不敢相信。
— Ben Cull 2015年
3
for为我工作
— Devidas M Das
48

尝试清理解决方案中的“调试”和“发布”文件夹。然后删除并再次添加统一。

— Aleksei Anufriev
source
3
这个问题可能是由很多事情引起的……您的解决方案可以解决我的问题，也可以解决其他问题。
— Scott Rippey
1
@ScottRippey这对我有用。我首先删除了所有.pdb文件，然后重新加载了我的项目并对其进行了重建。
— botenvouwer 2014年
21

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（全局程序集缓存）中注册新的dll：打开DOS终端并输入：

    cd \Windows\System32
regsvr32 /i msvcr71.dll

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

— 斯特凡诺·洛纳蒂（Stefano Lonati）
source
22
Dependency Walker很棒，但是将随机DLL从Internet复制到Windows的效果却不太好。最好尝试查找提供这些dll的安装程序。
— RJFalconer
我API-MS-WIN-CORE-KERNEL32-PRIVATE-L1-1-1.DLL找不到一些文件（），导致我遇到了这个stackoverflow问题。基本上请记住，某些文件可能会出现误报，链接提供了更多详细信息。
— cheriejw
16

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>

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

— 丽贝卡
source
16

以下对我有用。

  • 删除临时文件C：\ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ ASP.NET临时文件
  • 关闭VSTS，然后再次打开
  • 删除并添加相同的DLL（注意：添加相同的匹配版本）
— 里迪M.
source
15

尽管最初的问题是在5年前发布的，但问题仍然存在，而且很烦人。

通用解决方案是对所有引用的程序集进行全面分析，以了解发生了什么问题。为了简化此任务，我制作了一个工具（Visual Studio扩展），该工具允许选择.NET程序集（一个.dll或.exe文件）以获取所有被引用程序集的图形，同时突出显示冲突或丢失的引用。

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

输出示例： 在此处输入图片说明

— 火星19
source
不适用于Visual Studio的社区版本
— Draex_
我相信应该还有另一个问题，与Visual Studio版本无关。我在VS 2017和VS 2015社区版本上测试了该扩展。实际上，它是通过VS 2017 Community Edition开发的。
— marss19'9
啊哈 您是否还安装了其他扩展程序？此页面说VS社区不支持
— DGML
1
社区版中没有体系结构工具，但是DGML编辑器本身可用。您可以通过Visual Studio安装程序的“单个组件”->“代码工具”下的“安装DGML编辑器”来选择安装->修改
— marss19
11

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

— 恩金·艾多杜（Engin Aydogdu）
source
检查应用程序池后，“启用32位应用程序”设置为False，但我的平台目标是x86。将其更改为任何CPU或x64可以解决我的问题。
— 基思·凯特勒'18
11

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

对于统一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之间有什么区别？

— 伊夫根·奈达（Ievgen Naida）
source
6

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

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

1），2）

右键单击解决方案名称

4），5）

更改配置以发布

希望这对您也有帮助。

— 罗珊娜（Roshana Pitigala）
source
5
  • 转到：解决方案 -> 包装
  • 单击高级选项卡（在页面下方查找）
  • 将您的dll添加到其他程序集中（这样我们就可以在sharepoint中添加外部dll）。
— 维杰·辛格
source
7
我的VS2010项目中没有“解决方案->程序包”
— Muflix 2015年
5

不知道这是否有帮助。

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

— 尚
source
优秀的！我的dll文件名和名称空间不同，我复制了名称空间并重命名了dll。
— 汗
5

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

— 托德尔
source
4

感谢RiddhiM。以下为我工作。

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

— 斯里达（Sridhar Kommana）
source
花了这么长时间，我不敢相信这就是答案。当您在VS中看到一些奇怪的行为时，通常是不错的解决方案。谢谢。
— Bonez024 '18
3

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

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

— 乔尔·马丁内斯（Joel Martinez）
source
3

以下对我有用。

  • 删除临时文件C：\ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ ASP.NET临时文件
    • 然后右键单击“ Asp.net临时文件”>“属性”>“安全性”，并授予对IIS和运行我的项目的所有用户的完全控制访问权限
— 只有我
source
3

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

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

在此处输入图片说明

— 穆罕默德·阿尔玛西
source
2

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

— 古驰（Gucci）
source
2

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

然后部署它。

有效！

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

— 尼拉夫
source
2

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

— 纳森切尔
source
这花了我几个小时才弄清楚。...我不小心将单元测试项目命名为与主项目相同的名称，因此，单元测试项目dll必须已经覆盖了项目dll
— Iannazzi
2

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

Microsoft.Practices.Unity.Interception.dll

— 麦吉威
source
2

找出有冲突的参考。即使经过清理和重建，冲突的引用仍然会引起问题。我的问题出在AForge和Accord之间。我删除了两个引用，然后重新添加了引用，以重新选择特定的引用（对于我的情况，只是Accord）。

— 用户名
source
2

对我来说，在没有Unity C＃Proects Checkmark的情况下重建统一游戏非常有效。

— Praful Rudra
source
2

我今天有这个，对我来说，这个问题很奇怪：

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

更改为上面，瞧！一切又恢复了。

— 加里普
source
1

如果通过在Windows XP上打开应用程序而收到此错误消息，则意味着首先安装该应用程序是因为该应用程序在没有Net Framework 4和Service Pack 3的情况下无法正常工作。您同时安装了这两个错误，因此您应该重新安装该应用，但首先要从添加和删除中卸载

如果这不行，请不要虐待我。我也是大三

— 巴斯蒂特·杜拉尼
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.