在客戶反饋的推動下，Visual Studio 2022 向64位架構過渡，標誌著增強開發體驗的關鍵一步。正如 Klaus Loffelmann 在他的部落格文章中所描述的那樣，這種轉換增強了整體效能和響應性，特別是在處理資源密集型任務和大型程式碼庫時。然而，這種演變給一些在 Visual Studio 2022 中使用 Windows 窗體設計器的 .NET Framework 專案帶來了顯著的挑戰。挑戰在於無法在 .NET Framework 專案中設計依賴32位引用的 Form，這是固有技術限制的結果，64位的 devvenv .exe Visual Studio 程序無法載入32位編譯的引用。對於使用 Windows Forms .NET Framework 專案的使用者來說，這個特定的障礙已經成為一個顯著的的採用性障礙，這些專案廣泛地利用了 ActiveX/COM 控制元件或嵌入在32位程式集中的其他自定義控制元件。到目前為止，這種情況的解決方案是使用 Visual Studio 2019，其中 Windows 窗體設計器作為32位程序執行，以適應這些專案的特定需求。
認識到這種轉變帶來的限制，以及它對開發人員的影響，我們一直在努力開發功能，為在最新的 Visual Studio 環境中設計傳統的 WinForms 32位 .NET Framework 應用程式鋪平道路。雖然這些最初的努力不會全面解決整個問題，但我們的目標是為使用者掃清障礙，並讓過渡到64位的 Visual Studio 2022 更順利。
在最新的 Visual Studio 2022 版本 v17.9 中，WinForms 團隊引入了一個預覽特性——對 .NET Framework 專案的程序外設計器支援。使用 .NET Framework 的程序外設計器的能力目前處於早期預覽狀態，我們急切地尋求開發人員的反饋，以完善和改進其功能。值得注意的是，Visual Studio 17.9 版本帶來了重要的增強，包括:
- 改進了 .NET Framework 專案的型別解析
- ActiveX/COM 支援 .NET Framework 和 .NET 專案
- 一個新的設計器選擇功能，用於監視 .NET Framework 專案中的32位程式集載入失敗
這些新增功能表明我們致力於積極參與社群，瞭解他們專案的複雜性，並穩步構建功能，為最佳的 Visual Studio 體驗鋪平道路。我們希望這種方法能夠使開發人員更容易地最終遷移到 .NET ，以獲得更現代平臺的所有好處，而無需完全重寫使用者介面。
什麼是設計器選擇功能?
當 WinForms 設計器檢測到32位程式集載入失敗時，它會顯示以下對話方塊，其中提供了為開發人員的專案選擇適當的設計器的選項：
選擇“Yes”，專案將被重新載入，Windows 窗體程序外設計器將開始發揮作用。如果專案的目標是x86，設計器將啟動一個32位程序來在設計器中呈現 Form。該程序標識為“FxDesignToolsServer.exe”。在這個程序中，控制元件程式集被載入，並執行 InitializeComponent 方法中與指定框架對齊的程式碼。
如果選擇“No”，專案將繼續使用程序內設計器，儘管您仍然無法設計引用32位元件的Form，因為32位二進位制檔案無法在64位程序中載入。
使用“Yes/No”按鈕，設計器選擇將僅為當前 Visual Studio 例項記住此設定。若要自動將設計器選擇新增為專案配置屬性，請啟用“Remember for current project”選項。它將新增“UseWinFormsOutOfProcDesigner”屬性到每個專案配置。WinForms 設計器將讀取此屬性值，以便在下次在 Visual Studio 中開啟專案時自動選擇所需的設計器版本(程序內或程序外)。下面是新增此屬性後的示例專案配置：
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' "> <PlatformTarget>x86</PlatformTarget> <OutputPath>bin\Debug\</OutputPath> <UseWinFormsOutOfProcDesigner>True</UseWinFormsOutOfProcDesigner> </PropertyGroup>
請注意，設計器選擇功能目前處於以下預覽功能標誌下，在 Visual Studio 2022 17.9中預設啟用:
您可以在 Visual Studio的Tools -> Options -> Preview Features 下啟用或禁用該特性。
當您在 .NET Framework 專案中使用程序外設計器時，會顯示下面的資訊欄:
這個特效能做什麼，不能做什麼
與將所有與第三方控制元件相關的程式集載入到 Visual Studio 程序中的程序內設計器相比，程序外設計器要更加挑剔；它將設計時程式集載入到專用伺服器程序或客戶端 Visual Studio 程序中。由於程序外設計器的客戶機-伺服器架構，程式集載入中的這種區別是必要的，因此，第三方控制元件供應商需要使用新的設計器 SDK 來為程序外設計器提供控制元件。請注意，為客戶端和伺服器程序建立不同的設計時程式集對於支援簡單的場景來說並不是必需的，但是對於更高階的場景來說卻是必需的。因此， .NET Framework 專案的程序外設計器將無法處理為程序內設計環境設計的所有第三方控制元件。如果遇到這樣的控制元件，則可能會忽略與設計器無法呈現的控制元件相關的程式碼。因此，我們建議您事先建立專案的備份。
- 專案中引用的控制元件將不會出現在工具箱中，在解決方案中的其他形式中使用。我們的目標是在即將釋出的版本中新增此功能。
- 當在程序外設計器中載入具有自定義 CodeDOM 序列化器的控制元件時，設計器目前將忽略 InitializeComponent 中生成的程式碼(因為它不能像以前那樣執行 CodeDOM 序列化器)。我們希望在未來的版本中新增警告，讓您提前知道專案將無法載入特定的元件。
旁註：您可能會發現，在使用新的 SDK 風格專案檔案的 .NET Framework 專案中，與舊的傳統 csproj 檔案相比， InitializeComponent 方法生成的程式碼有很大的不同。這是因為程序外設計器在遇到 SDK 風格的專案時，會在後臺利用 Roslyn 進行程式碼生成，而不是使用較舊的 CodeModel 技術。從長遠來看，這對您的程式碼來說是一個巨大的勝利，並且支援未來的多目標和遷移路徑。對於那些遺留的 csproj 風格專案生成的程式碼可能會有一些小的調整，但這些將不那麼重要，如果在 VS 2019 中開啟相同的專案，將會工作得很好。
程序外設計器支援 .NET Framework 專案的路線圖
正如之前提到的，我們計劃在即將釋出的 Visual Studio 版本中增加對程序外設計器的以下特性的支援:
- 增強工具箱對解決方案中引用的控制元件的支援。
- 當設計器無法使用自定義 CodeDOM 序列化器載入控制元件時，會發出更詳細的警告。
如何為64位世界做準備?
對於在程式碼中使用傳統32位元件的 WinForms .NET Framework 應用程式的開發人員來說，這個特性並不是為了使過渡到 Visual Studio 2022 沒有任何動作。自從建立了許多遺留元件以來，開發環境發生了巨大的變化。例如，它們中的許多不符合今天的程式碼安全標準。設計器選擇功能，以及在程序外設計器中對 .NET Framework WinForms 應用程式的相關支援，旨在為您的應用程式提供最終解決方案的短期橋樑。從長遠來看，目前使用32位元件的應用程式有兩個潛在的選擇：要麼將元件升級到 AnyCPU 或64位，要麼最好將應用程式升級到 .NET 8 或更高版本。.NET 8 平臺在 WinForms 應用程式中完全支援32位 COM 和 ActiveX 控制元件。還有一個強大的第三方控制供應商生態系統，每天都在增長。
要了解更多關於 WinForms 採用32位元件的策略，請參閱 Klaus Loffelmann 和 Merrie McGaw 最近的部落格:《WinForms in a 64-Bit world – our strategy going forward》。
結語
我們感謝您花時間報告問題/建議，並希望您在使用 Visual Studio 時繼續給我們反饋，告訴我們您喜歡什麼以及我們可以改進什麼。您的反饋對於幫助我們使 Visual Studio 成為最好的工具至關重要！您可以透過開發者社群與我們分享反饋，透過傳送反饋來報告問題或分享您的建議，推動對新功能或現有功能的改進。
透過在 YouTube, Twitter, LinkedIn, Twitch 和 Microsoft Learn 上關注我們與 Visual Studio 團隊保持聯絡。
原文連結：https://devblogs.microsoft.com/visualstudio/winforms-designer-selection-for-32-bit-net-framework-projects/
