无法加载文件或程序集或其依赖项之一
我有另一个这样的“无法加载文件或程序集或其依赖关系”的问题。
其他信息：无法加载文件或程序集“Microsoft.Practices.Unity，Version = 1.2.0.0，Culture = neutral，PublicKeyToken = 31bf3856ad364e35”或其某个依赖项。 定位的程序集清单定义与程序集引用不匹配。 （来自HRESULT的exception：0x80131040）
我不知道是什么原因造成的，或者我可以怎样debugging才能find原因。
我已经在我的解决scheme目录.csproj文件和我拥有的Unity中的每个位置进行search：
Reference Include =“Microsoft.Practices.Unity，Version = 2.0.414.0，Culture = neutral，PublicKeyToken = 31bf3856ad364e35，processorArchitecture = MSIL”
在我的任何项目中都找不到任何引用1.2.0.0的引用。
任何想法如何我应该去解决这个问题？
我也希望提示如何debugging这样的问题。
-
检查是否引用了一个依次引用旧版本统一的程序集。 例如，假设您有一个名为
ServiceLocator.dll的程序集，它需要一个旧版本的Unity程序集，现在当您引用ServiceLocator您应该提供旧版本的Unity，并且这会造成问题。 -
可能是所有项目构build程序集的输出文件夹，具有旧版本的统一性。
您可以使用FusLogVw来找出谁正在加载旧程序集，只需定义日志的path，然后运行解决scheme，然后检查（在FusLogvw中）Unity程序集加载的第一行，双击它并看到调用大会，在这里你走。
打开IISpipe理器
select应用程序池
然后select您正在使用的游泳池
进入高级设置（在右侧）
将启用32位应用程序的标志更改为true。
尝试清理解决scheme中的debugging和发布文件夹。 然后删除并再次添加统一。
对我来说，其他的解决scheme都没有工作（包括清理/重build战略）。 我发现另一个解决方法是closures并重新打开Visual Studio 。
我想这迫使Visual Studio重新加载解决scheme和所有项目，重新检查过程中的依赖关系。
微软企业库（被.NetTiers引用）是我们的问题，反过来引用了旧版本的Unity。 为了解决这个问题，我们在web.config中使用了下面的绑定redirect：
<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>
或者，您可能只想将企业库更新到最新版本。
以下为我工作。
- 删除临时文件C：\ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Temporary ASP.NET文件
- closuresVSTS并再次打开
- 删除并添加相同的DLL（注意：您添加相同的匹配版本）
在99％的“无法加载文件或程序集或其依赖项之一”的问题是由依赖关系造成的！ 我build议你按照这个步骤：
1）从http://www.dependencywalker.com/下载“Dependency Walker”
2）启动“Dependency Walker”并打开dll（在我的例子中是“NativeInterfaces.dll”）
3）你可以看到一个或多个DLL的错误红色“错误打开文件…”
4）这意味着你的系统中缺less这个DLL; 在我的情况下，DLL的名称是“MSVCR71.DLL”
5）你可以从谷歌下载错误的DLL并复制到正确的path（在我的情况下c：\ windows \ system32）
6）此时，您必须在GAC（全局程序集caching）中注册新的dll：打开一个DOSterminal并写入：
cd \Windows\System32 regsvr32 /i msvcr71.dll
7）重新启动您的应用程序！
检查项目中的App.config文件。 看看版本号是否正确。
<bindingRedirect oldVersion="XXXX-XXXX" newVersion="XXXX" />
这对我有效。
我有类似的问题。 Junto的答案将解决这个问题，但你应该注意一个重要的提示！
在统一版本2.1.505.2中设置不同的AssemblyVersion和AssemblyFileVersion ：
AssemblyFileVersion由nuget使用，但CLR不关心AssemblyFileVersion ，它将只使用AssemblyVersion ！
因此，对于版本2.1.505.2，redirect应该应用于在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之间有什么区别？
- 转到： 解决scheme – > 包
- 点击高级选项卡（在页面下方查找）
- 将你的dll添加到其他程序集（这样我们可以在sharepoint中添加外部dll）。
不知道这是否有帮助。
检查组件名称中的程序集名称和默认名称空间是否匹配。 这解决了我的问题，产生了相同的错误。
我也有这个可怕的错误，并find了一个解决scheme…
- 右键单击解决scheme名称
- 点击Clean Solution
- 重新启动Visual Studio
- 转到项目属性>>构build
- 将configuration更改为发布
- 开始debugging（F5）
1），2）
4），5）
希望这也能帮助你。
在解决scheme资源pipe理器右键单击项目（而不是解决scheme），在生成选项卡中select平台目标：“任何CPU”。
你说你的解决scheme中有很多项目……好吧，从一个靠近构build顺序的顶端开始。 得到一个build立，一旦你弄明白，你可以应用相同的修复程序，其余的。
老实说，你可能只需要刷新你的参考。 这听起来像你更新你的版本，并没有更新引用，或者如果你的解决scheme保持在源代码控制，这是一个相对path问题。 只要validation你的假设，并重新添加参考。
尽pipe5年前发布的原始问题仍然存在，相当烦人。
通用的解决scheme是全面分析所有引用的程序集，以了解发生了什么问题。 为了使这个任务更容易，我做了一个工具（一个Visual Studio扩展），它允许select一个.Net程序集（.ddl或.exe文件），并获取所有引用程序集的高亮冲突或遗漏引用的graphics。
该工具在Visual Studio库中可用： https ： //marketplace.visualstudio.com/vsgallery/051172f3-4b30-4bbc-8da6-d55f70402734
输出示例： 
我“设置为启动项目”卸载/ unfound库/项目。
然后部署它。
有效！
我认为它不能find.dll，因为它一开始并不在程序集中。
在我的情况下，在bin文件夹是一个非参考的DLL名为Unity.MVC3，我试图在Visual Studio中search任何引用没有成功，所以我的解决scheme很容易，从bin文件夹中删除该DLL。
这个问题发生在我的一个依赖库正在编译一个带有“任何CPU”的DLL，当父库希望编译“x64”时。
您必须从您的输出文件夹中删除您的appname.dll文件。 清理debugging和发布文件夹。 重build并复制到输出文件夹重新生成的dll文件。
如果您通过在Windows XP上打开应用程序而收到此错误消息，则意味着首先安装了该应用程序，因为没有使用networking框架4和Service Pack 3，该应用程序无法正常工作。 你安装了两个，然后再次出现这个错误，所以你应该重新安装该应用程序，但首先从添加和删除卸载
如果这不起作用，请不要滥用我。 我也是一个初中
好吧，这听起来可能很愚蠢，但是如何在尝试了所有其他解决scheme并在这个愚蠢的事情上度过了一个夜晚之后解决了这个问题。
我遇到了一些DLL文件夹丢失的错误。 我尝试删除，从Team Foundation Server取回所有的东西，但没有工作。 从我的office-matelocal机器中获得了Bin文件夹的副本，并将其replace。 它也没有工作。 最后，我手动FTPed服务器，得到的DLL的副本显示为缺less，然后开始显示文件列表序列中的下一个文件丢失。
所以我ftped服务器得到所有斌文件夹，手动逐个replace每个文件。 （不Ctrl +全部和replace..我试过了：它没有工作。）而且不知何故，它工作…
另一个可能的原因：确保你没有在项目属性中意外地给两个项目使用相同的程序集名称。
以下为我工作。
- 删除临时文件C：\ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Temporary ASP.NET文件
- 然后右键单击Temporary Asp.net文件>属性>安全性，并授予对IIS和所有用户运行我的项目的全面控制访问
对于使用Enterprise Library 5的.NET 4.0，我的解决scheme是添加一个对以下内容的引用：
Microsoft.Practices.Unity.Interception.dll
感谢Riddhi M.以下为我工作。
删除临时文件C：\ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Temporary ASP.NET文件closuresVSTS并再次打开删除并添加相同的DLL（注意：您添加相同的匹配版本）
注意有冲突的参考。 即使在清理和重build之后，冲突的引用仍然会导致问题。 我的问题是在AForge和雅阁之间。 我删除了两个引用，并重新添加引用重新select特定的引用（特别是我的情况，只是雅阁）。
对于我来说，重build没有Unity C＃Proects Checkmark工作的统一游戏。
在我的情况下，没有提出的答案工作。
这是什么对我有用：
- 删除参考
- 重命名该DLL
- 再次导入参考
显然，第二步显得非常重要，因为如果没有它，工作就不可行。
尝试检查引用的“复制到本地”属性是否设置为true，并将特定版本设置为true。 这与Visual Studio中的应用程序有关。
我有这个问题，这个错误其实很愚蠢。 我已经指定了.dll文件的错误位置，将位置更改为正确的位置后，加载正确发生（回答所以别人不会犯这个错误）。
