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

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

我的app.config包含

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

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

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

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

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

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

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部分。

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