这类问题的一般答案是像其他答案一样使用绑定重定向。然而，这只是问题的一部分——您需要知道所使用的程序集文件的正确版本。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也会显示这些信息。

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

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

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

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

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

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

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

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

这个问题由来已久，我最近在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版本）将具有相同的版本，问题得到解决。