定位的程序集的清单定义与程序集引用不匹配

. 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.我收到一个运行时错误：

无法加载文件或程序集#1.4.1.0文化=中立，PublicKeyToken=045746ba8544160c'或它的依赖之一。定位程序集的清单定义不匹配程序集引用

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

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

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

恼人的部分是错误消息没有指示是什么引用导致了问题。

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

如果您使用的是Visual Studio，请尝试“干净的解决方案”，然后重建您的项目。

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

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

我的情况与Nathan Bedford的帖子非常相似，但略有不同。我的项目也以两种方式引用了更改后的dll。1）直接和2）间接引用本身引用了更改后的dll的组件（类库）。现在，我的组件（2）的Visual Studio项目引用了更改后的dll的正确版本。然而，组件本身的版本号没有更改。因此，项目新版本的安装未能在客户端机器上替换该组件。

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

解决方案：删除应用程序；从应用程序文件夹中删除所有DLLS；重新安装。

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

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

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

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

为了修复它，我更改了项目的名称，以及通过右键单击项目并选择“属性”可用的程序集属性。

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

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

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

我没有修复这个错误，所以匆忙中，我完全删除了BIN目录。重建了我的源代码，从那时起它就开始工作了。

我刚刚发现了另一个出现此错误的原因。我从特定库的所有版本中清理了我的GAC，并参考与可执行文件一起部署的特定版本构建了我的项目。当我运行项目时，我在搜索较新版本的库时遇到了这个异常。

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

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

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

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

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

我的app.config

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

对于npgsql。不知何故，在用户的机器上，我的app.exe.config不见了。我不确定它是一个愚蠢的用户，安装程序故障，还是杀毒软件。替换文件解决了这个问题。

以下内容将任何程序集版本重定向到版本3.1.0.0。我们有一个脚本将始终在App.config中更新此引用，因此我们不必再次处理此问题。

通过反射，您可以获取程序集public KeyToken并从. 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.testtesttings”文件中的代码覆盖率配置“导致”了这个问题。我忘了更新那里引用的文件。

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

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

检查清单数据：

1. 打开Visual Studio命令提示符，
2. 键入'ildash'并将所需的程序集拖到ILDASM窗口并打开MANIFEST视图。有时MANIFEST包含一个具有两个版本的程序集旧版本和新版本（如Utility, Version=1.2.0.200和Utility, Version=1.2.0.203）。实际上，引用的程序集是Utility, Version=1.2.0.203(new version)，但由于清单甚至包含Utility, Version=1.2.0.200(old version)，. NET程序集加载程序尝试查找此版本化的DLL文件，找不到，因此引发异常。

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

其他答案对我不起作用。如果您不关心版本，只想运行您的应用程序，请右键单击参考并将“特定版本”设置为false…这对我很有效。

我想补充一点，我正在创建一个基本的ASP.NETMVC 4项目，并通过NuGet添加了DotNetOpenAuth. AspNet。这导致了同样的错误，因为我引用了一个不匹配的DLL文件Microsoft.Web.WebPages.OA。

为了修复它，我做了一个Update-Package并清理了解决方案以进行完全重建。

这对我来说是一种懒惰的方式，但时间就是金钱:-P

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

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

我添加了一个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后同步合并这些依赖组件部分。

我遇到了同样的错误…在我的情况下，它得到了解决如下：

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

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

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

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

在我的情况下，此错误发生在运行ASP.NET应用程序时。解决方法：

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

清洁不起作用，重建不起作用，所有引用都很好，但它不是在编写一个库。删除这些目录后，一切都运行得很好。

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

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

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

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

3. 在解决方案中的所有. 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包管理器，您可以看到我的服务项目版本与其他版本不同。

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

只是删除项目bin文件夹的内容并重建解决方案就解决了我的问题。

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

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

然后尝试再次建立你的Silution。

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

希望这将为你工作。

我的问题是有旧的dll的部署在新的构建中被删除。为了修复它，我只是选中了在发布时删除目标位置的其他文件的框。在目的地删除其他文件

如果您遇到像“定位的程序集的清单定义与程序集引用不匹配”这样的错误，并且您已经通过项目>在VS中管理NuGet包和更新选项卡进行了更新，那么您可以做的第一件事就是在检查NuGet画廊页面的版本并从Package Manager Console运行可折叠命令后尝试安装另一个版本的软件包：

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

虽然答案与所讨论的包没有直接关系，而且是在很久以前被问到的，但它是通用的，仍然相关，希望它能帮助某人。

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

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

下面的屏幕截图用于快速摘要。

DeveloperPackge如果没有ildasm.exehttps://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。将名称恢复为原始名称可以修复错误。

检查项目属性中的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>

到：

<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异常底部的“完整详细信息”/“显示详细信息”。在完整详细信息/显示详细信息中，它告诉我我的一个项目（指的是我的主项目有不同的版本在我的情况下，我的单元测试项目正在调用我的项目。我的单元测试项目和我的项目有不同版本的Microsoft. IdtyModel. Client. 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的引用。

我被这个难倒了一段时间。我可以在发布中构建和运行，由于引用与清单不匹配而无法在调试中。我一定检查了引用一百次，并删除了所有的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运营模式Yaml管道和Dotnet Core 3.1中遇到了同样的错误消息。这个问题与尝试解决的其他答案有些不同，因此我将分享我的解决方案。

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

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

我为所有使用Yaml的项目打包了nuget包，其中包含DotnetCoreCLI@2任务：

 - task: DotNetCoreCLI@2displayName: 'pack'inputs:command: packnobuild: trueconfigurationToPack: 'Release'includesource: trueincludesymbols: truepackagesToPack: 'MyNugetProject1.csproj;**/MyNugetProject2.csproj'versioningScheme: 'byEnvVar'versionEnvVar: 'GitVersion.SemVer'

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

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

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

对我来说，修复它的是将包版本更改为错误中请求的版本。

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

是可能的，你有一个错误的nugget版本汇编绑定尝试：

1. 删除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>

2. 在包管理器控制台中键入：Add-BindingReDirect
3. 生成所有必要的绑定重定向
4. 运行您的应用程序并查看它是否正常工作。如果没有，请添加包控制台错过的任何丢失的绑定重定向。

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

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

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

1. 使用packages.config.打开包含项目的解决方案

2. 在解决方案资源管理器中，右键单击引用节点或packages.config文件并选择packages.config迁移到包参考……

3. 迁移器分析项目的NuGet包引用并尝试将它们分类为顶级依赖项（NuGet您直接安装的软件包）和传输依赖项（作为顶级包的依赖项安装的包）。

注意：PackageReference支持传递包恢复和解析动态依赖，这意味着传递依赖需要没有明确安装。

4. （可选）您可以选择将NuGet包分类为通过选择传递依赖项作为顶级依赖项包的顶级选项。此选项会自动设置为包含非瞬态流动资产的包（那些在构建、构建交叉目标、内容文件或分析器文件夹）和标记为开发依赖项的那些（devmentDependency="true"）.

5. 查看任何包兼容性问题。

6. 选择确定开始迁移。

7. 在迁移结束时，Visual Studio提供了一个包含备份的路径，已安装的软件包列表（顶级依赖项），作为传递引用的包列表依赖项，以及在开始迁移。报告保存到备份文件夹中。

8. 验证解决方案是否构建并运行。如果遇到问题，在GitHub上提交问题。

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

从app.config或web.config中删除xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0"；，因为在旧版本的. net框架（如2.0）中似乎不支持bindingReDirect

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

与File Explorer's > Properies > Details选项卡相比，. DLL在代码中使用反射的Version属性报告不同的版本并不罕见。

多年来，我发现使用这个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具有相同的名称，因此删除了旧版本，现在构建成功。

希望这对某人有帮助。