.NET程序集加载器：

找不到1.2.0.203但确实找到了1.2.0.200

此程序集与请求的程序集不匹配，因此会出现此错误。

简单地说，它找不到被引用的程序集。通过将程序集放在GAC或应用程序路径中，确保它可以找到正确的程序集。

运行以下命令将程序集dll文件添加到GAC：

gacutil /i "path/to/my.dll"

另请参见https://learn.microsoft.com/archive/blogs/junfeng/the-located-assemblys-manifest-definition-with-name-xxx-dll-does-not-match-the-assembly-reference.

您可以做一些事情来解决此问题。首先，使用Windows文件搜索在硬盘上搜索程序集（.dll）。一旦有了结果列表，请执行查看->选择详细信息。。。然后选中“文件版本”。这将在结果列表中显示版本号，因此您可以看到旧版本可能来自何处。

此外，正如Lars所说，检查您的GAC，看看那里列出了什么版本。这篇Microsoft文章指出，在生成过程中，在GAC中找到的程序集不会在本地复制，因此您可能需要在全部重新生成之前删除旧版本。（有关创建批处理文件以执行此操作的说明，请参见我对此问题的回答）

如果仍然无法确定旧版本的来源，可以使用Visual Studio附带的fuslogvw.exe应用程序获取有关绑定失败的详细信息。Microsoft在此处提供了有关此工具的信息。请注意，您必须通过将HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLog注册表项设置为1来启用日志记录。

我刚刚遇到了这个问题，问题是我的应用程序调试目录中有一个旧的.dll副本。您可能还想在那里（而不是GAC）查看是否看到它。

我自己遇到了这个问题，我发现这个问题与其他人遇到的问题不同。

我的主项目引用了两个dll：CompanyClasses.dll和CompanyControls.dll

无法加载文件或程序集'CompanyClasses，版本=1.4.1.0，培养=中性，PublicKeyToken=045746ba8544160c'或它的一个依赖项。位于程序集的清单定义与程序集引用不匹配

问题是，我的系统中没有版本号为1.4.1的CompanyClasses.dll文件。GAC中没有，应用程序文件夹中没有。。。任何地方都没有。我搜索了整个硬盘。我所有的CompanyClasses.dll文件都是1.4.2。

我发现，真正的问题是CompanyControls.dll引用了CompanyClasses.dll的1.4.1版本。我刚刚重新编译了CompanyControl.dll（在引用CompanyClasss.dll 1.4.2之后），这个错误就消失了。

对我们来说，问题是由其他原因造成的。DevExpress组件的许可证文件包含两行，一行用于未安装在此特定计算机上的旧版本组件。从许可证文件中删除旧版本解决了问题。

令人讨厌的是，错误消息没有指出是什么引用导致了问题。

尝试将缺少的内容添加到全局程序集缓存中。

如果您正在使用Visual Studio，请尝试“清理解决方案”，然后重新生成项目。

如果尝试使用反射进行后期绑定，如果绑定到的程序集具有强名称或其公钥标记已更改，则会引发完全相同的错误。即使实际上没有使用指定的公钥令牌找到任何程序集，错误也是一样的。

您需要添加正确的公钥令牌（可以使用dll上的sn-T获取它）以解决错误。希望这有帮助。

我的情况与内森·贝德福德的帖子非常相似，但有一点扭曲。我的项目也以两种方式引用了更改的dll。1） 直接和2）间接地通过引用组件（类库），该组件本身具有对更改的dll的引用。现在，我的组件（2）Visual studio项目引用了更改的dll的正确版本。但是，组件本身的版本号没有更改。因此，安装新版本的项目未能替换客户端计算机上的组件。

最终结果：直接引用（1）和间接引用（2）指向客户端计算机上更改的dll的不同版本。在我的开发机器上，它工作得很好。

解决方案：删除应用程序；从应用程序文件夹中删除所有DLL；重新安装。在我的情况下，就这么简单。

右键单击VS中的引用，将“特定版本”属性设置为True。

在我的例子中，它是C:\WINDOWS\Microsoft.NET\Framework\~\Temporary ASP.NET Files\目录中的旧版本DLL。您可以删除或替换旧版本，也可以删除并添加回对项目中DLL的引用。基本上，任何一种方法都将创建指向临时ASP.NET文件的新指针。

由于引用了与我正在生成的程序集同名的程序集，我收到了此错误消息。

这已编译，但它用当前项目程序集覆盖引用的程序集，从而导致错误。

为了解决这个问题，我更改了项目的名称，并通过右键单击项目并选择“财产”来更改可用的程序集财产。

我会让别人从我的愚蠢中受益。我对一个完全独立的应用程序有一些依赖性（让我们称之为App1）。来自App1的dll被拉入我的新应用程序（App2）。每当我在APP1中进行更新时，我都必须创建新的dll并将其复制到App2中。好我厌倦了在两个不同的App1版本之间复制和粘贴，所以我只是在dll中添加了一个“NEW_”前缀。

好我猜构建过程会扫描/bin文件夹，当它不正确地匹配某个内容时，会弹出与上面提到的相同的错误消息。我删除了我的“新版本”，它做得很好。

我的问题是将源代码复制到一台新机器上，而不覆盖任何引用的程序集。

我没有采取任何措施来纠正错误，所以匆忙中，我删除了BIN目录。重新构建了我的源代码，从那时起就开始工作了。

我只是找到了另一个原因，为什么会出现这个错误。我从特定库的所有版本中清理了我的GAC，并参照与可执行文件一起部署的特定版本构建了我的项目。当我运行这个项目时，我在搜索库的更新版本时遇到了这个异常。

原因是发布者策略。当我从GAC卸载库的版本时，我忘了卸载发布者策略程序集，所以程序集加载器在GAC中找到发布者策略，告诉它搜索新版本，而不是使用本地部署的程序集。

我在尝试更新网站的一个DLL文件时遇到了类似的问题。

当我简单地通过FTP将此DLL文件复制到bin文件夹时，发生了此错误。

我通过以下方式解决了此问题：

停止网站；复制所需的DLL文件/DLL文件；启动网站

我的app.config包含

<bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.11.0"/>

对于npgsql。不知怎么的，在用户的计算机上，我的app.exe.config丢失了。我不确定这是否是一个愚蠢的用户，安装程序故障，或是杀毒软件出了问题。替换文件解决了问题。

以下命令将任何程序集版本重定向到3.1.0.0版本。我们有一个脚本，它将始终更新App.config中的此引用，因此我们再也不用处理此问题了。

通过反射，您可以获取程序集publicKeyToken，并从.dll文件本身生成此块。

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
 <dependentAssembly>
    <assemblyIdentity name="Castle.Core" publicKeyToken="407dd0808d44fbdc" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="3.1.0.0" />
  </dependentAssembly>
</assemblyBinding>

注意，如果没有XML命名空间属性（xmlns），这将无法工作。

对我来说，“Local.testtestings”文件中的代码覆盖率配置“导致”了问题。我忘了更新那里引用的文件。

我在运行单元测试用例时遇到了同样的问题。

错误清楚地说明了问题：当我们尝试加载程序集时，.NET程序集加载器会根据其清单数据（引用的程序集名称、公钥令牌、版本）加载其引用的程序。

要检查清单数据，请执行以下操作：

打开Visual Studio命令提示符，键入“ildasm”并将所需的程序集拖到ildasm窗口并打开MANIFEST视图。有时MANIFEST包含一个具有两个版本的程序集，即旧版本和新版本（如Utility，版本=1.2.0.200和Utility，版本=1.2.0203）。实际上，引用的程序集是Utility，版本为1.2.0.203（新版本），但由于清单甚至包含Utility，版本=1.2.0.200（旧版本），.NET程序集加载器尝试查找此版本的DLL文件，找不到，因此引发异常。

要解决这个问题，只需将每个依赖于项目的程序集分别拖到ILDASM窗口中，并检查哪个依赖程序集保存旧程序集版本的清单数据。只需重新生成此依赖程序集并将其引用回项目。

其他答案对我不起作用。如果你不在乎版本，你只是想让你的应用运行，那么右键单击引用并将“特定版本”设置为false。。。这对我有用。

我想补充一下，我正在创建一个基本的ASP.NET MVC 4项目，并通过NuGet添加了DotNetOpenAuth.AspNet。在我引用Microsoft.Web.WebPages.OAuth的不匹配DLL文件后，这导致了相同的错误。

为了修复它，我做了一个更新包，并清理了完整重建的解决方案。

这对我来说很有效，有点懒，但时间就是金钱：-P

在AssemblyInfo.cs文件中的AssemblyVersion中，使用固定版本号，而不是指定*。*将更改每次编译的版本号。这就是我这个例外的问题所在。

我在使用内部包存储库时遇到了这个问题。我已经将主包添加到内部存储库中，但没有添加包的依赖项。确保将所有依赖项、依赖项的依赖项、递归等也添加到内部存储库中。

我添加了一个NuGet包，结果发现我的应用程序的黑盒部分引用了旧版本的库。

我删除了包并引用了旧版本的静态DLL文件，但web.config文件从未从以下位置更新：

<dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
    <bindingRedirect oldVersion="0.0.0.0-4.5.0.0" newVersion="6.0.0.0" />
</dependentAssembly>

恢复到卸载包时应该恢复的状态：

<dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.5.0.0" />
</dependentAssembly>

从文件夹位置手动删除旧程序集，然后将引用添加到新程序集可能会有所帮助。

我今天遇到了同样的问题，在我对实体框架进行了更改后，我无法执行添加迁移。

我的解决方案中有两个项目，我们称它们为“客户端”和“数据”，这是一个包含我的EF模型和上下文的类库项目。客户参考了数据项目。

我已经签署了两个项目，然后对EF模型进行了修改。删除签名后，我可以添加迁移，然后可以重新签署项目。

我希望这对某人有用，避免他们长期受挫。。

我在开始使用InstallShield后遇到了这个问题。尽管建造订单显示安装项目是最后一个，但它的建造仍不正常。

我纠正了这一点，使每个其他项目都依赖它-这迫使安装最后构建，从而消除了我的程序集不匹配。我希望这有帮助。

就我而言，问题出在椅子和键盘之间：-）

Could not load file or assembly 'DotNetOpenAuth.Core, Version=4.0.0.0,
Culture=neutral, PublicKeyToken=2780ccd10d57b246' or one of its dependencies.
The located assembly's manifest definition does not match the assembly reference.
(Exception from HRESULT: 0x80131040)

两个或多个不同的程序集希望使用不同版本的DotNetOpenAuth库，这不是问题。此外，在我的本地计算机上，NuGet自动更新了web.config：

<dependentAssembly>
    <assemblyIdentity name="DotNetOpenAuth.AspNet" publicKeyToken="2780ccd10d57b246" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
    </dependentAssembly>
    <dependentAssembly>
        <assemblyIdentity name="DotNetOpenAuth.Core" publicKeyToken="2780ccd10d57b246" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
</dependentAssembly>

然后我意识到我忘记了将新的web.config复制/部署到生产服务器。因此，如果您有手动部署web.config的方法，请检查它是否已更新。如果生产服务器的web.config完全不同，则必须在使用NuGet后同步合并这些dependentAssembly部分。

我也犯了同样的错误。。。在我的案例中，问题解决如下：

最初安装应用程序时，这里的人在应用程序中使用了Microsoft Enterprise Library 4.1。在前一周，我的机器被格式化了，在那之后，今天当我构建应用程序时，它给了我一个错误，即缺少企业库程序集。然后我安装了Microsoft Enterprise Library 5.0，这是我在谷歌上作为第一个搜索条目获得的。然后当我构建应用程序时，它给了我上面的错误，即找到的程序集的清单定义与程序集引用不匹配。经过大量的搜索和分析，我发现应用程序引用的是4.1.0.0，bin文件夹中的DLL版本是5.0.0.0然后我安装了Microsoft Enterprise Library 4.1。删除先前的引用（5.0）并添加4.0引用。构建应用程序（&V）。。。它奏效了。

在Team Foundation Server的生成服务上生成时遇到此错误。结果发现，我的解决方案中有多个项目，使用NuGet添加的同一库的不同版本。我删除了NuGet的所有旧版本，并添加了新版本作为所有版本的参考。

Team Foundation Server将所有DLL文件放在一个目录中，当然，一次只能有一个具有特定名称的DLL文件。

如果将AssemblyInfo.cs与AssemblyVersion标记一起使用，并且.csproj文件具有不同的值，也可能发生这种情况。通过匹配AssemblyInfo或一起删除该部分，问题就消失了。

在我的案例中，在运行ASP.NET应用程序时发生了此错误。解决方案是：

删除项目文件夹中的obj和bin文件夹

清理不起作用，重建不起作用。所有引用都很好，但它没有编写其中一个库。删除这些目录后，一切都很顺利。

这是我解决这个问题的方法。

从异常消息中，获取“问题”库的名称和“预期”版本号。

在解决方案中查找该.dll的所有副本，右键单击它们，然后检查它是哪个版本的.dll。

好的，在这个例子中，我的.dll肯定是2.0.5022.0（所以异常版本号是错误的）。

在解决方案中的所有.csproj文件中搜索异常消息中显示的版本号。用dll中的实际版本号替换此版本号。

所以，在这个例子中，我将替换这个。。。

<Reference Include="DocumentFormat.OpenXml, Version=2.5.5631.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />

…用这个。。。

<Reference Include="DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />

工作完成！

好的，再来一个答案。我之前将我的应用程序创建为64位，并相应地更改了输出路径（项目/财产/构建/输出/输出路径）。最近，我将应用程序更改为32位（x86），创建了一个新的输出路径。我创建了一个快捷方式，指向我认为编译的.exe要去的地方。无论我对源代码做了什么更改，它都得到了清单不匹配的错误。在大约一个小时的沮丧之后，我碰巧检查了.exe文件的日期/时间，发现它很旧，显然引用了旧的.dll。我正在将应用程序编译到旧目录中，我的快捷方式引用了新的。已将输出路径更改为.exe应指向的位置，运行快捷方式，错误消失。（拍打前额）

问题已经有了答案，但如果同一解决方案中不同版本的NuGet包出现了问题，您可以尝试以下方法。

打开NuGet Package Manager，您会看到我的服务项目版本与其他版本不同。

然后更新包含包的旧版本的项目。

只需删除项目的bin文件夹中的内容并重新生成解决方案就解决了我的问题。

清理并重建解决方案可能不会替换输出目录中的所有dll。

我建议尝试将文件夹从“bin”重命名为“oldbin”或将“obj”重命名为”oldobj“

然后再次尝试建立您的解决方案。

如果您正在使用任何第三方dll，则需要在成功构建后将其复制到新创建的“bin”或“obj”文件夹中。

希望这对你有用。

我的问题是，在新版本中删除了旧dll的dployed。为了解决这个问题，我只选中了在发布时删除目标位置的其他文件的复选框。删除目标位置的其他文件

如果您遇到类似“找到的程序集的清单定义与程序集引用不匹配”的错误，并且您已经通过VS中的“项目”>“管理NuGet程序包和更新”选项卡进行了更新，那么您可以做的第一件事就是在从NuGet Gallery页面检查版本并从package Manager控制台运行以下命令后，尝试安装另一个版本的程序包：

PM> Install-Package YourPackageName -Version YourVersionNumber 
//Example
PM> Install-Package Microsoft.Extensions.FileProviders.Physical -Version 2.1.0

虽然答案和所讨论的包并没有直接关系，而且早在很久以前就有人问过它，但它是一种通用的，仍然相关，希望它能帮助一些人。

在这篇文章中提到过类似的问题吗？“关于我如何找出试图引用此DLL文件的旧版本的内容的任何建议？”

需要哪个程序集仍然引用旧的ODATA客户端6.15.0，ildasm帮助我缩小了范围（没有基本代码访问，只能通过服务器上部署的pkg）。

下面的屏幕截图用于快速总结。

DeveloperPackge（如果没有ildasm.exe）https://www.microsoft.com/net/download/visual-studio-sdks

我现在要让所有人都大吃一惊。

从.config文件中删除所有<assemblyBinding>引用，然后从NuGet Package Manager控制台运行以下命令：

Get-Project -All | Add-BindingRedirect

在我的单元测试项目中也出现了同样的错误，导致一些测试失败。我仔细检查了我在程序集资源管理器中使用的程序集的哪个版本，并检查了运行时/依赖程序集标记的内容，发现我使用的程序集中的另一个版本仍然在那里被引用。因为这是我的测试项目app.config中的唯一指令，所以我尝试删除整个app.config文件，重新构建解决方案，这就成功了！我没有更多参考错误：）

我得到了：

无法加载文件或程序集“XXX new”或其依赖项之一。找到的程序集的清单定义与程序集引用不匹配。（HRESULT的异常：0x80131040）

这是因为我将程序集的名称从XXX.dll更改为XXX-new.dll。将名称还原为原始名称修复了错误。

检查project的财产中的licenses.licx，您将在那里发现错误的版本。。。。它在活跃的报告引用中对我有用

发生在我身上的System.ValueTuple

意外错误无法加载文件或程序集“System.ValueTuple，版本=4.0.1.0，文化=中性，PublicKeyToken=cc7b13ffcd2ddd51'或它的一个依赖项。系统找不到指定的文件。

通过在发生错误的计算机上安装.NET Framework 4.7.2 Runtime解决了此问题。简单且无需添加bindingRedirect、修改GAC或降级NuGet包等。

https://dotnet.microsoft.com/download/dotnet-framework/net472

没有适合我的解决方案。我尝试了清理项目解决方案、删除bin、更新包、降级包等……两个小时后，我用程序集从项目加载了默认App.config，并在那里更改了错误的引用版本：

<dependentAssembly>
    <assemblyIdentity name="Microsoft.IdentityModel.Logging" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-5.5.0.0" newVersion="5.5.0.0" />
</dependentAssembly>

to:

<dependentAssembly>
    <assemblyIdentity name="Microsoft.IdentityModel.Logging" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.14.0.0" newVersion="5.5.0.0" />
</dependentAssembly>

在这之后，我清理了这个项目，再次构建它，它成功了。没有警告没有问题。

请在Visual Studio调试器中运行代码。请运行直到得到异常。将出现Visual Studio异常UI。请阅读Visual Studio异常底部的“完整详细信息”/“显示详细信息”。在Fulldetails/Showdetails中，它告诉我我的一个项目（指我的主项目）有一个不同的版本在我的例子中，我的单元测试项目正在调用我的项目。我的单元测试项目和我的项目具有不同版本的Microsoft.IdentityModel.Clients.ActiveDirectory。我在执行单元测试时遇到运行时错误。

我刚刚用主项目的相同版本更新了单元测试项目的版本。这对我有用。

我也有类似的问题，但没有一个答案对我有效。

对我有效的解决方案是手动从项目文件（YourProject.csproj）中删除publicKeyToken部分。

以前是：

<Reference Include="Utility, Version=0.0.0.0, Culture=neutral, PublicKeyToken=e71b9933bfee3534, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>dlls\Utility.dll</HintPath>
</Reference>

更改后为：

<Reference Include="Utility, Version=1.0.1.100, Culture=neutral, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>dlls\Utility.dll</HintPath>
</Reference>

确保SpecificVersion为False。

用蛮力解决了我的问题。

我意识到我在整个解决方案中提供了DLL的多个副本和两个不同的版本。

在资源管理器中进入解决方案，搜索有问题的DLL并删除所有DLL。然后使用DLL的一个版本将引用添加回DLL。

我一时被这个难住了。我可以在发布版中构建和运行，但由于引用与清单不匹配而无法在调试中运行。我一定检查了100次引用，并删除了所有dll。我注意到在调试和发布中生成的清单是不同的。

我删除了我的项目/财产中的app.manifest，它解决了这个问题。这并没有提到有问题的引用dll，所以我不知道为什么这会导致问题。

在尝试了上面的许多解决方案但没有修复后，最终要确保在Visual Studio中的应用程序中启用了“自动生成绑定重定向”。

有关启用自动绑定重定向的更多信息，请参阅：https://learn.microsoft.com/en-us/dotnet/framework/configure-apps/how-to-enable-and-disable-automatic-binding-redirection

尝试从webConfig/appConfig中删除程序集引用

 <dependentAssembly>
        <assemblyIdentity name="System.IO" publicKeyToken="B03F5F7F11D50A3A" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.1.2.0" newVersion="4.3.0.0" />
      </dependentAssembly>

这类问题的一般答案是像其他答案一样使用绑定重定向。然而，这只是问题的一部分——您需要知道所使用的程序集文件的正确版本。Windows财产并不总是准确的，nuget也不总是准确的。

获取正确版本信息的唯一方法是分析文件本身。一个有用的工具是dotPeek。根据我的经验，dotPeek中列出的程序集名称总是准确的。

例如，此文件的正确绑定如下：

<dependentAssembly>
    <assemblyIdentity name="System.ComponentModel.Annotations" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.2.1.0" newVersion="4.2.1.0"/>
</dependentAssembly>

Windows资源管理器称该文件为4.6.26515.06，nuget称其为5.0.0.0文件。dotPeek说它是4.2.1.0，这是在我们的软件中正确工作的版本。还要注意，公钥和文化很重要，dotPeek也会显示这些信息。

这个问题由来已久，我最近在Azure DevOps Yaml管道和Dotnet Core 3.1中收到了同样的错误消息。这个问题与其他答案试图解决的问题有些不同，因此我将分享我的解决方案。

我有一个解决方案，为我自己的nuget包提供了许多项目。我无意中在*.csproj文件中添加了版本标记，如下所示：

  <Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <Version>1.0.0</Version>
  </PropertyGroup>

我用一个DotnetCoreCLI@2任务：

 - task: DotNetCoreCLI@2
   displayName: 'pack'
   inputs:
     command: pack
     nobuild: true
     configurationToPack: 'Release'
     includesource: true
     includesymbols: true
     packagesToPack: 'MyNugetProject1.csproj;**/MyNugetProject2.csproj'
     versioningScheme: 'byEnvVar'
     versionEnvVar: 'GitVersion.SemVer'

问题是*.csproj文件中的版本与环境变量GitVersion.SemVer（由输入“versionEnvVar”指定）中的版本不匹配。

删除*.csproj文件中的所有＜Version＞1.0.0＜/Version＞-标记后，dll的程序集/fileversion由环境变量自动分配，nuget和dll（程序集/file版本）将具有相同的版本，问题得到解决。

我也有同样的错误，但在我的案例中，我在本地运行一个自定义的nuget包到另一个项目中。

为我修复的是将包版本更改为错误中请求的版本。

该包在netstandard 2.1中，请求该包的项目在netcore 3.1中

您可能在assemblyBinding中有错误的掘金版本，请尝试：

删除web.config/app.config中的所有程序集绑定内容：

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
  <dependentAssembly>
    <assemblyIdentity name="Microsoft.Extensions.Logging.Abstractions" publicKeyToken="adb9793829ddae60" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.1.3.0" newVersion="3.1.3.0" />
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="Microsoft.Extensions.DependencyInjection" publicKeyToken="adb9793829ddae60" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.1.3.0" newVersion="3.1.3.0" />
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="System.ComponentModel.Annotations" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.2.1.0" newVersion="4.2.1.0" />
  </dependentAssembly>
</assemblyBinding>

在包管理器控制台中键入：添加BindingRedirect生成所有必要的绑定重定向运行应用程序，看看它是否正常工作。如果没有，请添加包控制台缺少的任何缺少的绑定重定向。

运行迁移器以从使用packages.config升级到PackageReference，为我轻松修复了此错误。如果您运行的是Visual Studio 2017 15.7版或更高版本，您可以按照以下步骤进行升级。

https://learn.microsoft.com/en-us/nuget/consume-packages/migrate-packages-config-to-package-reference#migration-步骤

以下是步骤（从上述链接复制）：

使用packages.config打开包含项目的解决方案。在解决方案资源管理器中，右键单击“引用”节点或packages.config文件，然后选择将packages.cnfig迁移到程序包参考。。。。迁移器分析项目的NuGet包引用和尝试将它们分类为顶级依赖项（NuGet直接安装的软件包）和Transitive依赖项（作为顶级包的依赖项安装的包）。注意：PackageReference支持可传递的包还原和解析依赖关系是动态的，这意味着传递依赖关系需要不能显式安装。（可选）您可以选择将NuGet包分类为通过选择程序包的顶层选项。此选项自动设置为包含不流动的资产的包（build、buildCrossTargeting、contentFiles或分析器文件夹）和标记为开发依赖项（developmentDependency=“真”）。检查所有程序包兼容性问题。选择“确定”开始迁移。在迁移结束时，Visual Studio提供了一个带有备份路径、已安装软件包的列表（顶级依赖项），引用为可传递的包列表依赖关系，以及在开始迁移。报告将保存到备份文件夹中。验证解决方案是否构建并运行。如果您遇到问题，在GitHub上提交问题。

在我的案例中，上述解决方案都不起作用——问题是由app.config中定义的旧的.net配置（2.0）架构引起的，因为bindingRedirect不起作用。

删除xmlns=“http://schemas.microsoft.com/.NetConfiguration/v2.0“来自app.config或web.config，因为在较旧版本的.net framework（如2.0）中似乎不支持bindingRedirect

希望这能为某人节省几个小时或几天的时间。

与“文件资源管理器”>“属性”>“详细信息”选项卡中的版本相比，.DLL在代码中使用反射的“版本”属性报告不同的版本并不罕见。

多年来，我发现使用这种powershell可以更好地找到应该将绑定重定向设置到哪个版本。

[Reflection.AssemblyName]::GetAssemblyName('C:\Source\Project\Web\bin\System.Memory.dll').Version

Major  Minor  Build  Revision
-----  -----  -----  --------
4      0      1      2

通过以上步骤，我可以在app.config文件中插入（或替换）绑定重定向：

<dependentAssembly>
    <assemblyIdentity name="System.Memory" culture="neutral" publicKeyToken="cc7b13ffcd2ddd51"/>
    <bindingRedirect oldVersion="0.0.0.0-4.0.1.2" newVersion="4.0.1.2"/>
</dependentAssembly>

在该特定示例中，System.Memory.dll的“详细信息”选项卡报告的文件版本为4.6.31308.01。

我陷入了类似的问题。卸载解决方案文件并单击csproj中的编辑以搜索特定的dll，转到dll包文件夹的路径，发现有两个不同版本的dll具有相同的名称，因此删除了旧版本，现在已成功构建。

希望这对某人有所帮助。