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

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

你说你的解决方案中有很多项目……好吧，从接近构建顺序顶部的一个开始。建立一个，一旦你找到它，你可以应用相同的修复其余的。

老实说，你可能只需要更新一下你的推荐信。这听起来像是您更新了版本而没有更新引用，或者如果您将解决方案保留在源代码控制中，这是一个相对路径问题。只需验证您的假设，并重新添加参考。

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

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

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

对我来说，其他的解决方案都不起作用(包括清洁/重建策略)。我找到了另一个变通的解决方案，这是关闭并重新打开Visual Studio。

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

不确定这是否有帮助。

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

微软企业库(由. 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>

或者，您可能只想将Enterprise Library更新到最新版本。

下面的方法对我很有效。

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

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

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

然后进行部署。

它工作!

我认为它找不到.dll，因为一开始它不在程序集中。

• Goto:解决方案 -> 包
• 点击先进的标签(在页面下面找到)
• 将您的dll添加到其他程序集(这样我们可以在sharepoint中添加外部dll)。

打开IIS管理器

选择应用程序池

然后选择您正在使用的池

进入高级设置(在右侧)

将“启用32位应用程序”的标志为true。

如果你在Windows xp上打开一个应用程序时得到这个错误消息，这意味着你首先安装了这个应用程序，因为它不能在没有net framework 4和service pack 3的情况下工作。你安装了两者，再次得到这个错误，所以你应该重新安装该应用程序，但首先从添加和删除卸载

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

好吧，这听起来可能很愚蠢，但在尝试了所有其他解决方案并花了一个晚上在这个愚蠢的事情上之后，我是如何解决这个问题的。

我得到了相同的错误，一些DLL从Bin文件夹中丢失。 我试着删除，从teamfoundationserver上恢复所有东西，但没有用。 从我办公室的本地电脑上拿了一份Bin文件夹，把它换掉了。它也没起作用。 最后，我手动ftp服务器，得到了显示为丢失的DLL副本，然后它开始显示文件列表序列中的下一个文件丢失。< / p >

所以我ftped服务器得到所有的Bin文件夹，手动替换每个文件一个接一个。(不是Ctrl + All和替换..我试过了，但没有用。) 不知怎的，它起作用了……< / p >

我有这个问题，这个错误其实很愚蠢。我为.dll文件指定了错误的位置，在将位置更改为正确的位置后，加载发生了正确的情况(回答，所以其他人不会犯这个错误)。

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

对于unity v2.1.505.2，指定了不同的AssemblyVersion和AssemblyFileVersion属性:

AssemblyFileVersion被NuGet使用，但CLR不关心它! CLR将只使用AssemblyVersion!< / p >

所以你的重定向应该应用到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>

另一个可能的原因是:确保没有意外地在项目属性中为两个项目指定相同的程序集名称。

下面的方法对我很有效。

移除临时文件C:\Windows\Microsoft.NET\Framework\v4.0.30319\临时ASP. net网络文件
• 然后右键单击临时Asp.net文件>属性>安全 并给予IIS和所有运行我的项目的用户完全控制访问权限 李< / ul > < / >

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

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

这对我很管用。

我的。net 4.0的解决方案，使用企业库5，是添加一个引用:

Microsoft.Practices.Unity.Interception.dll

我也得到了这个可怕的错误，并找到了一个解决方案…

1. 右键单击解决方案名称
2. 点击清洁溶液
3. 重启Visual Studio
4. 去项目属性>>构建
5. 将配置更改为释放
6. 开始调试(F5)

1)、2)

.

4)、5)

希望这也能帮助到你。

在我的情况下，bin文件夹是一个名为Unity的非引用dll。MVC3，我试图在visual studio中搜索任何参考，没有成功，所以我的解决方案很简单，从bin文件夹中删除那个dll。

注意相互矛盾的参考资料。即使在清理和重新构建之后，冲突的引用仍然会导致问题。我的问题是在AForge和Accord之间。我删除了这两个引用，并重新添加了引用，重新选择了特定的引用(针对我的情况，只是Accord)。

对我来说，在没有unity c# Projects Checkmark的情况下重建unity游戏是可行的。

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

1. 从http://www.dependencywalker.com/下载依赖沃克

2. 启动依赖沃克并打开dll(在我的例子中是NativeInterfaces.dll)

3. 你可以看到一个或多个带有红色错误打开文件出错…的dll

.

4. 这意味着该dll在您的系统中丢失;在我的情况下，dll名称是MSVCR71.DLL

5. 你可以从谷歌下载丢失的dll，并复制到正确的路径(在我的情况下c:\windows\system32)

6. 在这一点上，您必须在GAC(全局程序集缓存)中注册新的dll:打开DOS终端并写入:

    cd \Windows\System32
   regsvr32 /i msvcr71.dll
   

7. 重启应用程序

在我的案例中，这些提议的答案都不起作用。

以下是对我有效的方法:

1. 删除引用
2. 重命名DLL
3. 再次导入引用

第二步显然很重要，因为没有它就不能工作。

尝试检查引用的“Copy to Local”属性是否设置为true，并且特定版本是否设置为true。这与Visual Studio中的应用程序相关。

我的解决方案是:

我有一个三层应用程序，我忘记将DLL也复制到IIS的正确路径。只要复制到正确的位置，它就为我工作了。

__abc0在解决方案资源管理器中右键单击项目(不是解决方案)，在构建选项卡中选择平台目标:“任何CPU”。

这个问题发生在我身上，我的一个依赖库正在用“Any CPU”编译DLL，而父库期望编译“x64”。

我一直在visual studio 2015的web表单项目上得到这个错误。我关闭了VisualStudio，我杀死了ScriptedSandbox64.exe, Microsoft.VsHub.Server.HttpHostx64.exe, Microsoft.VsHub.Server.HttpHostx.exe *32, Microsoft.VisualStudio.Web.Host.exe *32进程，它似乎有助于解决问题。

我今天遇到了这个问题，对我来说，这个问题非常奇怪:

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

改成上面的，瞧!一切都恢复正常了。

尽管最初的问题是五年前发布的，但这个问题仍然存在，而且相当烦人。

一般的解决方案是彻底分析所有引用的程序集，以了解哪里出了问题。为了使这个任务更容易，我做了一个工具(Visual Studio扩展)，它允许选择一个。net程序集(.dll或.exe文件)来获得所有引用程序集的图形，同时突出显示冲突或缺失的引用。

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

输出示例: < / p >

对我来说，似乎Nuget并没有很好地处理我的项目/解决方案。我用Nuget安装了NewtonSoft。项目文件似乎正确地引用了它，当我在解决方案资源管理器/依赖项/Nuget中r -点击dll名称时，然后单击属性，我发现dll存在于属性说它应该在的地方。

我删除了Nuget包，并做R-click项目>添加>引用，并浏览到包目录中的dll，当以前的Nuget进程已经安装它时，然后解决方案运行良好。

注意:这个解决方案相当大杂烩，首先是Xamarin。iOS解决方案和添加。net标准项目(这是我使用Nuget有困难的地方)。解决方案中还有一个“可移植”项目。我从一个已经离开3年的开发者那里继承了所有这些。哈哈。

我遇到了同样的问题，我通过下面的说明解决了它:

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

我有一个c# Winforms项目，名为SetTags，其中有大量的表单，我使用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版本。

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

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

工作。

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

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

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

这里增加Assembly和Assembly file版本并重新构建。

如果这行不通，

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

2 -关闭Visual Studio。

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

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

我在这个问题上也浪费了几个令人沮丧的小时。我们不得不更新我们的. net框架版本，并开始得到多个“无法加载文件或程序集或其依赖项之一”的dll，这些dll多年未更改。奇怪的是，在错误消息中搜索的版本都非常旧。例如，它正在搜索Newtonsoft。Json版本为6.0.0，而我们已经使用8.0.1很多年了。

回到这些古老的版本不是一个选择，无论如何，在我们的网络中有一堆bindingRedirect元素。配置文件，应该重定向到旧dll到新dll的调用。回滚。net版本可以消除这些错误，但我们需要新版本。这是怎么回事?

web中的<runtime>元素。配置文件包含元素:

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

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

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

本例中的解决方案是完全删除appliesTo属性。

您的项目的csproj文件必须包含Microsoft.Practices.Unity的包引用，在global-packages文件夹(%userprofile%.nuget\packages)中找不到，运行dotnet restore可以解决这个问题

搞定了。：）

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

在尝试了这个问题中的所有答案后(截至2020-07-22 7:13UTC)，我决定修复visual studio安装(事先备份了我的设置)。安装后打开解决方案，问题就消失了。然后导入我的设置，问题又回来了!!所以没有重新修复visual studio的安装(这需要几分钟+一次重启)，我只是简单地恢复了VS的默认设置，然后它就工作了。如果我最后有时间调查，我会编辑答案并找出潜在的问题

我执行以下操作来确定无法找到哪个依赖项。

运行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，它是这些融合日志的查看器。在我的机器上可以在多个地方找到它，包括:

C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7.2 Tools\x64\FUSLOGVW.exe

尝试按照建议关闭和重新打开VS，但没有成功。

我不得不改变从混合平台到任何CPU。