在 Windows Vista 和 Windows Server 2008 上將 ASP.NET 1.1 升級至 IIS 7.0

由 IIS 小組

簡介

對於移至 Windows Vista™ 或更新版本的 Windows 作業系統 ASP.NET 應用程式開發人員，IIS 7.0 和更新版本代表舊版 IIS 的大幅進展。 IIS 整合模式提供更高的安全性和新的應用程式可能性，以及其他改善。

大部分從 Microsoft Windows® XP 作業系統升級到 Windows Vista 的開發人員，並在程式中升級其 ASP.NET 應用程式。 或者，他們會安裝在 Windows Vista 上，ASP.NET 在其他 Windows 操作系統上開發的應用程式。

本文詳述必須執行的重要安裝后和升級后設定步驟，讓應用程式能夠處理新的操作系統。 它會描述影響 ASP.NET 應用程式的傳統模式和 IIS 整合模式之間的變更，以及如何解決這些已知問題。

IIS 7.0 和更新版本中的其中一項重大改善是整合式管線功能，可讓 Web 應用程式從受管理或非受控程式碼應用程式使用單一要求處理管線。 此外，新的管線模型可減少從相同功能的兩個不同的實作產生的備援行為。

例如，在舊版中，IIS 和 ASP.NET 實作不同的要求管線，但無法共用事件和處理程式模組的存取權。 驗證是在每一個管線內獨立執行。 在新模型中，可以針對 IIS 進行一次驗證，並 ASP.NET。

這項整合的其他優點包括：

• ASP.NET 使用 IIS 內容類型的窗體驗證和角色等服務，例如靜態和傳統 ASP 頁面。
• 使用 Managed 程式代碼和 ASP.NET 管線模組擴充 IIS 功能，而不只是使用 ISAPI 延伸模組或 CGI。
• 簡化事件追蹤和錯誤記錄整合所產生的疑難解答。
• 在 ASP.NET 與 IIS 之間共用應用程式組態。

本文將探討從舊版 IIS 移轉至 IIS 7.0 和更新版本的應用程式 ASP.NET 相容性問題，並特別著重於從傳統模式轉換至整合模式中使用整合式管線的差異。

如需 ASP.NET 和 IIS 整合功能的完整概觀，請參閱 ASP.NET 與 IIS 7.0 和更新版本整合一文。

從舊版 IIS 升級至 Windows Vista

下圖顯示 Windows Vista 可用版本的 IIS 7.0 可用性：

Windows Vista 版本	IIS 7.0 可用性
家用入門版	否
家用進階版	是
Microsoft Store	是
旗艦版	是

在 Windows Vista 上 ASP.NET 升級案例

下表概述舊版 Windows 操作系統上 ASP.NET 支援的升級路徑，以在 Windows Vista 上 ASP.NET。 請注意問題的位置，如需升級限制和限制的詳細資訊，請參閱下列各節。

下表也顯示無法使用從伺服器 OS 版本升級至用戶端 OS 版本。 相反地，您必須在已安裝伺服器OS的電腦上執行 Vista 的全新安裝。

作業系統	IIS 版本	.NET Framework 版本	升級至 Windows Vista / IIS 7.0 時的考慮
Windows 2000 Server	IIS 5.0	1.0, 1.1, 2.0	升級至 Windows Vista 無法使用。
Windows 2000 Professional	IIS 5.0	1.0, 1.1, 2.0	需要全新安裝OS。
Windows Server 2003	IIS 6.0	1.0, 1.1, 2.0	升級至 Windows Vista 無法使用。
Windows XP Home	N/A	1.0, 1.1, 2.0	Windows XP Home 不包含 IIS。 用戶可以決定在 Windows Vista 上安裝 IIS 7.0 或更新版本。
Windows XP Professional	IIS 5.1	1.0	Windows Vista 不支援 .NET Framework 1.0。 ASP.NET 1.0 應用程式必須升級至至少 ASP.NET 1.1 (ASP.NET 2.0 建議) 。
1.1	升級之後需要手動設定， (請參閱本文稍後) 。
2.0	ASP.NET 必須在升級之後的 IIS 安裝選項中選取，才能在整合模式中設定 ASP.NET 2.0。
Windows XP 平板電腦電腦	IIS 5.1	1.0	Windows Vista 不支援 .NET Framework 1.0。 ASP.NET 1.0 應用程式必須升級至至少 ASP.NET 1.1 (ASP.NET 2.0 建議) 。
1.1	升級之後需要手動設定， (請參閱本文稍後) 。
2.0	ASP.NET 必須在升級之後的 IIS 安裝選項中選取，才能在整合模式中設定 ASP.NET 2.0。
Windows XP Professional x64	IIS 5.1	1.1, 2.0	需要全新安裝OS。

安裝後應用程式組態

緊接在安裝或升級至 Windows Vista 之後，用戶必須執行其他設定步驟，才能讓應用程式運作。 安裝後設定取決於每個應用程式所使用的 ASP.NET 版本。

設定 ASP.NET 1.1 應用程式

在安裝 .NET Framework 1.1 (之前，如果您執行 ASP.NET 1.1 應用程式) ，使用者必須執行下列兩個步驟來啟用 ASP.NET 應用程式：

程序

每個執行 ASP.NET 應用程式的 IIS 應用程式集區，都必須使用符合應用程式所用 ASP.NET 版本的 .NET Framework 版本明確設定。 每個應用程式集區只能執行一個版本的 ASP.NET，因此您必須針對每個 ASP.NET 版本使用不同的應用程式集區。

在 IIS 管理員控制台中，開啟 [應用程式集區]，然後以滑鼠右鍵按鍵按鍵集區，然後選取 [基本設定]。 在圖 1 所示的 [編輯應用程式集區] 對話框中，選取符合應用程式集區中所設定應用程式的 .NET Framework 版本，然後按兩下 [確定]。

圖 1：編輯應用程式集區設定

在傳統模式中使用 ASP.NET 1.1

ASP.NET 1.1 在傳統模式中執行時會使用 IIS ISAPI 擴充功能，這是在安裝或升級後 ASP.NET 的預設設定， (請注意，ASP.NET 2.0 也可以在 Windows Vista 上以整合模式執行，這不需要 ISAPI 擴充功能) 。

您必須明確允許應用程式使用 ISAPI 和 CGI 限制組態在 IIS 管理控制台中執行 ASP.NET 版本。 開啟 IIS 管理員，然後選取 [ISAPI 和 CGI 限制]。 在 [ISAPI 和 CGI 限制] 頁面中，選取 [限制] 資料行中設定為 [不允許] 的每個 ASP.NET 版本，然後按下頁面右側的 [允許] 連結，將設定變更為 [允許]。

圖 2 顯示 ISAPI 和 CGI 限制頁面的範例，其中已選取用於 ASP.NET 1.1 的 Aspnet_isapi.dll 元件版本。 在圖中，此 ISAPI 延伸模組的設定必須從 [不允許] 變更為 [允許]。

圖 2：ISAPI 和 CGI 限制清單

設定 ASP.NET 2.0 應用程式

.NET Framework 2.0 會在 Windows Vista 安裝期間安裝，因此安裝之後，ASP.NET 2.0 已存在於伺服器上。 不過，若要針對 ASP.NET 2.0 應用程式在 Vista 上完成 ASP.NET 設定，用戶必須執行下列兩個步驟：

步驟 1

從 Windows Vista 套件管理員 (控制台\程式和功能\開啟或關閉 Windows 功能) ，選取 [ASP.NET]，如圖 3 所示，然後按兩下 [確定]。

注意

在此步驟之前，ASP.NET 已安裝在計算機上時，請以這種方式選取 [ASP.NET]，以確保已完成其他設定步驟。

圖 3：Windows Vista 安裝 - Windows 功能

步驟 2

每個執行 ASP.NET 應用程式的 IIS 應用程式集區都必須使用符合應用程式所用 ASP.NET 版本的 .NET Framework 版本明確設定。 每個應用程式集區只能執行一個版本的 ASP.NET，因此您必須針對每個 ASP.NET 版本使用不同的應用程式集區。

在 IIS 管理員中，開啟 [應用程式集區]，然後以滑鼠右鍵按鍵單擊應用程式集區，然後選取 [基本設定]。 在圖 4 所示的 [編輯應用程式集區] 對話框中，選取符合應用程式集區中所設定應用程式的 .NET Framework 版本，然後按兩下 [確定]。

圖 4：應用程式集區 & 整合模式

應用程式集區設定

將舊版 Windows 作業系統上的 ASP.NET 應用程式升級至 Windows Vista 時，應用程式會根據 IIS 應用程式隔離設定在應用程式集區中設定，如下所示：

升級前的 IIS 隔離設定	IIS 應用程式集區	IIS 應用程式集區身分識別
低	AppPool Low	NT AUTHORITY\NETWORK SERVICE
中	AppPool Medium	<IWAM_machine 名稱>
高	應用程式是在符合應用程式名稱的應用程式集區中設定	<IWAM_machine 名稱>

Windows Vista 不支援 ASP.NET v1.0

Windows Vista 不支援 .NET Framework 1.0，因此，ASP.NET 1.0 應用程式必須升級為至少 ASP.NET 1.1。 強烈建議您將 ASP.NET 1.0 應用程式升級至 ASP.NET 2.0，以利用較新版本 ASP.NET 中找到的更佳效能和可維護性功能。

HTTP 處理程式

在 Windows Vista 上升級至 IIS 7.0 和更新版本中，只會升級在全域層級設定的前置 HTTP 處理程式。 未升級在月臺層級設定的處理程式。

並存支援

您可以在不同版本的 ASP.NET (上执行开发的应用程序，例如，1.1 和 2.0) 並存在 IIS 上。 您必須在 IIS 應用程式集區中設定應用程式。 此集區必須針對開發應用程式的 ASP.NET 版本進行設定。 每個應用程式集區只能設定一個 ASP.NET 版本。

.NET Framework 1.1 需要 64 位 Windows Vista 上的 WoW 64 設定

如果 .NET Framework 1.1 安裝在 64 位版本的 Windows Vista 上，則 ASP.NET 未正確設定。 在 64 位版本的 Windows Vista 上安裝 .NET Framework 1.1 之後，您必須使用 IIS 管理工具，手動設定應用程式以使用 WOW 64 在全域層級執行。

設定應用程式所使用的管線模式

IIS 已設定為針對新的應用程式使用新的整合模式。 這是預設行為。 管線模式是使用應用程式集區設定來設定。 使用下列其中一項來變更這些設定：

• IIS 管理工具
• APPCMD.EXE 命令行工具
• 使用文字編輯器編輯應用程式組態檔

如果您要將現有的計算機升級至 IIS 7.0 或更新版本，應用程式預設會設定為在傳統模式中執行。 傳統模式提供與舊版 IIS 中 HTTP 管線實作特定相依性的應用程式相容性。

不過，如果您要將現有的應用程式彙入執行 IIS 7.0 和更新版本的電腦，而且您正在複製網站，則使用的管線模式取決於應用程式設定執行所在的應用程式集區設定。

例如，如果您將應用程式複製到您的計算機，並將其設定為在默認應用程式集區中執行，則會使用該應用程式集區的設定來執行，預設會設定為整合模式。 若要變更應用程式的管線模式，請變更 [默認應用程式集區] 設定，或使用您想要的設定建立新的應用程式集區。

Read more about how to configure an existing application to use Integrated mode in the article ASP.NET Integration with IIS 7.0 and Above, in the section entitled, "Migrating ASP.NET Applications to IIS 7.0 and Above Integrated mode". 這會提供變更應用程式組態設定的指示。

相容性

ASP.NET 針對舊版 IIS 開發的管線模組，以及設定為搭配 IIS 7.0 和更新版本使用整合模式的管線模組，可能會遇到行為或其他相容性問題的差異。 這類問題是因為舊版 IIS 中的管線與 IIS 7.0 和更新版本的模組化設計，以及整合式 HTTP 管線之間的架構差異所造成。

本文的其餘章節說明應用程式可能會遇到的潛在相容性問題，並包含建議的因應措施。 如果建議的因應措施不適合實作，請將您的應用程式設定為在傳統模式中執行，以避免相容性問題。

整合模式與傳統模式之間的已知差異

下列提供兩種模式之間已知問題的清單。 請仔細閱讀這份清單。

在整合模式中，不會針對 HttpApplication：：Init 中發生的例外狀況呼叫Application_OnError

在整合模式中，無法使用Application.Error事件攔截在初始化應用程式或模組期間發生的例外狀況。

此外，使用 Server.ClearError 從錯誤復原的應用程式無法在應用程式初始化期間清除錯誤。 這是為了避免應用程式在初始化期間忽略錯誤。 針對每個發生的例外狀況記錄錯誤資訊的應用程式將無法記錄在應用程式初始化期間發生的錯誤，雖然這些錯誤是使用 Web 事件和 HTTP 回應報告。

如果應用程式需要在初始化期間實作這類例外狀況處理，則必須在傳統模式中執行，而不是在整合模式中執行。

EndRequest 中的 Server.ClearError 不會清除整合模式中的例外狀況訊息

在整合模式中，如果在要求處理稍早發生例外狀況，在 EndRequest 中呼叫 Server.ClearError 並不會清除例外狀況回應。 清除 EndRequest 中例外狀況訊息的應用程式無法從回應中移除例外狀況輸出。

如果應用程式需要在 EndRequest 期間實作這類例外狀況處理，則必須在傳統模式中執行，而不是在整合模式中執行。

當例外狀況格式化並寫入響應之後，整合模式應用程式可能會在 EndRequest 中寫入回應

在整合模式中，可以寫入並顯示例外狀況發生之後所寫入的額外回應。

這不會在傳統模式中發生。 如果在要求期間發生錯誤，而且應用程式會在發生例外狀況之後寫入 EndRequest 中的回應，則會顯示以 EndRequest 撰寫的回應資訊。 這隻會影響包含未處理例外狀況的要求。

若要避免在例外狀況之後寫入回應，應用程式必須在寫入回應之前檢查 HttpContext.Error 或 HttpResponse.StatusCode。

在整合模式中，當回應是空的時，ASP.NET 不再隱藏內容類型

在整合模式中，即使回應是空的，ASP.NET 處理程式會在模塊明確設定時產生內容類型標頭。 有些應用程式會產生空白回應的內容類型。 如有需要，請將應用程式設定為 NULL，以明確移除內容類型標頭。

窗體驗證中的不同 Windows 身分識別

當應用程式使用窗體驗證，並允許匿名存取時，整合模式身分識別與傳統模式身分識別有下列不同：

• ServerVariables[“LOGON_USER”] 已填滿。
• Request.LogognUserIdentity 會使用 [NT AUTHORITY\NETWORK SERVICE] 帳戶的認證，而不是 [NT AUTHORITY\INTERNET USER] 帳戶。

發生此行為的原因是驗證是在整合模式的單一階段中執行。 相反地，在傳統模式中，先使用匿名存取 IIS 進行驗證，然後使用窗體驗證 ASP.NET。 因此，驗證的結果一律是單一使用者-- 窗體驗證使用者。 AUTH_USER/LOGON_USER會傳回這個相同的使用者，因為窗體驗證用戶認證會在 IIS 與 ASP.NET 之間同步處理。

副作用是LOGON_USER、HttpRequest.LogonUserIdentity 和模擬無法再存取 IIS 使用傳統模式驗證的匿名用戶認證。

默認Authentication_OnAuthenticate事件不會在整合模式中引發

在整合模式中，DefaultAuthenticationModule.Authenticate 事件不再引發。 在傳統模式中，當未發生驗證時，就會引發此事件。 在整合模式中，設定驗證模式=None 且訂閱 DefaultAuthentication.Authentication 事件的應用程式會收到例外狀況，指出整合模式不支援此功能。 依賴此模式的驗證配置將無法運作。

若要解決此問題，整合模式應用程式可能會改為訂閱 AuthenticateRequest。

在整合模式 Request.RawUrl 中，會在呼叫 RewritePath 之後包含新的查詢字串

在整合模式中，在具有新查詢字串的 URL 上呼叫 RewritePath 之後，Request.RawUrl 屬性會包含新的查詢字串。 在傳統模式中，它包含舊的查詢字串。

若要解決此問題，請重寫您的應用程式，使其不相依於舊的行為。

Windows Vista 不支援 Passport 網路認證驗證

Passport 網路認證功能會從 Windows Vista 和 Microsoft Windows Server® 2008 操作系統中移除，因此 Passport 網路認證驗證應用程式預設無法在 ISAPI 或整合模式中運作。

PassportAuthentication 模組不屬於整合式管線的一部分

在整合模式中，預設會從管線中移除 ASP.NET Passport 驗證模組。 如果應用程式使用它，它可能會新增回管線中。 如上所述，基礎 Passport 網路認證功能會從 Windows Vista 和 Microsoft Windows Server 2008 中移除，因此 Passport 網路認證驗證應用程式默認無法在 ISAPI 或整合模式中運作。

IIS 7.0 和更新版本會拒絕查詢字串中存在的大型有效窗體驗證票證 (長度 <= 4096 個字節)

IIS 會拒絕具有大型 Cookieless ASP.NET 票證的要求，例如在窗體驗證、會話狀態和總計超過 4096 個字節的匿名標識碼中使用的要求。 基於安全性考慮，這可防止使用大型查詢字串的緩衝區溢位惡意探索。 在窗體驗證票證中儲存自定義數據或使用非常大型使用者名稱的應用程式，可能會看到要求遭到拒絕，因為查詢字串太大。

若要變更此行為，請在 IIS 要求篩選組態區段中調整查詢字串大小上限。

在整合模式中，要求逾時 ASP.NET 會在要求期間多次套用，允許要求執行較長的時間

在整合模式中，管線中的每個新轉換都會重設Managed要求執行逾時。 這表示要求最多可以使用模組通知的 (逾時 * (#) ) ，只要任何單一逾時未超過逾時設定的最大時間。

根據 ASP.NET 模組的數目，以及這些模組合併在一起的方式，緩慢的要求可能不會中止，或可能需要很長的時間才能中止。 藉由減少逾時的時間設定長度，以避免這種行為。

追蹤設定不會傳送至 Server.Transfer 目標頁面

整合模式不支援將追蹤設定傳送至 Server.Transfer 作業的目標。

Httpcontext.Current.Response.Write () 方法無法在 Application_Onstart () 中運作

在整合模式中，應用程式無法在 Application_Onstart () 方法中呼叫 Http.Current.Response.Write () 。

HttpRequest.LogonUserIdentity 會在 PostAuthenticateRequest 之前存取時擲回例外狀況

在整合模式中，HttpRequest.LogonUserIdentity 屬性會在 PostAuthenticateRequest 之前存取時擲回例外狀況。 如果模組在PostAuthenticateRequest之前存取此屬性，則會擲回例外狀況。

若要避免此行為：請勿在應用程式中存取此屬性;或者，在 PostAuthenticateRequest 完成之後加以存取。

在整合模式中，當停用匿名驗證時，ASP.NET 模組會收到 IIS 7.0 和更新版本的第一個未經驗證要求

在整合模式中，使用匿名驗證以外的 IIS 驗證配置時，可從不包含必要認證的用戶端看到第一個要求，以在 BeginRequest 和 AuthenticationRequest 階段中 ASP.NET 模組。

相較之下，在傳統模式中，ASP.NET 應用程式不會看到這類要求，因為 IIS 會在 ASP.NET 有機會處理之前，以 401 挑戰拒絕它。

這表示 ASP.NET 模組會在 BeginRequest 和 AuthenticateRequest 階段中看到額外的要求。 要求會出現在 Web 事件中，以及 BeginRequest 或 EndRequest 中完成的任何自定義記錄中。

ASP.NET 在PostAuthenticateRequest之前無法模擬用戶端身分識別

在整合模式中，ASP.NET 在PostAuthenticateEvent中使用應用程式的 Web.config 或 Machine.config 啟用用戶端模擬後，才會模擬用戶端。

此外，啟用用戶端模擬時，在 BeginRequest 和 AuthenticationRequest 事件中執行的模組會以進程身分識別執行，而不是使用已驗證使用者的身分識別來執行。 這不應該是問題，因為模組很少存取這些事件中的資源，因為尚未建立已驗證的使用者。

不過，如果這樣做，則會使用進程身分識別來存取資源。

由於此變更可能造成的用戶權力提升，因此啟用用戶端模擬時，IIS 會擲回例外狀況。 這表示應用程式應該移至傳統模式，或者如果可以確認在 BeginRequest 或 AuthenticateRequest 事件中存取資源，應該關閉此錯誤。

當 charset 和內容類型設定為空字串時，不會產生 Content-Type 標頭

HTTP.sys 在明確設定為 String.Empty 時，不再產生 Content-Type 標頭。 用戶端依賴空白 Content-Type 標頭的應用程式，可能會受到這項變更的影響。

在整合模式中，在下一個模組執行之前，每個模組都會引發同步和異步事件

在整合模式中，同步和異步事件會在伺服器移至下一個模組之前，針對每個模塊引發。

這不同於傳統模式，其中所有異步模組通知都會先執行，後面接著所有同步通知。 除非對排序 (看到「PreSendRequestHeaders 和 PreSendRequestContent 的模組順序已反轉」，否則應用程式應該不會有任何作用。本檔的其他位置) 。

在自定義 IHttpModule 中呼叫 ClearHeader 之後，回應標頭會以整合模式移除

在整合模式中，呼叫 ClearHeaders 不會自動產生預設標頭。 呼叫 ClearHeaders 的應用程式會將標頭傳回至 .aspx 頁面的默認狀態，而是清除所有響應標頭。

不支援在整合模式中使用 Windows 和 Forms 驗證

在整合模式中，不支援設定 Impersonate=true，且不支援使用 Forms 驗證，並造成錯誤或不正確的行為。

在整合模式中，即使 ASP.NET enableHeaderChecking 設為 false，IIS 7.0 和更新版本一律會拒絕回應標頭中的新行) (

在整合模式中，當您嘗試將響應標頭設定為包含 \r 或 \n 的值時，就會擲回例外狀況。 在傳統模式中，此值預設會經過編碼，並在標頭編碼關閉時傳遞。 基於安全性考慮，應用程式不應該嘗試在標頭值中撰寫未編碼的新行。

PreSendRequestHeaders 和 PreSendRequestContent 事件會針對每個模組一起引發

在整合模式中，訂閱 PreSendRequestHeaders 和 PreSendRequestContent 事件的模組會同時收到 PreSendRequestHeaders 和 PreSendRequestContent 事件的通知。

例如，如果模組 A 相依於先在 PreSendRequestHeaders 中執行的模組 B，在針對 PreSendRequestContent 執行模組 A 之前，應用程式可能會中斷，例如模組 B 修改某些要求狀態，而模組 A 依賴它。

使用整合模式時，PreSendRequestHeaders 和 PreSendRequestContent 的模組順序會反轉

在整合模式中，訂閱 PreSendRequestHeaders 和 PreSendRequestContent 的模組將會以區段中的外觀相反順序收到通知。 如果應用程式共用事件順序的相依性，則有多個模組設定為在這些事件中執行的應用程式會受到這項變更的影響。

若要解決這類問題，請變更 區段中的模組順序，或以傳統模式執行應用程式。

在整合模式中，會忽略 中的線程和佇列設定

在整合模式中，ASP.NET 而非 IIS 處理線程上的要求，而且不會使用傳統模式中使用的線程或佇列語意。 由於這種差異，應用程式在整合模式中可能會遇到不同於傳統模式中執行時的輸送量或壓力行為。

如果使用整合模式時遇到組態檔錯誤，IIS 則不會 ASP.NET，會產生錯誤訊息

針對以整合模式執行的應用程式，IIS 現在會讀取應用程式組態檔。 因此，如果在 Web.config 檔案中找到格式不正確的 XML，或檔案中有組態錯誤，IIS 一律會產生錯誤訊息，而不會 ASP.NET。

因為 IIS 和 ASP.NET 以不同格式寫入錯誤，所以錯誤訊息的格式會根據應用程式是否以整合模式或傳統模式執行而有所不同。 以下是 IIS 產生的一種組態檔錯誤類型的範例：內部伺服器錯誤組態錯誤：組態檔格式不正確

在整合模式中，ASP.NET 應用程式必須在模組的 Init 呼叫期間訂閱管線事件

ASP.NET 使用 ASP.NET HTTP 管線的應用程式可以訂閱管線外部的應用程式事件。 不過，使用 IIS 整合模式管線 ASP.NET 應用程式現在必須在模組的 Init () 方法期間訂閱事件。 下列範例示範如何在 Init 中實作事件訂閱：

Public void Init(httpApplication context)
{
    Context.AuthenticateRequest += new EventHandler(this.AuthenticateUser);
}

如需如何建立 IIS 模組的詳細資訊，請參閱 使用 .NET 開發模組一文。

其他資源

如需在 Windows Vista 上升級至 IIS 7.0 和更新版本的詳細資訊，請參閱 Windows Vista 上的 IIS 7.0 應用程式相容性、 Windows Vista 相容性和功能需求一文。