推薦：從ASP.NET 1.1升級到ASP.NET 2.0要考慮的Cookie問題
當你準備將Web應用程序從ASP.NET 1.1升級到ASP.NET 2.0，你將面對這樣一個cookie問題：在ASP.NET 1.1應用程序中客戶端保存的所有cookie將失效。 博客園也遇到了這樣的問題，對博客園

大家都知道，要實現(xiàn)一個24*7全天候運行的應用程序并不是一件容易的事。我的一個項目就曾經(jīng)在暴力負荷下堅持了20多個小時后還是壯烈掛掉了。幸運的是，ASP.NET和IIS為我們提供了一些簡便的設施，使我們能夠輕松構建超級穩(wěn)定的。Net應用程序。不過稍嫌不爽的是，Windows 2000（IIS6.0 以下版本） 和 Windows 2003（IIS6.0）系統(tǒng)下的配置方法不盡相同。

先說說windows 2000系統(tǒng)，熟悉ASP.NET的兄臺應當都知道 machine.config 這個文件吧，它保存在 %WindowPath%/Microsoft.Net/Framework/%.NetVersion%/CONFIG/ 目錄下。隨便用什么文本編輯器（當然最土的就屬 “記事本” 了）打開該文件，找到 <processModel ……> 這一節(jié)。ASP.NET就是根據(jù)這一節(jié)的設置，來控制ASP.NET服務進程（aspnet_wp.exe 或 w3wp.ext ）的。我們的寫的ASP.NET 應用程序代碼就運行在這個進程空間內(nèi)。如果你使用的是Framework 1.1 你會在這一節(jié)中看到n多個屬性，我們關心的是下面三個，等號后面是它們的缺省值：

timeout="Infinite"

idleTimeout="Infinite"

memoryLimit="60"

在 Framework 2.0 下你看不到它們，但你可以手工把它們添加進去。

我來翻譯一下這三個屬性的意思，在持續(xù)運行了 timeout 指定的時間后，重啟 ASP.NET服務進程，timeout 的缺省值為無窮大，你可以按“HH：MM：SS”的格式重新設置，如，timeout=24：00：00表示24小時后重啟； 如果在 idleTimeout 指定的時間內(nèi)沒人的訪問，則重啟 ASP.NET服務進程，idleTimeout 的缺省值同樣為無窮大，設置方式如上；如果ASP.NET服務進程 使用的內(nèi)存占系統(tǒng)總內(nèi)存的百分比超過了 memoryLimit 指定的數(shù)量，則重啟 ASP.NET服務進程。

明白了吧，通過這三個屬性的配合，就可以神不知，鬼不覺的重啟服務進程，從而使咱的應用程序生生不息的運行下去。我這樣說，細心的讀者可能已經(jīng)發(fā)現(xiàn)問題了，當服務進程重啟時，客戶端的會話（Session）必然會丟失，用戶的操作也就被中斷了。怎么能做到“神不知，鬼不覺”呢？

這個問題確實存在，不過可以通過如下措施將其影響減至最小，甚至完全消除：

首先，我們可以把 idleTimeout 設為一個合理的值，通常我會將其置為會話（Session）超時設置的1.5-3倍。將timeout 置為程序能堅持的上限值，我通常將其置為24小時。這樣將迫使服務進程在空閑時重啟，由于這時不存在任何會話（Session），所以也就不可能中斷用戶的操作。這種設置在中小企業(yè)辦公環(huán)境中非常有效，因為下班后基本沒有人訪問。

當然，上面的方法局限性很大，只能在特定場合起作用。如果在持續(xù)有人訪問，或者內(nèi)存超限的情況下重啟，用戶的操作仍然會受到干擾。一個終極的解決辦法就是，將會話（Session）狀態(tài)保存在獨立的進程中。在ASP.Net上，這也可以通過簡單的配置實現(xiàn)。

分享：asp.net2.0 URL重寫以及urlMappings問題(2)
　　由于一旦進行了URL重寫，原先的WEBFORM中的Action會發(fā)生改變，容易造成：請求的資源不存在問題具體怎么樣？各位DX看看就清楚了！！！ 所有才有了這個ResponseFilter了，