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

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

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

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

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

Get-Project -All | Add-BindingRedirect

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

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

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

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

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

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

尝试从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>