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