标题可能会更好，但我现在真的想不出更好的东西了。我在我的两个服务器之间遇到了一个非常奇怪的问题：Server1和Server2。
两者都是Windows 2012 R2/IIS 8.5。Server2是在生成时从Server1克隆而来的，此后一直处于相同的修补程序周期中。
我最近对Server1进行了一次重大的代码更改，其中包括在我的解决方案中添加了一个新项目。大多数解决方案的目标。NET Framework 4.6(这里和那里有一些旧的部分，但没有那么重要(，但新项目的目标。NET Standard 1.3。这个新项目的所有引用都列为NuGet包。
当我在本地计算机上编译并运行整个解决方案时，一切都很好。然而，当我将它部署到Server1时，每当代码到达引用的点时，我就开始出现以下错误。NET标准1.3项目的代码。
Could not load file or assembly 'System.Net.Http, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
在尝试了我能想到的一切并在网上找到解决这个问题的方法后，我最终能够通过在机器上安装MSBuild并运行msbuild -t:restore命令来正常运行。一旦直接在服务器上运行，一切都开始工作。
我认为部署过程可能缺少了一个步骤，所以当我将所有代码移到Server2时，我实际上将整个代码库从Server1原样移到了Server2。我甚至没有依赖自己的部署过程，因为我担心这是问题的原因。
果不其然，在Server2上运行代码后，我再次看到完全相同的错误。目前，我在Server2上唯一没有做的事情就是运行该命令，虽然它可能会为这些开发机器修复它，但我并不特别渴望在我们的生产服务器上安装MSBuild这样的程序来修复它。
所以现在我的问题是：有人知道我是否遗漏了什么吗？我承认，我不完全理解NuGet，所以我不确定msbuild -t:restore命令为什么会修复这个问题。是否有某种方法可以复制此命令在文件结构或配置级别上所做的操作，这些操作可以合并到部署过程中？
或者。。。我是否应该停止担心将MSBuild放在生产服务器上，并将服务器上的构建活动作为我们日常部署过程的一部分？
请注意： 我不建议任何使用本应长期存在并具有持续增强功能的应用程序遇到此问题的人使用以下解决方案。这对我们来说是一个可行的选择的唯一原因是，主应用程序很快就会达到EOL，并且在完全退役之前，代码库不希望经历任何重大的增强或集成
事实证明，解决方案是将NuGet添加到我们的核心应用程序中(该应用程序从未实际使用过NuGet，只依赖于手动引用(，然后强制核心应用程序降级自己的系统。网Http和系统。诊断。DiagnosticsSource程序包到所使用的程序包。NET标准1.3目标项目。我对这种方法并不特别满意，因为如果我们需要升级任何东西，它会给我们带来很多问题，但就当前项目而言，它会起作用。
我仍然有点困惑为什么要使用网络。配置绑定从未对此起作用。我的理解是，如果我使用下面的代码，我就不必担心降级或升级库引用等等。NET将根据显示的绑定设置来处理引用调用的指向。
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" culture="neutral" publicKeyToken="b03f5f7f11d50a3a" />
<bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.0.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
我们甚至尝试使用4.1.1.3和4.1.1.0的新版本(经过适当的DLL更改(，但它们都不起作用。应用程序完全忽略配置中的这一行这一潜在现实是我们关注的另一个问题，但幸运的是，正如上面的注释所述，我们不必再担心这个应用程序了。