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

附加信息:无法加载 文件或程序集 “Microsoft.Practices.Unity, Version = 1.2.0.0、文化=中立, 都31 bf3856ad364e35”或 它的依赖项之一。在位于 程序集的显式定义可以 不匹配程序集引用。 (异常来自HRESULT: 0x80131040)

我不知道是什么导致了这种情况,也不知道如何调试它来找到原因。

我在我的解决方案目录.csproj文件中做了一个搜索,我有Unity的每个地方:

参考 包括= " Microsoft.Practices.Unity, Version = 2.0.414.0、文化=中立, 都31 bf3856ad364e35, processorArchitecture = MSIL”

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

我该怎么解决这个问题呢?


当前回答

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

你可以使用FusLogVw找出谁在加载旧的程序集,只需要为日志定义一个路径,并运行你的解决方案,然后检查(在FusLogVw中)Unity程序集加载的第一行,双击它并查看调用程序集,然后就可以了。

其他回答

对我来说,这是一个奇怪的解决方案,但我刚刚从源代码控制中获取了这个解决方案。

正在得到此错误,检查了上面的大部分答案,然后删除解决方案并从源代码控制中重新拉出解决方案。

工作。

只会适用于少数人,但我想我是少数人之一,所以会有更多。不知道第一次发生了什么,但不知怎的,当我把它们拉过去时,一些程序集肯定有一些问题。

基本上就是把它关掉再打开。

TLDR; 我的解决方案是在visual studio中恢复默认设置。


我在visual studio 2019社区版上,我在不同的项目中遇到了同一个dll文件的问题,我没有接触过。

After trying out all the answers in this question (as of 2020-07-22 7:13UTC) I decided to repair visual studio installation (backed up my settings beforehand). After installation opened the solutions that had the problem and the problem was gone. After that imported my settings that and the problem came back!! So without repairing visual studio installation again (which takes a few minutes + one restart) I've simply restored VS default settings and then it works. If I end up having time to investigate, I'll edit the answer and pinpoint the underlaying issue

在99%时,无法加载文件或程序集或其依赖项之一的问题是由依赖项引起的!我建议你遵循以下步骤:

从http://www.dependencywalker.com/下载Dependency Walker 启动Dependency Walker并打开dll(在我的例子中是NativeInterfaces.dll) 您可以看到一个或多个dll的错误在红色错误打开文件…

这意味着这个dll在你的系统中丢失了;在我的情况下,dll名称是MSVCR71.DLL 您可以从谷歌下载丢失的dll,并复制到正确的路径(在我的情况下c:\windows\system32) 此时,您必须在GAC(全局程序集缓存)中注册新的dll:打开DOS终端并写入: cd \ Windows \ System32系统 Regsvr32 /i msvcr71.dll 重新启动应用程序

下面的方法对我很有效。

删除临时文件C:\Windows\Microsoft.NET\Framework\v4.0.30319\临时ASP. net网络文件 关闭VSTS,然后重新打开 删除和添加相同的dll(注意:您添加了相同的匹配版本)

Juntos的答案是正确的,但你也应该考虑:

对于unity 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之间有什么区别?