這對於任何擁有App_Code文件夾中的代碼並使用硬件負載平衡器的人來說都是一個問題。它的確可以將硬件負載平衡器設置爲粘性會話來解決問題，但在完美的世界中，我希望關閉該功能。ASP.NET AJAX負載平衡問題
當App_Code文件夾中有一個文件，並且該網站沒有預編譯時，iis會爲這些文件生成隨機文件名。
server1 "/ajax/SomeControl, App_Code.tjazq3hb.ashx"
server2 "/ajax/SomeControl, App_Code.wzp3akyu.ashx"
所以當一個用戶發佈的頁面，並被轉移到另一臺服務器沒有任何作品。
有沒有人有解決方案？我可以更改爲預編譯的網站，但是我們將失去QA部門僅僅推廣已更改文件的能力。
如果您的QA部門可以提升整個庫，則可以將app_code中的任何內容移動到外部類庫。如果您找不到方便或可以忍受的方式切換到預編譯的網站，我認爲您會遇到粘滯的會話。
您的負載均衡器是否支持粘性會話？有了這個，平衡器將在同一個時間窗口內將相同的IP路由到同一臺服務器。通過這種方式，來自一個客戶端的所有請求（AJAX或其他）將始終訪問集羣/服務器場中的同一臺服務器。
其真正的硬件負載平衡器可以設置爲粘性會話來解決問題，但在完美的世界中，我希望關閉該功能。 – 2008-09-10 04:55:28
如果是硬件負載平衡器，則不應該有問題，因爲所有已知的請求URL都是服務器在其中編譯請求的頁面並提供服務的請求URL。
我能想到的唯一問題就是會話和視圖狀態。
其真正的硬件負載平衡器可以設置爲粘性會話來解決問題，但在完美的世界中，我希望關閉該功能。
您是否已將兩臺服務器上的<機器密鑰>節點設置爲相同的值？
您可以重寫web.config中的machine.config文件來設置它。這需要匹配，否則你可以得到這樣的奇怪的情況。
看起來像
看來，這只是ViewState加密。它不會影響自動編譯程序集的文件名。
我認爲asp.net模型對加密和計算機專用存儲有相當大的依賴性，所以我不確定它是否可以避免會話的粘性IP。
我不知道ASP.NET AJAX（我使用MonoRail NJS方法代替），但會話狀態可能是您的問題。
您必須確保會話狀態是可序列化的，並且不要使用InMemory會話。您可能需要運行ASP.NET會話狀態服務器以確保整個前端場使用相同的會話存儲。在這種情況下，會話必須是完美的序列化（這就是爲什麼沒有對象的會話是首選，你必須始終使用ID，我打賭MS堅持在這個限制，當他們做AJAX庫開發）
好吧，第一件事第一MachineKey的事情是真的。在所有負載均衡的機器上，這應該完全相同。我不記得它所影響的一切，但無論如何都要這樣做。
其次，繼續並預編譯該網站。實際上，當頁面重新編譯時，只要有一個.cs文件就可以推出新版本。棘手的是app_code文件被編譯成單個dll。但是，如果在那裏進行了更改，則可以上傳新的dll，並且再次一切都應該沒問題。
爲了使事情更簡單，請啓用「使用固定命名和單頁裝配」選項。這將確保每個編譯中的事物具有相同的名稱，因此您只需測試然後替換已更改的.dll文件。
所有這一切說，你不應該有問題。請求轉到IIS，它只是提供頁面並根據需要進行編譯。如果後面的代碼在每臺機器上都不相同，那麼代碼是相同的，並且該機器將引用它自己的代碼。實際的請求/回發不知道或關心任何這些。我上面提到的所有東西都應該能夠幫助簡化事情，但無論如何它都應該可以工作......所以這可能是一個機器問題。
這種唯一的方法，我已經解決了這個問題，沒有開啓粘滯會話。 – 2009-11-10 06:08:11