今天將 Application Insights 升級到最新版本后，由于我們的站點不再報告調用堆棧，我們的 .NET Framework 4.6.1 ASP.NET 站點現在在初始化時崩潰，原因如下：System.IO.FileLoadException: 'Could not load file or assembly 'System.Runtime, Version=4.2.0.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)'我過去在另一份工作中也曾遇到過類似的問題。關鍵區別在于該問題是由引入 .NET Core 或 Standard 的 Nuget 包引起的。因此，多個同名的 .NET DLL 被復制到 bin 文件夾（在這種情況下為 System.Net.Http）。在這種情況下，就像不再更新 Nuget 包一樣“簡單”......盡管我認為這里的情況略有不同，但“不升級”不再是一個選擇。Application Insights 不再報告調用堆棧有點違背了整個事情的目的！由于它是 System.Runtime，而不是 Nuget 包，因此配置文件中沒有用于 nuke 的依賴版本標記；盡管這樣也行得通，但無論如何，這似乎只是一個臨時解決方案。我推測現在項目中的某個地方可能隱藏著 .NET Core 的 .NET 標準，但我沒有看到 NetStandard 參考，而且我不知道如何判斷 Core 是否被以某種方式拖入。我還沒有愉快地（？）使用標準版或核心版，還沒有立即了解更多信息。我會繼續谷歌搜索...我認為這是因為我們有一個 .NET 3.5 DLL（除了普通的 .NET Framework 3.5 的 System、System.Runtime.Serialization 和 System.Xml 之外，Nuget 或 DLL 引用為零），被 ASP.NET 項目引用，盡管這以前從未出現過問題。我完全被難住了，并停止了當天的所有開發。我一直在升級和降級各種軟件包，查看它們的先決條件，但我沒有找到任何提示。
1 回答
慕無忌1623718
TA貢獻1744條經驗 獲得超4個贊
兩個不同的 Nuget 想要引入不同版本的 System.Runtime.dll。這在使用使用 .NET Standard 的 Nuget 的 .NET 項目中極為常見。這是我第二次遇到源自 System.Net.Http 的問題，因為幾乎每個人都使用它。
Program Files\Reference Assemblies由于 System.Runtime 是一個 .NET Framework DLL，因此無論您在 Visual Studio 或 CSProj 中執行什么操作， Visual Studio 都會始終從該文件夾中獲取它。
就我而言，無論出于何種原因，復制到 bin 文件夾的版本是所需 DLL 的僅反射版本，這意味著我不能簡單地使用標簽來強制它使用<dependantAssembly>bin 文件夾中的版本。我必須首先將完整版本的 System.Runtime.dll 放入 bin 文件夾中。
除了更新到 .NET Core 之外，我唯一的想法（并得到另一位 Stack Overflow 用戶的證實）是在構建后手動復制它。這很糟糕，但它可以與您擁有的任何沖突的 DLL 一起使用：
由于 Nuget 包的原因，您的項目引用中可能會存在沖突的 DLL。我的問題更困難，因為雖然 System.Runtime 是我使用的另一個 Nuget 的先決條件，但我想因為它是 .NET Framework 的一部分，所以它沒有作為 Nuget 包或引用添加。如果沒有，就自己去拉Nuget包。
在包文件夾中查找 DLL 的路徑。例如，我的是
$(SolutionDir)packages\System.Runtime.4.3.1\lib\net462\System.Runtime.dll. 您將需要$(SolutionDir)像我一樣將解決方案目錄與宏交換。在項目的解決方案屬性中編輯構建后事件命令行：
copy "$(SolutionDir)packages\System.Runtime.4.3.1\lib\net462\System.Runtime.dll" "$(TargetDir)System.Runtime.dll"在可以看到其版本號和公鑰令牌的工具中打開 DLL，例如 ILSpy。就我而言，DLL 的版本為 4.1.1.1，公鑰標記為 b03f5f7f11d50a3a。請注意，在文件資源管理器中查看 DLL 的屬性不會顯示正確的版本號。
在文本編輯器中打開 app.config/web.config。如果標簽中還沒有
<dependentAssembly>DLL 的標簽configuration\runtime\assemblyBinding，請添加它。它應該看起來像這樣：
<dependentAssembly>
<assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-9.9.9.9" newVersion="4.1.1.1"/>
</dependentAssembly>
（續）將該名稱替換為不帶 .DLL 擴展名的 DLL 文件名。將公鑰標記替換為您在 ILSpy 中發現的值。將 oldVersion 設置為較寬的范圍。將 newVersion 設置為您在 ILSpy 中找到的版本。
每當您在 Nuget 包管理器中觸摸該 nuget 包時，它可能會更改您的
<dependentAssembly>標簽！因此，在你的項目上留下一個文本文件、一張便利貼、一個霓虹燈標志，說明如果你弄亂了那個 Nuget 包，你可能需要編輯構建后和 app.config/web.config。哭。
如果您像我一樣被困在 .NET Framework 上，您可能最終不得不對許多 DLL 進行這種修改，因為 .NET Standard/Core 變得更加普遍，因此更多的 DLL 最終與它們的 .NET Framework 對應項具有相同的名稱。我們發現將此解決方案部署到 Azure 上不起作用。
否則，唯一的其他解決方案是完全避免它：一次僅升級一個 Nuget 包，并在每次之后進行徹底測試。Nuget 可以像俄羅斯輪盤賭;-)。盡管上述方法對我們有用，但我們最終還是回滾并緩慢而痛苦地升級，直到找到罪魁禍首。
如果您知道更好的方法，我很想聽聽。
- 1 回答
- 0 關注
- 423 瀏覽
添加回答
舉報
0/150
提交
取消