在開發時，如果我們正在使用 VS + IIS 的模式進行開發與調試，或者當我們在使用 VS 內置的開發人員服務器組件調試 Asp.net 應用程序時，我們從正在瀏覽的頁面偶爾收到一個消息：應用程序已脫機。這是由於VS正在更新網站，爲了給正在更新的網站提供一個保護，調試工具在網站根目錄放置了 App_Offline.htm 以防止在不正確的時機訪問正在被更新的網站。一般地，當 VS 完成更新網站（生成操作或基他操作）之後會自動將這個文件刪除。
本文將詳細地討論此文件，及如何將應用程序定義爲脫機，並創建我們自己自定義的脫機機制。
app_offline.htm 在 ASP.NET 中是一個有用的文件。當我們對服務器正在進行維護，需要暫時關閉網站時，可以用到它，它向客戶端提示服務器正在維護。當 asp.net 應用程序根目錄下存在這個 App_Offline.htm 時，一旦有客戶端試圖訪問這個 ASP.NET 網站，服務器就會向其傳送 app_offline.htm 的內容。基於用戶體驗上來說，它是十分有意義的。
關於此文件，MSDN沒有專門的文檔，只有幾篇文章中提到這樣一句話：“如果存在 App_offline.htm 文件，對網站的任何請求都將重定向到該文件，它顯示一條友好消息，通知客戶端網站正在進行更新。” 事實上，系統自動生成的這個 App_Offline.htm 文件是十分醜陋的，因此我們想到要自己定義一個這樣的 App_Offline.htm 文件（可以直接修改系統自動生成的那個文件），或者自己定義自己的一個脫機機制。
首先，關於 App_Offline.htm，到目前爲止，不得不澄清幾個問題：
1 文件的大小可以認爲是不受限的，可是很小也可以是很大。很多人說文件大小應該超過 512 Byte，而又有另一個系列的文章認爲此文件的大小是無關緊要的。我必須再一次對此問題進行澄清一下：事實上， Internet Explorer 8.0、Opera 10.50、Firefox 3.5 中，可以認爲這個文件的大小已被忽略了，瀏覽器可以接受它以任意大小的形式出現；但在 Chrome 4.1 中，如果此文件的大小低於 512 Byte，它將被忽略，Chrome 將給用戶呈現一個“鏈接已被破壞”的消息。通過跟蹤 http 請求可以知道，客戶端在接收 App_Offline.htm 時，接收了一個 404 的狀態碼。這就決定了它的內容如果過少，很有可能被一些瀏覽器拋棄——這正是一些瀏覽器將它解析爲”該頁無法顯示“的本質原因所在。
2 文件名稱：大小寫不敏感，擴展名必須是 htm。在 Windows 系統中文件名稱是大小寫不敏感的，包括 Asp.net 頁面名稱、QuestString、各種請求的資源名稱等都是不分大小寫的，因此 App_Offline.htm 的文件名是不分大小寫的；注意 "app_offiline.htm" 作爲一個文件的名字，在 URL 中它是一個客戶端請求的資源的名稱，它是既定的，也是唯一的，而且系統僅內置它作爲應用程序脫機的標準文件名，而擴展名作爲整個文件或資源的名稱不可分割的一部分，更改了它，自然整個文件的名字就變了。所以其擴展名不能是除 htm 以外的任何其他擴展名。
3 此文件僅影響當前應用程序。在 Asp.net 中，一個“網站”被當作一個“應用程序”對待，我們暫且把它稱之爲一個“Asp.Net網站”，這與IIS的“網站”的概念略有不同：一個IIS中的網站可以以虛擬目錄的形式包含若干個“Asp.Net網站”。也就是說在IIS中，一個應用程序可以被部署在一個獨立網站中，也可以被部署在某個網站的一個虛擬目錄中。事實上，不用管當前的應用程序是如何部署的，記住一點，App_Offline.htm 文件影響着當前的應用程序，即Asp.Net網站；而不會對當前IIS網站中其他虛擬目錄造成任何影響；即使當前網站已經含有虛擬目錄（無論這虛擬目錄的物理路徑是否真的位於當前網站網站的目錄下），這些虛擬目錄也有其他應用程序，這些部署在虛擬目錄裏的應用程序仍將不受影響。
4 此文件影響所有受當前應用程序 asp.net ISAPI 託管的文件類型。此文件影響所有受 ASP.NET 引擎託管的的文件，例如我們常見的 .aspx，.ascx等，也有我們不常見的 .axd 等。諸如 .html、圖片等靜態文件，在通常情況下是不由 asp.net 引擎託管的，因此他們也就不會受此文件影響了。不用擔心，如果你在 IIS 中做過自定義映射，那麼這些經過映射過的類型也將受此影響，也就是說無需爲了讓這些類型受它影響而專門爲它們做映射。我想聰明的你已經猜出原因了，是的，這是因爲 app_offline.htm 的作用機制完全來自 asp.net 引擎，而不是 IIS 本身。
自定義應用程序的脫機機制
雖然上述使用 App_Offline.htm 文件能解決一大部分問題，但我不得不提到他的幾個缺點：
1 有目共睹的，它的樣式實在是很醜陋；
2 它的提示仍然不符合我們日常在做應用開發時給用戶的提示需求——它只做了一個極爲常規的提示；
3 如上面”澄清“部分所述，它只有擁有一個正確的大小才能被正確被展示出來；
4 它是系統生成的，也很有可能被系統在某一個時刻刪去，不易受操作人員控制；
5 以上做法並不利於搜索引擎的抓取。如果網站根目錄被放有 App_Offline.htm，用戶將得到一個 404 錯誤碼。當搜索引擎在試圖訪問某一頁面時得到一個 404 錯誤碼，那麼搜索引擎將通知其數據庫將正在抓取的頁面的所有信息刪除。雖然我知道這個文件存在的時間不會太久，但你無法保證搜索引擎不會在此時到來。我想這並不是網站管理人員所期待的。
鑑於以上原因，我們想製作一個用戶用好、具有更多有用信息、不返回404錯誤碼、而且是操作人員能主動控制的應用程序脫機機制。
我們可以在 Web.Config 的 appSettings 節創建一個名稱爲”ApplicationIsOffline“ 的鍵（如果您的項目有自己的配置提供者，也可以在您自己的配置提供器中創建對應項），以指示應用程序是否脫機，然後以編程的方式來檢測此值，並在此配置值指定脫機時做出相應處理。
我們可以採用 HttpModule 的方式來處理所有正在指向當前網站的請求。如果上述配置鍵指示當前應用程序已脫機，則我們向客戶端傳送（使用 Server.Transfer() 方法）一個我們之前就製作好的錯誤頁面。寫好此 HttpModule 後，在 Web.Config 中做相關配置，將所有請求均映射到此 HttpModule 上即可實現本文中提到的功能。下面是此 HttpModule 的 .cs 相關代碼，如果需要更多關於此示例的代碼，請在文末下載完整的示例。
可以預料，通過上文所述的方法向客戶端的輸出是正常的輸出一個 ciznxcustomedofflinefile.html 文件，因此客戶端會得到一個 200 的狀態碼，這正是我們所期待的。
在這裏下載本文相關示例：ChekOffline.rar (2.32 kb)
本文版權：陳計節
轉載請註明出處。
歡迎訪問本文在 ciznx.com 的原地址：http://blog.ciznx.com/post/aspnetsisteappofflinefile.aspx