• 發行項

本文章是由機器翻譯。

應用程式移轉

將 ASP.NET 1.1 應用程式移轉至 Visual Studio 2010

Jonathan Waldman

如果您多年來一直都在使用 ASP.NET，很有可能您已使用適用于 Microsoft .NET Framework 1.1 的 Visual Studio 2003 編寫過解決方案。近年來，更新且功能豐富的 .NET Framework 2.0、3.0 和 3.5 版本相繼推出，您可能想知道從可信賴的 1.1 Framework 應用程式升級到上述某個版本是否值得或切實可行。

如今，全新的 .NET Framework 4 正受到全世界開發人員的擁戴，認真考慮遷移問題也許比任何時候更緊迫。如果決定遷移，您大可放心，Microsoft 已提供有用的工具説明完成這樣的任務，確保實現 ASP.NET 應用程式的現代化，以便充分利用最新的 NET Framework 的創新功能。我會具體向您介紹如何通過將 ASP.NET 1.1 解決方案遷移到 Visual Studio 2010（Professional、Premium 或 Ultimate）使之再次煥發活力，確保這些解決方案適用于 .NET Framework 2.0、3.0、3.5 或 4 版本。

為什麼要遷移？

即使您的目標僅僅是保持現有的 ASP.NET 1.1 網站，支援和擴展性選項也在逐漸減少。作為一位 1.1 開發人員，您應注意到 Microsoft 已于 2008 年 10 月 14 日停止為 Visual Studio 2003 提供主流支援，並表示不再發行針對 Visual Studio 2003 或 .NET Framework 1.1 的 Service Pack。(不過，Microsoft 將提供擴充支援 Visual Studio 2003 年 10 月之前。8, 2013.)

您可能會非常擔憂，越來越多的協力廠商供應商已停止提供或停止支援可基於 .NET Framework 1.1 運行或擴展 Visual Studio 2003 IDE 的元件。的確，您的 .NET Framework 1.1 Web 應用程式和 Visual Studio 2003 IDE 已越來越不受重視並且即將被淘汰。

但也存在其他原因。.NET Framework、C#、Visual Basic .NET 程式設計語言以及 Visual Studio IDE 的增強功能已大量出現，通過將 .NET 1.1 網站遷移到 .NET 2.0 或更高版本（以下稱為 2.0+），您將最終可以使用最新的工具和技術以及所有新式語言和框架功能（例如母版頁、AJAX、Windows Communication Foundation [WCF]、Silverlight、LINQ、分部類、泛型、lambda 運算式和匿名方法）來增強上述語言和工具，這些框架功能已得到領先的 .NET 開發人員的擁戴。通常，您為 ASP.NET 應用程式選擇的目標框架版本越高，就能夠輕易獲得更大的潛力和更強的功能。您不僅可以從 Microsoft 本身獲得堅實支援（到撰寫本文時，Microsoft 已為所有 2.0+ 框架版本提供主流支援），還可以從活躍的開發人員論壇和協力廠商工具供應商處獲得支援。此外，還有涵蓋最新技術的所有方面的書籍以及提供視頻課程、博客、白皮書和其他培訓選擇的網站可供利用。

卓越的最新 Visual Studio 2010 IDE 本身就是您選擇遷移的充分理由。Visual Studio 2010 IDE 是 Visual Studio 2003 IDE 的下一代產品，支援 IntelliTrace 等新功能，可使用能有效提高程式設計工作效率的各種功能強大的協力廠商外掛程式來實現擴展。當很小一部分使用者出於各種原因需要繼續使用 Visual Studio 的較舊版本時，由於 Visual Studio 2010 面向 2.0+ 框架，因此幾乎不需要並行運行 Visual Studio 2005 和 Visual Studio 2008。但與 Visual Studio
2005 及 Visual Studio 2008 一樣，Visual Studio 2010 也不適用於 1.1 框架。這意味著您必須繼續運行 Visual Studio 2003，或者必須將 ASP.NET 1.1 專案遷移到更新的框架。

最終結果就是，僅具有 1.1 框架經驗的開發人員在職場上可能不會像具有 2.0+ 框架經驗的開發人員那麼搶手。開發人員職位競爭比較激烈，因此您需要盡可能使自己更具有優勢；如果在您的代碼中充分利用更新的框架功能，將可增強您作為專業軟體發展人員的候選資格和可信度。

遷移問題

為什麼從 Visual Studio 2003 以來，並非每個使用者在任何一個主要 Visual Studio 和 .NET Framework 版本發行期間即已從 ASP.NET 1.1 進行遷移？一個原因就是開發人員需要實施 Visual Studio 2005 提供的 ASP.NET 1.1 至 ASP.NET 2.0 遷移選項。這聽起來並不那麼糟糕，但應意識到，當首次部署 Visual Studio 2005 時，需要將 ASP.NET 1.1 專案轉換為全新的 Web 專案類型。這意味著，構建 ASP.NET 1.1 網站時所基於的整個體系結構必須已經過精心改進和嚴格的回歸測試。許多開發人員認為該過程類似于從頭開始重新編寫網站，會帶來看似無法逾越的成本和技術挑戰。因此，決策者通常都會將 ASP.NET 1.1 網站原樣保留。

若要更好地領會此 ASP.NET 1.1 至 ASP.NET 2.0 的遷移挑戰，必須瞭解如何使用專案驅動的 檔-資料夾配置來組織所有 ASP.NET 1.1 Web 專案。該專案類型最初被稱為“2003 Web 專案模型”，現在稱為 Web 應用程式專案 (WAP)。發行 Visual Studio 2005 後，Microsoft 引入一個資料夾驅動的 全新專案類型，該類型專為 .NET Framework 2.0 而設計。該專案類型最初被稱為“2005 Web 專案模型”，現在稱為網站專案 (WSP)。（感到困惑嗎？我們借助簡單的技巧，按它們的字母順序記住縮寫詞：WAP 早于 WSP 出現，正如 Visual Studio 2003 早于 Visual Studio 2005 一樣。）

在此不再贅述 WAP 和 WSP，總之，Microsoft 最初計畫通過包含的轉換向導將所有遷移的 1.1 Web 應用程式更改為 WSP。相關開發人員立即對此提出異議，因為最初的 WAP 專案類型可提供更新的 WSP 專案類型所欠缺的特定技術和性能優勢。當開發人員、管理者和利益相關者獲悉，Microsoft 僅提供 ASP.NET 1.1 WAP 至 ASP.NET 2.0 WSP 的遷移選項，經證實這一舉措既耗時又成本高昂，尤其對複雜網站更是如此，ASP.NET 開發社區很快就此表現出強烈不滿。有關此類遷移過程中引起的技術問題的詳細資訊，包含在一篇單獨的由多部分內容組成的文章中；您可以閱讀 MSDN 庫文章“常見的 Web 專案轉換問題及解決方案”(msdn.microsoft.com/library/aa479312) 以瞭解相關的詳細資訊。

幸運的是，Microsoft 迅速做出回應，很快在 Visual Studio 2005 SP1 中提供經過修訂的轉換向導。這一次，轉換向導可以將 ASP.NET 1.1 WAP 轉換為 ASP.NET 2.0 WAP。但許多開發人員錯過了了解該遷移選項的機會，因而無法再對其進行深入研究。在 Visual Studio 2010 中，轉換向導既能將 ASP.NET 1.1 WAP 轉換為 ASP.NET 2.0+ WAP（這意味著轉換為 2.0+ 後，即能用於 2.0、3.0、3.5 或 4.0 版），同時仍會提供遷移到舊版 Web 應用程式的機會。（您不能使用 Visual Studio 2010 轉換向導將 ASP.NET 1.1 應用程式轉換為 WSP 應用程式，您可能也不希望如此；您必須有權訪問 SP1 之前發佈的原始 Visual Studio 2005 中提供的轉換向導。）

您可能會注意到，無論何時在 Visual Studio 2010 中啟動新專案，都可以選擇是創建 WAP 還是 WSP。Microsoft 承諾為當前及未來的所有 .NET Framework 版本同時提供 WAP 和 WSP 支援。

過程

使用 Visual Studio 2010 遷移 ASP.NET 1.1 應用套裝程式含以下主要步驟（我將詳細介紹每項步驟）：

  • 運行轉換向導。
  • 設置目標框架和啟動頁。
  • 編譯並修復。
  • 將頁面和使用者控制項轉換為分部類。
  • 編譯並修復。

運行轉換向導 若要使用轉換向導將 1.1 WAP 轉換至 2.0+ WAP（我們的目標），必須在安裝 Visual Studio 2010 期間安裝 Visual Web Developer 選件。如果未安裝該選件，則需要進行添加，方法是重新運行 Visual Studio 2010 安裝程式並使用“更改或刪除 Microsoft Visual Studio 2010”選項，選擇“添加”或“刪除”功能，然後確保 Visual Web Developer 功能被選中（請參閱圖 1）。

圖 1 確保在啟動轉換向導之前已安裝 Visual Web Developer 元件

如果未安裝 Visual Web Developer，轉換向導仍會啟動並運行。該嚮導將可以轉換解決方案中除 Web 專案之外的所有專案。建議您務必安裝 Visual Web Developer 以便轉換 Web 專案。

執行轉換任務之前，有必要確保您的應用程式不僅已構建且能夠良好地運行，還應盡可能條理清晰。因此：

  1. 刪除任何未使用或不需要的檔，只保留 Web 應用程式的基本元件，使應用程式清楚明瞭。
  2. 確保在編譯解決方案中的每個專案時均未發生編譯時錯誤。
  3. 雖然建議將解決方案添加到原始程式碼控制中，但如果尚未按此方式配置，請務必確認沒有專門從存儲庫簽出任何檔。將解決方案添加到原始程式碼控制下後，您將可以在轉換過程完成後檢查嚮導所做的特定更改。
  4. 確保未將原始程式碼控制範圍之外的任何檔或資料夾標記為唯讀。這樣，嚮導將可以根據需要更新這些檔/資料夾。
  5. 創建備份。如果在虛擬機器中運行解決方案，最好是僅備份整個虛擬機器（或創建虛擬機器快照）。否則，備份整個應用程式（包括所有依賴項）。如果不確定有哪些依賴項，最好查看應用程式的解決方案 (.sln) 檔及各個專案 (.proj) 檔（這些是可直觀檢查的文字檔）。許多 ASP.NET 解決方案包含的專案指向網路位置或者 Web 根目錄或應用程式檔案夾之外的資料夾。如果您希望從備份檔案還原應用程式，不備份這些依賴項可能會導致嚴重後果。請注意，完整的遷移過程會對應用程式中的每個專案進行更改，因此在開始之前瞭解應用程式的依賴項對您有説明。此外，如果使用在多個 ASP.NET 1.1 應用程式之間共用的專案，則應意識到，一旦遷移這些解決方案，就不能再在 Visual Studio 2003 中打開。如果在團隊環境下工作，更改共用專案還會影響團隊成員的解決方案，這可能會終止對已轉換專案的引用。因此，無論是在專案還是團隊間共用，應通過為共用專案創建備份，同時確保開發工作站上存在本機複本，來將共用專案分離出來。如果移動專案（例如，為了使之分離），您的解決方案檔將發生變化，因此在更改解決方案檔引用的任何專案之前，您可能需要考慮備份解決方案檔。然後在正確分離專案依賴項之後，但在運行轉換向導之前，再次進行備份。最後，可以在轉換過程完成之後發現原始解決方案檔中的錯誤。保留方便使用的轉換前解決方案的備份，您即可輕鬆地在重新運行轉換向導之前回頭檢查並修復這些錯誤。
  6. 考慮設置並行環境：Visual Studio 2003 和 Visual Studio 2010 可以在同一台電腦上並行運行，因此您也可以並行運行 ASP.NET 1.1 網站和 ASP.NET 2.0+ 網站。這有助於您執行遷移後的 QA 測試。

若要啟動轉換向導，請依次使用 Visual Studio 2010 中的“檔”、“打開”和“專案/解決方案”功能表選項打開 Visual Studio 2003 解決方案檔。很快您就可以看到 Visual Studio 轉換向導簡介對話方塊（請參閱圖 2）。按一下“下一步”。

圖 2 Visual Studio 轉換向導簡介對話方塊

轉換向導可以在處理過程中發現問題，而您自己可能也想從備份還原解決方案，請進行少量的更改並從頭開始重新開機該過程。即使將解決方案的所有依賴項放在指定的備份檔案夾內（以便正確還原），該步驟也可以快速創建備份（請參閱圖 3），但您必須完全確信您知道這些備份檔案夾的初始佈局情況。

圖 3 轉換向導允許您在繼續操作之前創建備份

如果您要在該步驟備份解決方案，只需提供資料夾路徑，嚮導即可創建用於存放解決方案檔的子資料夾 Backup。解決方案中的每個專案都將被備份到 Backup 資料夾下的相應子資料夾（即使專案源自原始解決方案的根目錄之外），因此，要成功創建備份，重要的是確保專案名稱在解決方案中是唯一的。按一下“下一步”。

此時您將看到最後一個對話方塊，其中包含有關原始程式碼控制和讀/寫許可權的指導（請參閱圖 4）。

圖 4 轉換向導在允許您繼續操作之前提出相關建議

如果選擇創建備份，您將看到所請求的備份類型和備份檔案的寫入位置。您將看到正在轉換的解決方案名稱及其所有專案的摘要。如果一切正確並且可接受，請按一下“完成”。

此時可能會提示您提供原始程式碼控制存儲庫的登錄憑據（例如 Visual SourceSafe），以便可以簽出項目。

在轉換解決方案的每個專案時會顯示進度欄。由於嚮導要在解決方案中的專案間反復運行，因此該過程可能需要幾分鐘。

轉換向導會顯示一條消息，說明您已完成第一步，現在需要轉換您的 Web 應用程式（請參閱圖 5）。

圖 5 轉換向導提示您需要轉換 Web 專案才能完成遷移

然後，嚮導會提示您已完成初始過程（請參閱圖 6）。

圖 6 轉換向導在轉換過程完成時向您發出提示

然後，可以使用“轉換報告”範本檢查轉換日誌。該日誌檔案名為 Upgrade­Log.XML，存放在解決方案的 .sln 檔所在的資料夾內。升級日誌中顯示已轉換的專案檔案、任何相關錯誤以及警告消息。日誌中還提供有用的注釋以及有關每個專案所面向的框架版本的注釋。我已在圖 7 中包含該報告的摘錄。

圖 7 轉換日誌顯示有關已轉換 Web 應用程式的詳細資訊

應檢查所有警告和錯誤。警告（例如對備份路徑的相對路徑的更改）通常涉及次要的技術問題，一般不需要您執行進一步的操作也能成功編譯轉換後的解決方案。但必須認真檢查錯誤消息（例如檔引用丟失）並採取相應措施，因為錯誤消息涉及的問題通常會阻止您成功編譯轉換後的解決方案。如果發現許多錯誤，則轉換日誌將起到很好的作用，它可清楚說明您需要執行的操作，通常您也可以使用 Visual Studio 2010 説明檔或在各種技術網站中找到更多説明。許多情況下，您可能發現記錄轉換日誌錯誤並在原始 Visual Studio 2003 專案檔案中進行處理，比在轉換後的解決方案（方便您使用創建的備份）中處理更有效。您始終都可以針對修改後的 Visual Studio 2003 解決方案重新運行轉換向導。

在檢查所有警告並清除所有錯誤之後，可以退出轉換向導的最終螢幕。轉換向導現已完成任務。您的解決方案 (.sln) 檔及其專案 (.proj) 檔現已轉換為 Visual Studio 2010 格式。但在完成遷移之前仍有一些工作要做。

設置目標框架和啟動頁 轉換向導完成後，即已將 Visual Studio 2003 Web 專案配置為基於 .NET Framework 4 運行，同時將解決方案的其他專案設置為基於 .NET Framework 2.0 運行。雖然允許混合搭配不同的框架版本，但建議對解決方案的所有專案使用單一目標框架，除非存在由 Web 託管公司或組織基礎結構強加的限制。（Visual Studio 2010 根據活動專案的有效目標框架修改其 IDE 功能集。如果您的專案面向不同的框架版本，在專案之間切換時可能會發現 IDE 的行為令人費解。如果對所有專案使用相同的框架版本，不僅 IDE 可以在所有專案之間提供一致的介面，而且您還能針對一致的框架進行程式設計。）

如果希望更改所有已轉換專案的目標框架，只需在解決方案資源管理器中按右鍵該專案的根目錄並選擇“屬性”即可執行。在出現的配置頁面（請參閱圖 8）中，選擇“應用程式”選項卡，將“目標框架”更改為任意的 2.0+ 框架值。

圖 8 將任何專案的目標框架更改為 2.0、3.0、3.5 或 4

最後，為 Web 專案設置起始頁。為此，請在解決方案資源管理器中找到該頁面並按右鍵，然後選擇“設為起始頁”。

編譯並修復 既然解決方案和專案檔案已升級到 Visual Studio 2010 格式，則可以對您的 ASP.NET 2.0+ WAP 進行編譯。若要強制生成解決方案中的所有專案，建議您在 Visual Studio 2010 中使用“生成”、“重新生成解決方案”功能表選項進行編譯。重新生成之後，可以通過顯示“錯誤清單”視窗查看任何生成問題（可以通過選擇“查看”和“錯誤清單”選項顯示這些問題）。“錯誤清單”視窗中顯示錯誤、警告和消息（可以通過切換相應的“錯誤”、“警告”和“消息”按鈕來指定視窗中顯示的內容）。Visual Studio 2010 通常會提供有關如何解決“錯誤清單”視窗中各項問題的明確指導。如果您不能理解錯誤/警告/消息文本，只需選擇包含相應指導的“錯誤清單”視窗行並按 <F1>。此時將會出現一個説明視窗，其中包含有關該問題的更多詳細資訊（如果您未安裝本地説明，可以連接到 Internet 查看該説明）。您看到的大部分錯誤都與框架更改有關，這些更改導致與您自己的代碼發生命名衝突。通常，您可以使用命名空間對引用進行完全限定來解決這些問題。您看到的大多數警告都涉及過時成員。雖然您仍可以使用過時成員，但應瞭解 .NET Framework 的更高版本中可能不支援這些成員。如果您看到過時成員並以 2.0 框架為目標，則在決定以 3.x 或 4 框架為目標時可能無法使用這些成員。

準備抽出一些時間解決“錯誤清單”視窗中的這些問題。在繼續執行接下來的步驟之前，您應可以解決所有的錯誤和大部分（即使不是全部）警告。

將頁面和使用者控制項轉換為分部類 接下來運行“轉換為 Web 應用程式”（以下稱為 CWA）命令。雖然可以針對單個頁面或使用者控制項運行該命令以
瞭解其所做的更改，但針對整個解決方案運行該命令會更快速。為此，請在解決方案資源管理器中按右鍵“解決方案”節點，然後選擇“轉換為 Web 應用程式”。該過程將執行以下操作：

  1. 通過為頁面和使用者控制項添加新的“設計器”文檔來實施分部類。
  2. 設置頁面和使用者控制項的 AutoEventWireup。
  3. 為頁面和使用者控制項上的每個控制項添加聲明性事件處理常式。

ASP.NET 1.1 應用程式具有代碼隱藏模組（C# 的 aspx.cs 和 ascx.cs，Visual Basic .NET 的 aspx.vb 和 ascx.vb），該模組中包含開發人員編寫的代碼和 Web 表單設計器生成的代碼。在 Visual Studio 2003 中創建頁面或使用者控制項，並使用 Web 表單設計器為它們添加控制項時，IDE 將向代碼隱藏模組添加受保護的實例欄位，這樣，您就可以引用所添加的這些控制項。運行 CWA 命令之後，將顯示每個頁面和使用者控制項的設計器文檔（僅當啟用解決方案資源管理器的“顯示所有檔”選項時，解決方案資源管理器才會顯示該檔）。您將注意到設計器檔案名與副檔名為 designer.cs (C#) 或 designer.vb (Visual Basic .NET) 的頁面或使用者控制項相同。

例如，如果 C# 中存在名為 MyPage.aspx 的頁面，即會出現一個名為 MyPage.aspx.designer.cs 的新文檔。該設計器文檔包含將在代碼隱藏模組中使用的受保護實例欄位。這些欄位已轉換為設計器模組，因此不會再混合在您自己的代碼中。這可能是因為設計器模組屬於分部類，意味著 CWA 命令也會將相應頁面或使用者控制項的代碼隱藏代碼轉換為分部類。

例如，在 Visual Studio 2003 專案的代碼隱藏文檔中，C# 和 Visual Basic .NET 中的實例代碼如下所示：

[VB]
Protected WithEvents MyButton As System.Web.UI.WebControls.Button

[C#]
protected System.Web.UI.WebControls.Button MyButton;
The CWA command moves each to a corresponding designer file:
[VB]
Protected WithEvents MyButton As Global.System.Web.UI.WebControls.Button

[C#]
protected global::System.Web.UI.WebControls.Button MyButton;

(全域:: 表示系統中命名空間的搜尋應該在全域命名空間層級開始，因此可確保架構的 System 命名空間 won’t 會隱藏您自己的系統命名空間)。

設計器檔的創建是動態的，可以隨時重新生成。 因此，只需在解決方案資源管理器中按右鍵該頁面或使用者控制項節點，然後對其重新運行 CWA 命令，即可安全刪除並重新生成 designer.cs 或 designer.vb 文檔（如果該文檔丟失，也可以還原）。 CWA 命令在頁面或使用者控制項的 HTML 標記中掃描伺服器控制項，然後在設計器分部類檔中生成必要的執行個體變數。 接下來，它將刪除仍顯示在您自己的代碼隱藏檔（aspx.cs、ascx.cs、aspx.vb 或 ascx.vb）中的所有執行個體變數。

分部類允許在命名空間內的兩個或更多物理檔間編寫單個類、結構或介面的原始程式碼。 編譯器稍後將這些分部定義組合起來，形成每個類型的單一聲明。 雖然分部類保持 Visual Studio 使用的實際機制，以便將開發人員編寫的代碼與 IDE 生成的代碼明確分開，但開發人員也可在代碼隱藏模組中使用分部類，尤其在團隊環境下工作時更是如此。

由於分部類是 ASP.NET 2.0+ 應用程式的標準，因此應將 ASP.NET 1.1 類劃分為分部類。 如果您跳過該步驟，頁面和使用者控制項將繼續運行，但您在修改頁面 (.aspx) 或使用者控制項 (.ascx) 上的控制項時，需要手動更新代碼隱藏檔中的控制項欄位聲明。

CWA 命令還會更改 AutoEvent­Wireup 的值以及事件的聲明和綁定方式，我認為這一影響非常重要，值得我們詳細討論。 AutoEventWireup 屬於布林屬性，用於指定是隱式（如果為 True）還是顯式（如果為 False）綁定頁面物件事件處理常式。 對於頁面，在 @Page 標記中設置 AutoEventWireup；對於使用者控制項，在 @Control 標記中設置 AutoEventWireup。 CWA 命令為 C# 頁面和使用者控制項將 AutoEventWireup 設置為 True，為 Visual Basic .NET 頁面和使用者控制項將其設置為 False。

各個開發人員有著不同的偏好，ASP.NET 1.1 應用程式中的某些頁面或使用者控制項很可能將 AutoEventWireup 設置為 True 或 False，或者根本不指定該值，在後一種情況下，其預設值來自 web.config 或 machine.config（如果未指定 web.config）。 您應該瞭解，AutoEventWireup 的值可在運行 CWA 命令後發生更改。 此更改可能會導致無法預料的行為，例如頁面事件觸發兩次。 當您在 ASP.NET 1.1 應用程式中為頁面物件事件創建自己的命名約定時，通常會發生這種情況。 例如，考慮使用下麵的 C# 代碼，其中將 Page_Load2 處理常式綁定到 Page.Load 事件委託：

this.Load += new System.EventHandler(this.Page_Load2);

如果 AutoEventWireup 為 False，事件將按預期觸發一次，即使存在名為 Page_Load 的代碼隱藏函數也是如此。 但是，如果 AutoEventWireup 為 True，則會觸發兩個事件，一個對應此處說明的顯式綁定代碼，一個對應將 Page_Load 事件處理常式預訂到 Page.Load 事件的隱式綁定代碼。 請考慮使用圖 9 中的代碼。

圖 9 測試 AutoEventWireup 行為

public partial class _Default : System.Web.UI.Page
{
  override protected void OnInit(EventArgs e)
  {
    InitializeComponent();
    base.OnInit(e);
  }

  private void InitializeComponent()
  {
    this.Load += new System.EventHandler(this.Page_Load2);
  }

  protected void Page_Load()
  {
    Response.Write("In Page_Load().<br />");
  }

  protected void Page_Load2(object sender, EventArgs e)
  {
    Response.Write("In Page_Load2().<br />");
  }
}

图 9 中的代碼生成以下輸出：

In Page_Load().
In Page_Load2().
Top of Form 1
Bottom of Form 1

如果 AutoEventWireup 設置為 True，同樣的情況也將發生在 Visual Basic .NET 中。 請考慮使用以下代碼：

Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs)

  Response.Write("In Page_Load.<br />")

End Sub

Private Sub Page_Load2(ByVal sender As System.Object, _
  ByVal e As System.EventArgs) Handles MyBase.Load

  Response.Write("In Page_Load2.<br />")

End Sub

如果 AutoEventWireup 為 True，將觸發兩個事件處理常式以顯示頁面：

In Page_Load2.
In Page_Load.

您不僅可以看到執行兩個事件處理常式，還可以看到相應的執行順序（與所有多播委託相同）可能與您預期的順序不同。 最後，應意識到 AutoEventWireup 為 True 時，無論是否使用參數定義包含正確函數名稱（例如 Page_Load）的頁面事件處理常式，都會觸發該處理常式。 例如，

protected void Page_Load()
  {
    Response.Write("In Page_Load().<br />");
  }

與以下相同：

protected void Page_Load(object sender, EventArgs e)
  {
    Response.Write("In Page_Load().<br />");
  }

如果兩個都存在，則僅觸發使用參數的事件處理常式，這是在排除故障時要考慮的又一個問題。 因此，通常情況下，在測試頁面和使用者控制項時應謹慎，尤其是在 AutoEvent­Wireup 設置被 CWA 命令更改時更是如此。

最後，CWA 命令將刪除用於繫結控制項事件的顯式 C# 和 Visual Basic .NET 代碼，並在頁面或使用者控制項的標記中改用聲明性事件屬性。 例如，在 ASP.NET 1.1 中，按鈕上的按一下事件通常具有代碼處於隱藏狀態的事件處理常式，例如：

this.MyButton.Click += new System.EventHandler(this.MyButton_Click);

CWA 命令刪除該事件，改為向伺服器-控制項聲明中添加如下 OnClick 屬性：

<asp:Button ID="MyButton" runat="server" Text="MyButton" onclick="MyButton" />

在 Visual Basic .NET 中，不添加聲明性事件， 而是向隱藏代碼中添加 Handles 關鍵字。 因此，“按鈕”控制項的標記將顯示為：

<asp:Button ID="MyButton" runat="server" Text="Button" />

而隱藏代碼將控制項綁定到處理程式：

Protected Sub MyButton_Click(
  ByVal sender As Object, ByVal e As EventArgs) _
Handles MyButton.Click

End Sub

這些聲明性事件處理常式構造的事件委託是在編譯時創建的。

編譯並修復 遷移現已完成。建議您重新生成解決方案，練習解決可能會收到的任何其他編譯器錯誤或警告。請注意，您必須解決編譯錯誤，才能成功生成 Web 專案以及在流覽器中查看已遷移的網站。此外，還應解決編譯警告，但警告不是關鍵問題，不會阻止您使用 Web 應用程式。最後，記錄下所有的編譯器消息，因為這些消息通常可提供説明性的改進建議，如果時間允許，應考慮實施這些建議。除了錯誤和警告之外，還必須對您遷移的代碼執行回歸測試和 QA 測試，執行這些測試時務必小心，確保按預期觸發事件。

遷移後注意事項

由於您的 ASP.NET 專案現在面向更新的框架，並在更新式版本的 IDE 下運行，因此還應注意其他的一些問題。

如果將 ASP.NET 1.1 解決方案從 32 位作業系統遷移到 64 位作業系統，應意識到 IIS 6.0 及其更高版本同時支援 32 位和 64 位操作模式。由於 ASP.NET 1.1 僅在 32 位模式下運行，您可能會發現已轉換的 ASP.NET 應用程式仍包含 32 位依賴項（例如 COM 或 P/Invoke 調用），這些依賴項在遷移後可能無法繼續正常工作。若要修復此問題，請訪問應用程式的應用程式池的“高級設置”，並將“啟用 32 位應用程式”值設置為 True。

Visual Studio 2010 要求網頁與 XHTML 相容。您在 ASP.NET 1.1 中的頁面可能與 XHTML 不相容。因此，大多數頁面將會顯示 XHTML 驗證警告（若要查看這些警告，請在“源”或“設計”模式下查看頁面，然後訪問“查看”功能表並選擇“錯誤清單”）。雖然這些警告不會阻止頁面運行，但指明頁面無法在最新流覽器中正確呈現。如果時間允許，應更新頁面和使用者控制項以使它們與 XHTML 相容，從而確保頁面和使用者控制項在最新流覽器中正確呈現。如果您的 Web 應用程式特定于較舊版本的流覽器，或者此時不想為標記驗證錯誤費神，則可以更改標記的驗證方式，方法是轉到“工具”功能表，選擇“選項”，再轉到“文字編輯器”節點，然後將“目標”更改為 Internet Explorer 6（請參閱圖 10）。該方法僅適用于需要針對 Internet Explorer 6 進行開發的開發人員（例如，如果您的應用程式是企業 Intranet 應用程式）。這可以將呈現驗證有效設置為與在 Visual Studio 2003 中可能使用的級別所類似的級別。

圖 10 可以通過將 HTML 驗證目標更改為 Internet Explorer 6 來抑制 XHTML 驗證錯誤

對於必須在 Internet Explorer 以外的流覽器或 Internet Explorer 6 以上的版本中正確顯示的應用程式，應繼續在 HTML 編輯器中顯示 XHTML 標記錯誤，並充分利用作為 Web.config system.web 部分中的屬性提供的新 .NET Framework 4 controlRenderingCompatibilityVersion 配置設置。

<system.web>
  <pages controlRenderingCompatibilityVersion="4.0"/>
</system.web>

如果未在 Web.config 中設置 controlRenderingCompatibilityVersion，則預設為正在運行的 ASP.NET 的版本。 但是，當指定 controlRenderingCompatibilityVersion 值時，可以將其設置為“3.5”或“4.0”（轉換向導將其設置為“3.5”，以按照 ASP.NET 3.5 中的相同方式呈現頁面）。 該設置決定 .aspx 檔中指定的標記如何在流覽器中最終呈現。 若要引用 Visual Studio 2010 線上說明中的示例，如果 controlRenderingCompatibilityVersion 設置為“3.5”，則 IsEnabled 屬性設置為 false 的伺服器端 ASP.NET 標籤控制項將呈現“disabled”屬性設置為“disabled”的 HTML span 元素；如果 controlRenderingCompatibilityVersion 設置為“4.0”，生成的 span 元素將包含一個引用 CSS 類的“class”屬性。

您應注意到使用“4.0”設置可生成最新的 XHTML 標記，但這可能會破壞在 ASP.NET 1.1 版本頁面中正常工作的用戶端指令碼或 CSS 規則，從而將會影響所呈現的內容的行為和/或美感。 因此，直到完全認可，以產生有效的 XHTML，我建議您設定 controlRenderingCompatibilityVersion 到 「 3.5 」。如果您使用 [此 「 3.5 」 設定需要知道 xhtmlConformance (這只適用於 controlRenderingCompatibilityVersion 設為 「 3.5 」) 和其可被設定成 「 傳統，」 「 嚴格 」 或 「 轉換 」 (預設值)。 “Strict”可呈現 XHTML 1.0 Strict 標記；“Transitional”可呈現 XHTML 1.0 Transitional 標記；“Legacy”以類似于（不一定完全一樣）ASP.NET 1.1 中的呈現方式呈現 HTML：

<system.web>
  <pages controlRenderingCompatibilityVersion="4.0"/>
  <xhtmlConformance mode="Transitional"/>
</system.web>

根據我的經驗，應避免使用“Legacy”模式，因為它可能會妨礙 ASP.NET AJAX UpdatePanel 正常運行。 此外，還應注意，controlRenderingCompatibilityVersion 值不會更改網頁的 DOCTYPE，而僅會更改 ASP.NET 控制項自身的呈現方式。 因此，正確呈現頁面在很大程度上取決於 controlRenderingCompatibilityVersion、xhtmlConformance 和 DOCTYPE 值以及所用的目標流覽器類型和版本的組合。

另外，還應考慮以下事項：您可能需要更改在其下運行新遷移網站的虛擬目錄，尤其是在計畫與 ASP.NET 1.1 版本並行運行時。 為此，請在解決方案資源管理器中按右鍵 Web 專案，選擇“屬性”，然後訪問“Web”選項卡。 在“伺服器”下，您將看到“使用本地 IIS Web 伺服器”選項。 確保選中該選項，指定專案 URL（例如 http://localhost/mysitemigrated），如果虛擬目錄不存在，還請按一下“創建虛擬目錄”按鈕。

ASP.NET 1.1 應用程式利用 Windows ASPNET 使用者來分配對虛擬根目錄下的檔和資料夾的特權。 ASP.NET 2.0+ 利用 NETWORK SERVICE 使用者。 例如，如果應用程式要求 ASP.NET 具有特定檔或資料夾的寫入存取權限，也必須將這些許可權授予 NETWORK SERVICE 使用者。 如果您不確定需要該存取權限的使用者，可以通過在運行 ASP.NET 應用程式時檢查 Envionment.UserName 屬性的值來查看該使用者名。

如果使用任何協力廠商載入項或依賴項（無論是二進位檔案還是原始程式碼），則需要與供應商核實來確保您擁有最新的版本。 例如，常用的日誌記錄程式 NLog 提供 1.1 和 2.0 庫版本。 獲取 2.0 版本，避免花費精力遷移 1.1 代碼。 另外，供應商將為針對 Visual Studio IDE 設計的工作效率載入項提供更新。 務必執行升級，為新 Visual Studio 2010 IDE 獲取這些產品的最新版本。

遷移 ASP.NET 1.1 Web 應用程式後，將會發現可立即享受以下兩個好處。 首先，您無需再使用 Front Page Server Extensions (FPSE) 為網站提供支援（除非希望繼續使用 FPSE）。 其次，您無需再在開發電腦上安裝 IIS，因為 Visual Studio 2010 提供了自己的內置 ASP.NET Development Server。 雖然可以繼續並行運行 Visual Studio 2003 ASP.NET 應用程式和 Visual Studio 2010 ASP.NET 應用程式（例如，出於 QA/調試目的），但已轉換的 Visual Studio 2010 ASP.NET 應用程式無需再使用 Visual Studio 2003 或訪問 .NET Framework 1.1。

如果您是一位 C# 開發人員，可能注意到在設計模式下查看頁面和使用者控制項事件時，它們在“屬性”視窗中不再顯示為黃色的雷電圖示。 若要按照 Visual Studio 2003 中的相同方式查看/創建這些事件，必須在解決方案資源管理器中按右鍵該頁面 (.aspx) 或使用者控制項 (.ascx)，然後選擇“查看元件設計器”。 此時，您將看到包含熟悉的事件清單的“屬性”視窗。 您可以按兩下清單中的任何事件，以便創建事件程序和委託綁定代碼（從而將其添加到 InitializeComponent 函數）。

若要託管網站，應瞭解所需的 CLR。 如果使用 3.0 和 3.5 .NET Frameworks，將針對 CLR 2.0 運行；如果使用 .NET Framework 4，將針對 CLR 4.0 運行。 若要託管 ASP.NET 4.0 解決方案，您的託管公司必須支援 CLR 4.0。

希望我已經為您將 Visual Studio 2003 ASP.NET 應用程式遷移到 Visual Studio 2010 提供了説明。 一旦完成該任務，那麼您將進入一個隨您掌控的全新程式設計技術世界。 我相信這是一個相對容易接受的技術決策，您絕不會後悔。

Jonathan Waldman 为 PC Magazine 撰稿，是一位高級 Microsoft 認證專家，利用 .NET Framework 技術為桌面和 Web 全身心創建自訂軟體解決方案。可以通過 jonathan.waldman@live.com 與他聯繫。

衷心感謝以下技術專家對本文的審閱： Scott Hanselman