是什么导致 IIS 在 4.0 应用程序池中加载 .NET 2.0 dll 而不是 4.0 版本？答案

【问题标题】：what causes IIS to load .NET 2.0 dll instead of 4.0 version inside 4.0 application pool?是什么导致 IIS 在 4.0 应用程序池中加载 .NET 2.0 dll 而不是 4.0 版本？
【发布时间】：2013-05-10 20:54:21
【问题描述】：

我们有一个网站，使用在 IIS 7 上运行的最新 MVC 4 构建。我们创建了自己的应用程序池并将其运行时版本设置为 4.0。在过去的几个月里，一切都很顺利。昨天，我们升级到了最新的内部版本，包括该机器所需的其他组件。其中一个组件将 Newtonsoft.Json.dll v4.5.10 安装到 GAC 中，用于它的几个组件。

这破坏了我们的网站。我们进行了一些快速挖掘，发现 IIS (w3wp.exe) 正在从 GAC 加载 Newtownsoft.Json.dll 而不是我们网站上的版本（4.5.11 - 适用于 .NET 4.0）。这令人费解，因为我们将应用程序池设置为 .NET Framework 4.0。

什么会导致 IIS 从 GAC 而不是我们的本地版本加载此 DLL？

有什么方法可以强制它使用我们的本地副本？

它们很有可能很快就会成为相同的版本，但其中一个是针对 .NET v4.0 而不是 v2.0。 关于 IIS 如何处理这一切的任何指示？

我查看了几个线程 here 和 here 没有运气。

【问题讨论】：

标签： asp.net-mvc iis json.net

【解决方案1】：

据我所知，Newtonsoft.Json.dll 对于自 4.5 以来的所有版本以及为它构建的所有不同 .NET Framework（2.0、3.5 和 4.0）都具有相同的强名称。在 Json.NET 的 4.0 版本中情况并非如此，但正如您所读到的 here，版本控制策略从 4.5 开始发生了变化。如果每个目标 .NET Framework 的程序集的强名称不同，那就太好了，但事实并非如此。因此，将 Newtonsoft.Json.dll 放入 GAC 似乎是一种犯罪行为。它很可能会破坏机器上的其他应用程序，特别是如果这些应用程序是在不同的 .NET Framework 版本上构建的。由于我需要将其添加到 GAC，因此我自己构建了它并更改了强名称。

【讨论】：

是的，这就是我们本周发现的。我们最终使用完整版本号重新签署了 .NET 3.5 版本。这使我们可以将常规的 json.net 用于我们的 Web 应用程序。
嘿等一下。 “我们”是你和我。蜜蜂先生。 ;)

【解决方案2】：

我记得 .net 库有不同的优先顺序。

我挖掘了这篇 Stackoverflow 帖子，可能有助于您理解：In what order are locations searched to load referenced DLLs?

在您的特定情况下，如果您重新编译您的网站以使用特定版本的库，是否会有所帮助？（大概你现在没有这样做？）

或者您也可以通过将您的版本也放入 GAC 来进行试验？

希望这些能给你一些想法。

【讨论】：

感谢您的信息。我很清楚 DLL 的正常加载顺序。但是，由于涉及 IIS，这不是您的普通方案。我想问题的核心是：为什么设置为 .NET 4.0 的 AppPool 会加载针对 .NET 2.0 的 DLL，而不是 /bin 文件夹中完全有效的 4.0 DLL？