我們有一個網站，使用運行在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