DLL 參考僅在 NuGet 在服務器上還原后有效

Question

標題可能會更好，但我現在真的想不出更好的東西。 我在兩台服務器之間遇到了一個非常奇怪的問題：Server1 和 Server2。

兩者都是 Windows 2012 R2/IIS 8.5。 Server2 在構建時從 Server1 克隆而來，並且從那以后一直處於相同的補丁周期。

我最近對 Server1 部署了一個主要的代碼更改，其中包括向我的解決方案添加一個新項目。 大多數解決方案的目標是 .NET Framework 4.6（這里和那里有一些較舊的位，但沒有什么那么重要），但新項目的目標是 .NET 屬性中的標准 1.3。 這個新項目的所有引用都列為 NuGet 包。

當我在本地計算機上編譯並運行整個解決方案時，一切正常。 但是，當我將它部署到 Server1 時，只要代碼到達引用 .NET Standard 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 放在生產服務器上，並讓服務器上的構建活動成為我們常規部署過程的一部分？

Answer 1

請注意：我不向任何遇到此問題的人推薦以下解決方案，該應用程序本應長期存在並不斷增強。 這對我們來說是一個可行的選擇的唯一原因是因為主要應用程序將很快達到 EOL，並且代碼庫不希望在完全取消之前通過任何更多的主要增強或集成來實現 go。

事實證明，解決方案是將 NuGet 添加到我們的核心應用程序（它從未真正使用過 NuGet 並且僅依賴於手動引用），然后強制核心應用程序將其自己的 System.Net.Http 和 System.Diagnostics.DiagnosticSource 包降級為.NET 標准 1.3 目標項目使用的包。 我對這種方法不是特別滿意，因為如果我們需要升級任何東西，它會為我們前進帶來很多問題，但就當前項目而言，它會起作用。

我仍然對為什么使用 Web.Config 綁定對此不起作用感到有點困惑。 據我了解，如果我使用下面的代碼，我就不必擔心降級或升級庫引用，並且 .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 更改），但它們都不起作用。 應用程序完全忽略配置中的這一行的潛在現實是我們關心的另一個問題，但幸運的是，正如上面的注釋所述，我們不必再擔心這個應用程序了。