我们有一个网站，使用运行在IIS 7上的最新MVC 4构建。我们创建了自己的应用程序池并将其运行时版本设置为4.0。过去几个月一切顺利。 昨天，我们升级到了我们最新的内部版本，包括该机器上需要的其他组件。其中一个组件安装了Newtonsoft.Json.dll v4.5.10到GAC的几个组件。是什么导致IIS在4.0应用程序池内加载.NET 2.0 dll而不是4.0版本？
这打破了我们的网站。我们做了一些快速的挖掘，发现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如何处理所有这些的任何指针？
从我可以告诉，Newtonsoft.Json.dll具有相同的4.5以及所有不同的.NET框架它为（2.0,3.5和4.0）建立的所有版本的强名称。在Json.NET的4.0版本中，情况并非如此，但您可以阅读here，版本控制策略从4.5开始改变。如果组件的强名称对于每个有针对性的.NET Framework都不同，但它们不是。因此，将Newtonsoft.Json.dll放入GAC似乎是一种犯罪行为。这很可能会破坏机器上的其他应用程序，特别是如果应用程序构建在不同的.NET Framework版本上。由于我需要将其添加到GAC，因此我自己创建并更改了强名。
我记得使用.net库有一个不同的优先顺序。
我挖了这个岗位＃1，可以帮助您的理解：In what order are locations searched to load referenced DLLs?
你的具体情况，可能它帮助，如果你重新编译你的网站使用该库的特定版本？ （假设你目前没有这样做？）
或者，您也可以将您的版本放入GAC以进行实验吗？
希望这些给你一些想法。
感谢您的信息。我很清楚DLL的正常加载顺序。但是，自从涉及IIS以后，这不是您的普通方案。 我猜这个问题的重点是：为什么AppPool设置为.NET 4.0将加载一个针对.NET 2.0的DLL，而不是它在/ bin文件夹中的完全有效的4.0？ – 2013-05-10 21:15:41
是的，这就是我们本周想到的。我们最终用完整版本号重新签署.NET 3.5版本。这使我们能够使用常规的json.net作为我们的web应用程序。 – 2013-06-02 03:46:36
嘿，等一下。 “我们”是你和我。蜜蜂先生。 ;） – 2013-06-02 03:48:25