其他信息：无法加载
文件或程序集
'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背离的引用。
有什么想法应该解决这个问题吗？
/>
我也很高兴了解一般如何调试此类问题的技巧。
#1 楼
检查是否引用了程序集，而程序集又引用了旧版本的unity。例如，假设您有一个名为
ServiceLocator.dll的程序集，该程序集需要一个旧版本的Unity程序集，现在，当您引用ServiceLocator时，应为它提供旧版本的Unity，这会引起问题。可能是输出所有项目都在其中构建其程序集的文件夹，其中包含旧版本的unity。
您可以使用FusLogVw找出谁正在加载旧程序集，只需定义日志路径并运行解决方案，然后检查（在FusLogvw中）加载Unity程序集的第一行，双击它并查看调用程序集，然后就可以了。
评论
FuseLogVw的日志文件在哪里
– Stiger
2014年8月1日，凌晨3:41
为了避免找到日志文件，您可以指定一个自定义日志路径：设置，选中“启用自定义日志路径”复选框，输入一个自定义日志路径，然后刷新。
– RedGreenCode
15年1月21日在19:46
#2 楼
打开IIS管理器选择应用程序池
，然后选择您正在使用的池
转到高级设置（在右侧）
将“启用32位应用程序”的标志从false更改为true。
评论
IIS->选择每个ApplicationPool->基本设置->检查是否在“ .NET Framework版本”下拉列表中选择了最新的框架
–马丁
13年11月19日在6:58
您也可以在VS中右键单击您的项目。并删除首选的32位复选标记
–eran otzap
14-10-12在6:57
谢谢。有效。好吧，对于我来说，这已经是True了，只是为了尝试。我把它弄错了，它奏效了。
–meekash55
17年1月27日在10:10
当我将一个项目从一台服务器合并到另一台服务器时，此标志确实再次为False，感谢您的解决方案！
–Appsum解决方案
19年11月27日在7:01
#3 楼
对我而言，其他解决方案均无效（包括清除/重建策略）。我找到了另一个解决方法，即关闭并重新打开Visual Studio。我想这迫使Visual Studio重新加载解决方案和所有项目，重新检查过程中的依赖项。
评论
如果您不相信这行得通，请至少尝试一下。直到我自己都不敢相信。
–本·库尔
15年1月27日在13:40
for为我工作
– Devidas M Das
18年9月9日15:43
Visual Studio 2019，这仍然是我的解决方法😥
–月亮打蜡
10月27日8:01
@月亮-o很抱歉听到hear
–罗伯特尼克
10月27日9:16
#4 楼
尝试清理解决方案中的“调试”和“发布”文件夹。然后删除并再次添加统一。评论
这个问题可能是由很多事情引起的……您的解决方案解决了我的问题，也可能解决了其他问题。
–斯科特·里皮（Scott Rippey）
2011年9月29日在1:19
@ScottRippey这对我有用。我首先删除了所有.pdb文件，然后重新加载了我的项目并对其进行了重建。
–botenvouwer
2014年2月12日在8:26
#5 楼
99％时无法加载文件或程序集，或者其依赖性问题之一是由依赖性引起的！我建议您按照以下步骤操作：从http://www.dependencywalker.com/
下载Dependency Walker，启动Dependency Walker并打开dll（在我的情况下为
NativeInterfaces.dll） 您可以看到一个或多个带有红色错误的dll。打开文件时出现错误。在您的系统中；在我的情况下，dll名称为
MSVCR71.DLL 您可以从Google下载丢失的dll并以正确的路径进行复制（在我的情况下为
c:\windows\system32）此时，您必须在GAC（全局程序集缓存）：打开DOS终端并输入：
cd \Windows\System32
regsvr32 /i msvcr71.dll
重新启动应用程序！
评论
Dependency Walker很棒，但是将随机DLL从Internet复制到Windows的效果却不太好。最好尝试找到提供这些dll的安装程序。
– RJFalconer
16-10-13在12:34
我找不到一些文件（API-MS-WIN-CORE-KERNEL32-PRIVATE-L1-1-1.DLL），这使我想到了这个stackoverflow问题。基本上请记住，某些文件可能会出现误报，链接提供了更多详细信息。
– Cheriejw
18年5月15日1:00
#6 楼
尽管最初的问题是在5年前发布的，但问题仍然存在，而且很烦人。一般的解决方案是对所有引用的程序集进行全面分析，以了解问题所在。为了简化此任务，我制作了一个工具（Visual Studio扩展），该工具允许选择.NET程序集（
.dll或.exe文件），以获取所有被引用程序集的图形，同时突出显示冲突或丢失的引用。 Visual Studio Gallery中提供了该工具：https://marketplace.visualstudio.com/vsgallery/051172f3-4b30-4bbc-8da6-d55f70402734
输出示例：
评论
不适用于Visual Studio的社区版本
–Draex_
17年9月8日在18:29
我相信应该还有另一个问题，与Visual Studio版本无关。我在VS 2017和VS 2015社区版本上测试了该扩展。实际上，它是通过VS 2017 Community Edition开发的。
– marss19
2017年9月9日19:22
啊哈您是否还安装了其他扩展程序？此页面说VS社区不支持DGML：msdn.microsoft.com/en-us/library/hh871439.aspx#VersionSupport
–Draex_
17年9月9日在20:17
社区版中没有体系结构工具，但是DGML编辑器本身可用。您可以通过Visual Studio Installer-> Modify在“单个组件”->“代码工具”下选择“安装DGML编辑器”进行安装。
– marss19
17-10-16在18:37
#7 楼
Microsoft Enterprise Library（由.NetTiers引用）是我们的问题，而后者又引用了旧版本的Unity。为了解决该问题，我们在web.config中使用了以下绑定重定向： 。#8 楼
以下是对我有用的。 br删除并添加相同的DLL（注意：添加相同的匹配版本）#9 楼
检查项目中的Web.config / App.config文件。看看版本号是否正确。<bindingRedirect oldVersion="X.X.X.X-X.X.X.X" newVersion="X.X.X.X" />
这对我有用。
评论
这对我有用，尽管它是web.config，而不是app.config
–讽刺
18年1月12日在2:50
#10 楼
在解决方案资源管理器中，右键单击项目（不是解决方案），在“构建”选项卡中选择“平台目标：任何CPU”。 评论
检查应用程序池后，“启用32位应用程序”设置为False，但是我的平台目标是x86。将其更改为任何CPU或x64可以解决我的问题。
– Keith Ketterer
18年11月30日在15:17
为我工作这项工作感谢您的信息
–阿贡潘端
12月7日4:47
#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>
另请参见：
AssemblyVersion，AssemblyFileVersion和AssemblyInformationalVersion之间有什么区别？
#12 楼
我也遇到了这个可怕的错误，并为此找到了解决方案...右键单击解决方案名称
单击“清洁解决方案”
重新启动Visual Studio
转到项目属性>>生成
将配置更改为Release
开始调试（F5）
1） ，2）
4），5）
希望也能为您提供帮助。
#13 楼
转到：解决方案->包
单击“高级”选项卡（在页面下方查找）
将dll添加到其他程序集中（这样我们可以在sharepoint中添加外部dll）。
评论
我的VS2010项目中没有“解决方案->程序包”
– Muflix
2015年7月1日在14:11
#14 楼
不确定这是否有帮助。检查程序集的属性中的程序集名称和默认名称空间是否匹配。这解决了我的问题，并产生了相同的错误。
评论
优秀的！我的dll文件名和名称空间不同，我复制了名称空间并重命名了dll。
–汗
1月20日6:03
#15 楼
就我而言，bin文件夹中有一个名为Unity.MVC3的非引用dll，我试图在Visual Studio中搜索对该引用的任何引用都没有成功，因此我的解决方案非常简单，就像从bin文件夹中删除该dll一样。#16 楼
谢谢RiddhiM。以下为我工作了。
删除临时文件C：\ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Temporary ASP.NET文件
关闭VSTS并再次打开
删除并添加相同的DLL（注意：添加相同的匹配版本）
评论
花了这么长时间，我不敢相信这就是答案。当您在VS中看到一些奇怪的行为时，通常是不错的解决方案。谢谢。
–Bonez024
18 Mar 23 '18 at 20:12
#17 楼
我遇到了同样的问题，可通过以下说明解决：打开工具菜单，然后在选项中选择选项
，然后转到“项目和解决方案/ Web项目”。 >检查
use the 64bit version of IIS ... 
#18 楼
您说您的解决方案中有很多项目……好吧，从构建顺序顶部附近的项目开始。构建该代码，一旦弄清楚，便可以对其余代码应用相同的修复程序。老实说，您可能只需要刷新参考即可。听起来您要么更新了版本而没有更新引用，要么将解决方案保留在源代码管理中是相对路径问题。只需验证您的假设，然后重新添加参考即可。
#19 楼
以下为我工作。删除临时文件C：\ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Temporary ASP.NET文件
然后右单击“临时Asp.net文件”>“属性”>“安全性”，然后授予对IIS以及运行我的项目的所有用户的完全控制访问权限
#20 楼
发生此问题的原因是我的一个依赖库中的一个正在使用“ Any CPU”编译一个DLL，而父库则希望编译一个“ x64”。评论
stackoverflow.com/questions/516730/…
–迈克·洛里（Mike Lowery）
6月8日21:54
#21 楼
您必须从输出文件夹中删除您的appname.dll文件。清理调试和发布文件夹。
重建并复制到输出文件夹中已重新生成的dll文件。
#22 楼
我将已卸载/未找到的库/项目“设置为启动项目”。然后部署它。
它起作用了！
我认为它不能找不到.dll，因为它最初不在程序集中。
#23 楼
如果通过在Windows XP上打开应用程序而收到此错误消息，则意味着首先安装该应用程序是因为该应用程序在没有Net Framework 4和Service Pack 3的情况下无法正常工作。您一次又一次安装了此错误，因此您应该再次重新安装该应用程序，但先从添加并删除进行卸载，如果这不起作用，请不要滥用我。我也是大三学生
#24 楼
另一个可能的原因：确保您没有意外地在项目属性中为两个项目都赋予了相同的程序集名称。评论
这花了我几个小时才能弄清楚...。我不小心将我的单元测试项目命名为与主项目相同的名称，因此，单元测试项目dll必须已经覆盖了项目dll。
– Iannazzi
18年8月22日在13:15
#25 楼
我使用企业库5的.NET 4.0解决方案是添加对以下内容的引用：Microsoft.Practices.Unity.Interception.dll
#26 楼
找出冲突的参考。即使经过清理和重建，冲突的引用仍然会造成问题。我的问题出在AForge和Accord之间。我删除了两个引用，然后重新添加了引用，重新选择了特定的引用（对于我的情况，只是Accord）。#27 楼
对我来说，在没有Unity C＃项目Checkmark的情况下重建统一游戏非常有用。#28 楼
对于我来说，没有一个建议的答案有效。这对我有用：
删除引用
重命名DLL
再次导入参考文件
第二步很重要，因为没有它，它就无法工作。
#29 楼
尝试检查参考的“复制到本地”属性是否设置为true，并且特定版本设置为true。这与Visual Studio中的应用程序有关。#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>
更改为以上内容，瞧！一切又恢复了。
评论
您引用的任何程序集都可以在旧的Unity库中使用某些东西吗？可能...但是如何找到哪个程序集？我的解决方案中有很多项目，而且有很多潜在的嫌疑人...反复试验蛮力似乎有点无望...
它不是程序集引用，而是引用版本2.0。但是在运行时，CLR正在找到1.2（旧版本）。如果在构建目录中没有看到旧的DLL，请使用Fuslogvw.exe找出CLR如何找到此旧副本。
查看项目的bin文件夹，查看项目的dll名称是否冲突。只需删除一个，然后重建您的解决方案。对我有用。
“或其依赖项之一”确实让我很烦。如果它无法加载“其依赖项之一”，则错误应说明无法加载“其依赖项之一”。当前形式是无用的，可能还说不能加载thinggy