IIS 7.5 上的 ASP.Net 站點未採用新版本的第 3 方 DLL
我有一個使用 SubSonic 2.1.0 版的 Web 應用程序。在添加一些新功能時，我遇到了該版本中的一個錯誤，該錯誤已在 2.2.0 中修復。
在我的開發盒上，我切換了引用的 DLL 版本，一切正常。
更新執行 IIS 7.5 的 Windows 2008 R2 伺服器後，該錯誤仍然存在。
我搜尋了伺服器並將 SubSonic.dll 的每個實例替換為最新版本。
重新啟動站點、應用程序池，然後重新啟動整個伺服器。
我執行了 SysInternal 的 Process Explorer 並檢查了該站點的 w3wp.exe 程序，根據它，w3wp.exe 引用了 SubSonic.dll 的 2.2.0 版本。
我已將數據庫和站點文件從該 Windows 2008 伺服器複製到另一個 2008（從未載入過 v2.1.0 的伺服器），並確認該錯誤不會在那裡發生。
根據症狀，伺服器似乎保留了 DLL 的 2.1.0 版本，但我不知道它在哪里以及如何擺脫它。
附加資訊：
我檢查了 GAC，沒有 SubSonic dll。
使用 Windows SDK 6.1 中的 gacutil 將 2.2.0 安裝到 GAC
在伺服器上設置一個新的站點和 AppPool，並從我的開發箱上傳站點文件的新副本。
站點是 C# .Net 2.0，使用 MVC 1 和 nHaml 2.0 作為視圖引擎。
使用 cygwin find 在文件系統中搜尋與 2.1 DLL 大小相同的任何文件。
找到了幾個 Windows 搜尋框沒有的副本，它們只是在備份文件夾中，不應該被使用，刪除以防萬一。
與 2.1.0 版本大小相同的唯一剩余文件是： ./Windows/System32/DriverStore/FileRepository/prnca00z.inf_amd64_neutral_27f402ce616c3ebc/Amd64/
CNBDR4_5.DLL
./Windows/winsxs/amd64_microsoft-windows-getuname.resources_31bf3856_600.43e .16385_en-us_eca42f29f7e4d0ea / getuname.dll.mui
./Windows/winsxs/amd64_prnca00z.inf_31bf3856ad364e35_6.1.7600.16385_none_ea189c313845a10e/Amd64/CNBDR4_5.DLL
./Windows/winsxs/x86_microsoft-windows-getuname.resources_31bf3856ad364e35_6.1.7600.16385_en-us_908593a63f875fb4/getuname .dll.mui
這似乎與 SubSonic DLL 無關。
2010 年 8 月 30 日更新
關於懷疑正在使用的 DLL 版本的錯誤的推理是問題：
發生的錯誤是相當具體的，當我在 DLL 的 2.1.0 和 2.2.0 之間更改時，在我的開發框中，它可以預見地發生在 2.1.0 而不是 2.2.0 下。
我還把網站放到了不同的伺服器上，它在 2.2.0 上執行良好，所以它的工作並不是我的開發箱獨有的。
基本上，在版本 2.1.0 中，當執行分頁結果查詢時，WHERE 子句元素會加倍，因此生成的查詢將以“WHERE CreatedOn > ‘8-1-2010’ AND CreatedOn > ‘8-1-2010’”結束.
雖然是多餘的，但從語法上來說這很好執行。
當您添加子查詢時，它會出錯，因為子查詢對像生成了兩次 SQL，第二次不是以 WHERE 開頭，而是以 AND 開頭，因為對像上的布爾標誌跟踪是否已啟動 WHERE從第一次生成 SQL 開始時為 true。
所以在 2.1.0 下你會得到“WHERE id IN (SELECT id FROM table WHERE CreatedOn > ‘8-1-2010’) AND id IN (SELECT id FROM table AND CreatedOn > ‘8-1-2010’)”
在 2.2.0 中，分頁查詢上的 WHERE 子句不會重複其條件，因此子查詢不會生成不正確的 SQL 語法。
SQL 生成發生在 DLL 中，我可以通過 SQL Profiler 觀察到 2.1.0 生成了錯誤的語法，但是當我使用 2.2.0 在本地執行時，語法是正確的。
因為這個錯誤是一種特殊的情況，所以站點通常執行良好，它只是在一個特定的搜尋查詢上發生，並且很容易重複，沒有程式碼、數據或資料結構或其他環境更改，它會出錯低於 2.1.0 但不是 2.2.0。
我之前沒有給出關於這個錯誤的細節，因為它似乎與解決問題無關，解決方案應該是關於從 asp.net 站點的 bin 目錄載入的任何第 3 方 dll 被記憶體並且不更新應用程序後的版本池、服務和機器重啟、新站點容器的創建、所有站點文件的刪除和重新上傳等。
更新：嘗試刪除以下內容：
%SystemRoot%\Microsoft.NET\Framework<64>\<versionNumber>\Temporary ASP.NET Files對相關路徑執行此操作（取決於您的 .net 版本和 32/64 位）。
更新前：我不熟悉亞音速。但也許它會生成程序集或儲存過程。不知何故，即使在 dll 升級之後，這個東西的舊版本也會被保留。使用程序監視器檢查應用程序正在從磁碟載入什麼。並檢查儲存過程是否相關。
幾個問題：
- 在將站點部署到 IIS7/Win2k8 伺服器之前，您是否重建了站點？即，部署的站點是否引用2.1.0 或2.2.0 版本？
- 有問題的程序集是強名稱還是弱名稱？如果它是強命名的，它會安裝到 GAC 嗎？
- 錯誤的存在是您認為問題出在 DLL 版本中的唯一理由嗎？