Windows 應用程式 開發常見問題

本常見問題解答了關於 Windows 應用程式開發的常見問題，包括如何為您的專案選擇合適的框架的指引。 涵蓋的主題包括：

  • 入門與 Windows 應用程式開發的現況。
  • 原生 Windows 專用應用程式開發，使用 WinUI 3、Windows Presentation Foundation（WPF）及 Windows Forms（WinForms）。
  • Windows 軟體開發套件（SDK）和 Windows 應用程式 SDK。
  • 將 Windows 作為跨平台開發策略的一部分。
  • 混合式及網頁應用程式開發，使用 .NET MAUI、Blazor 及 ASP.NET Core。
  • 如何在理解 Microsoft 投資的同時選擇策略。

Windows 應用程式開發環境

哪裡可以找到Windows開發技術的直白概述？

想了解目前 Windows 開發者的選項，請觀看 Windows Dev Chat 節目《選擇你的理想開發平台》，該集討論了 WinUI 3、.NET MAUI、React Native、Blazor 以及 Progressive Web Apps（PWA）。 你可以在 Windows 開發者聊天播放清單中找到其他集數。

你也可以參考應用程式開發選項概覽，給Windows開發者參考。

為什麼在cloud services時代，客戶端應用程式開發對現代數位轉型仍至關重要？

在雲端服務時代，客戶端應用程式開發對於在使用者裝置上提供響應式且有意義的互動依然至關重要。

以下是客戶應用程式重要的原因：

  • 裝置範圍： 客戶端應用程式讓你能直接將應用程式帶給使用者，使用他們選擇的裝置。
  • 智慧型服務的閘道： 用戶端應用程式通常是使用者首度與服務互動的介面。 它們提供豐富的互動介面，使您能夠展示智慧功能，將您的產品與其他產品區分開來。
  • 雲端整合的可擴展性：一個整合良好的客戶端應用程式能輕鬆與後端雲端服務同步，隨著用戶群成長，實現即時資料存取與無縫擴展。
  • 增強生產力和用戶忠誠度： 經過深思熟慮的設計應用程式可以提升生產力，並讓使用者持續參與您的產品或服務。

僅適用於 Windows 的原生應用程式開發

是什麼 Windows 應用程式 SDK？

Windows 應用程式 SDK 為 Windows 桌面應用程式提供獨立服務的元件，包括 WinUI 3、應用程式生命週期、視窗、通知、資源及文字 API。 它支援在 Windows 10、版本 1809 及以上版本上運行的應用程式，前提是必須遵守 Windows 版本及 Windows 應用程式 SDK 版本的支援生命週期。

Windows 應用程式 SDK 和 Windows SDK 有什麼不同？

兩者都是軟體開發套件（SDK），讓你能建立 Windows 應用程式。

Windows 應用程式 SDK 提供獨立於 Windows 發行的元件，可在受支援的各個 Windows 版本上運作，最低可支援至 Windows 10 版本 1809。 它包含 WinUI 3 以及應用程式生命週期、視窗、通知、資源、文字和其他功能的 API。

Windows SDK 提供標頭、函式庫、元資料及作業系統 API 的工具，如 Win32、WinRT、COM、DirectX、裝置及 shell 功能。

Windows 應用程式 SDK 並不會取代 Windows SDK。 採用 Windows 應用程式 SDK 的應用程式仍可繼續使用 Windows SDK API，而 WinUI 3 應用程式通常同時使用兩者。

我正在組建一支新團隊，準備開發一款僅限 Windows 的應用程式。為什麼我要選擇使用原生的 Windows 框架，如 WinUI 3、WPF 或 WinForms？

以下是選擇原生Windows框架作為純Windows應用程式的一些理由：

  • Performance： 原生Windows框架優化以利用現代Windows硬體，提供快速且反應靈敏的使用者體驗。
  • Integration： Windows 內建多種 API，能提供僅在 Windows 上才能有的複雜體驗。 原生框架能深度整合這些功能與 API。
  • Native 使用者體驗： 原生框架在Windows裝置間提供一致的體驗，確保您的應用程式在各處看起來與運作都非常出色。
  • 離線支援： 原生框架支援離線情境，讓應用程式即使沒有網路連線也能正常運作。
  • 支援與工具：Microsoft 維護原生框架，並提供最新 SDK、文件、除錯工具及範例。
我該用哪個框架來善用Microsoft在Windows應用程式開發上的最新投資？

如果你正在打造一個新的通用 Windows 桌面應用程式，我們建議使用 WinUI 3。 WinUI 3 是隨 Windows 應用程式 SDK 提供的原生 UI 框架。 它支援 Windows 桌面應用程式，並提供最新的 Fluent 控制項及 Windows 平台功能。

我可以在現有的 Windows 應用程式中使用 Windows 應用程式 SDK / WinUI 3 嗎？

請注意，WinUI 3（一個 UI 框架）隨 Windows 應用程式 SDK（一個 Windows 平台開發框架）一起出廠。

你可以將應用程式的使用者介面遷移到 WinUI 3，或使用 WinUI XAML Islands 在支援的現有桌面主機上架設 Windows 應用程式 SDK 控制項。 舊有系統 XAML Islands 托管 UWP XAML 控制項並使用不同的 API。

Windows 應用程式 SDK 的元素通常可以用於桌面應用程式，視現有應用程式的建置方式而定。 UWP 應用程式不支援 Windows 應用程式 SDK。

這表示 WPF/MFC/WinForms 應用程式可以使用與 WinUI 3 無關的 Windows 應用程式 SDK API。 例如應用程式生命週期、視窗管理和應用程式通知。

更多資訊請參見 在現有專案中使用Windows 應用程式 SDK。

我需要使用 Visual Studio 來建立 WinUI 3 應用程式嗎？

否。 WinUI 3 的 XAML 編譯版使用 MSBuild，但你也可以在另一個編輯器的命令列用 .NET SDK 和現有的 WinUI 3 範本編譯。 請參閱 命令列快速啟動。

Visual Studio 2026 提供最豐富的整合編輯、除錯、設定檔及 XAML 熱重新載入 體驗。 使用符合你工具需求的工作流程。

我在執行應用程式時會跳出「無法載入 DLL 'Microsoft.ui.xaml.dll'」的錯誤。我該怎麼解決？

此錯誤通常發生在unpackaged應用情境中，且該Windows 應用程式 SDK執行時尚未安裝於機器上。 嘗試下列作業：

  • 如果你使用的是 packaged 應用程式（建議預設），請確保你透過 Visual Studio 啟動時選擇了 MsixPackage啟動設定檔（而非普通的執行檔設定檔）。 MSIX 封裝步驟會安裝所需的執行時元件。
  • 如果你使用的是依賴框架的未封裝應用程式，請安裝相應的 Windows 應用程式 SDK 執行環境。 自包含部署包含其 Windows 應用程式 SDK 所需的相依性。
  • 確認你的專案是否符合你的部署模式。 對於一般的 .NET 未封裝應用程式，設定<WindowsPackageType>None</WindowsPackageType>會啟用 Windows 應用程式 SDK 執行時自動初始化。 只有在需要明確控制動態相依初始化時，才直接使用 bootstrapper API。

更多關於部署需求的詳情，請參見使用 Windows 應用程式 SDK 部署應用程式。

WinUI 3 和 WinUI 2 在 UWP 上有什麼不同？

WinUI 3 是 Microsoft 目前為 Windows 桌面應用程式提供的原生 UI 框架，並作為 Windows 應用程式 SDK 的一部分提供。

WinUI 2，也稱為 WinUI for UWP，是一套用於 UWP 應用程式的控制與樣式函式庫。 WinUI 2 和 WinUI 3 使用 XAML 命名空間不同，且不相容二進位。

當我使用 Windows 應用程式 SDK 和 WinUI 3 建立應用程式時，我是在建立一個「WinUI 應用程式」嗎？

是的。 WinUI 3 應用程式是最明確的名稱，指的是其介面使用 WinUI 3 和 Windows 應用程式 SDK 的應用程式。 WinUI 應用程式 也常用於上下文明確的環境。

我可以逐步將 UWP 應用程式的 WinUI 控制項更新到 WinUI 3，並逐步更換控制項嗎？

否。 Windows 應用程式 SDK 不能用在 UWP 應用程式中，而 WinUI for UWP 也不能和 WinUI 3 混合使用。 請參見 從 UWP 遷移到 Windows 應用程式 SDK。

將 UWP 應用程式遷移到 WinUI 3 有多困難？

UWP 和 WinUI 3 共享許多 XAML 概念，但遷移並非直接更改命名空間。 費用主要取決於：

  1. Project 檔案與 MSBuild 自訂：遷移工作量會依進階 MSBuild 使用情況而異。
  2. .NET API 遷移：使用 .NET Native 的 UWP 應用程式可遷移至目前支援的 .NET 版本，並搭配 Native AOT。 這次現代化與將 UI 遷移到 WinUI 3 是分開的。
  3. UI 元件函式庫： 函式庫必須有針對 WinUI 3 的版本。
  4. 視窗與應用程式模型 API：與例如 CoreWindow、ApplicationView 或 GetForCurrentView 等概念相關聯的 UWP API，需要改用 Windows 應用程式 SDK 的對應 API 或其他桌面應用程式做法。
  5. C++ 語言投影：如果 UWP 應用程式使用被取代的 C++/CX 投影，請將該程式碼移植到 C++/WinRT。

欲了解更多資訊，請參閱從 UWP 遷移至 Windows 應用程式 SDK 及 UWP 至 Windows 應用程式 SDK API 映射。

如果我在商店裡已有 UWP 應用程式，我可以發佈一個新的 WinUI 3 應用程式，使用相同的識別碼嗎？

是的，升級版的應用程式可以在不更新應用程式身份的情況下發佈。 舊版本的用戶將更新至新版本。 這只適用於桌面應用程式。 Xbox、HoloLens 以及標準的 Surface Hub 應用程式無法遷移到 WinUI 3。

我該如何打包或發佈我的 WinUI 3 應用程式？

請參閱 「套件與部署概述」。

我在哪裡可以找到Windows 應用程式 SDK遷移指引？

請參見 從 UWP 遷移到 Windows 應用程式 SDK。

如果我想使用 WinUI 3，是否需要使用 XAML 標記？

否。 UI 控制項可以在程式碼中建立。 然而，以宣告式 XAML 標記表示 UI 帶來許多好處，包括提升開發者體驗。

  • 從 UWP 遷移到 WinUI 3：許多 XAML 和 UI 概念會延續，但命名空間、專案模型和部分 API 有所不同。
  • 從 WPF 遷移到 WinUI 3：許多概念會延續，但控制項集和 API 有所不同。
Visual Studio 有 WinUI 3 的設計表面或 UI 設計器嗎？

目前不行。 使用 XAML 熱重新載入、Live Visual Tree、Live Property Explorer 及相關的執行時工具，在應用程式執行時檢查並更新 XAML。

欲完整了解 WinUI 3 執行時設計工具，請參見 XAML 執行時設計工具（適用於 WinUI 3）。

Windows 應用程式 SDK 包含 WinUI 3 嗎？

是的。 WinUI 3 隨附於 Windows 應用程式 SDK。

Windows 應用程式 SDK 有包含 UWP 的 WinUI 嗎？

否。 UWP 的 WinUI 是 UWP 平台的一部分。

UWP 和 WinUI 3 的 WinUI 是基於相同技術打造的嗎？

不完全正確。 雖然 WinUI 3 源自於 WinUI for UWP 的程式碼基底，但兩者是不同的技術。 兩者都是基於 XAML 的 UI 框架，能跨越 .NET 和 C++，但 UWP 和 WinUI 3 的 WinUI 彼此不相容。

我可以在不使用 Windows 應用程式 SDK 的情況下使用 WinUI 3 嗎？

否。 WinUI 3 隨附於 Windows 應用程式 SDK。

我可以在未封裝的應用程式中使用 WinUI 3 嗎？

是的。 WinUI 3 和許多 Windows 應用程式 SDK API 可以在未封裝的應用程式中運作。 然而，某些 Windows 功能需要套件識別碼，且依賴框架的未封裝應用程式必須初始化 Windows 應用程式 SDK 執行環境。 比較包裝 概覽 與 需要套件識別的特徵中的選項。

XAML Islands 和 WinUI 3 有什麼不同？

WinUI 3 是 Windows 應用程式 SDK 中包含的 UI 框架。 XAML Islands 是一種主機技術，讓現有桌面應用程式能將 XAML 內容與來自其他框架的 UI 並置。

此術語可指承載 UWP XAML 控制項的舊有系統 XAML 島，或是在支援的桌面主機中承載 Windows 應用程式 SDK 控制項的 WinUI XAML 島。 API、命名空間和主機需求各不相同。

如果我建立一個 WinUI 3 應用程式，它在 Windows 11 和 Windows 10 上看起來會很現代嗎？

WinUI 3 控制項在受支援版本的 Windows 10 和 Windows 11 上，無論是封裝或未封裝的應用程式，皆採用 Fluent 樣式。 部分作業系統的效果與行為會因 Windows 版本而異。 例如，Mica在Windows 11上可用，但在Windows 10上則回復為純色。

我可以在用 Windows 應用程式 SDK 的應用程式中使用雲母或壓克力背景嗎？

是的。 Desktop Acrylic 支援 Windows 10 1809 版及更新版本。 Mica 需要 Windows 11，且在 Windows 10 上會回復為純色主題色。 在套用背景幕之前，請先在執行階段呼叫 DesktopAcrylicController.IsSupported 或 MicaController.IsSupported。 請參考在 Windows 11 桌面應用程式中應用雲母或壓克力材料。

我在哪裡可以找到 WinUI 3 的範例？

請參閱範例和資源。 一些值得注意的存放庫：

如果我已經大量投資 WPF，應該繼續使用 WPF 還是考慮遷移到 WinUI 3？

如果你已經在 WPF 投入大量資源，可以繼續用它來管理現有應用程式。 WPF 是一個成熟且穩定的框架，廣泛用於建置 Windows 桌面應用程式。

使用 GitHub Copilot 升級來評估並升級一個 .NET Framework 的 WPF 應用程式到現代版的 .NET。 檢視已產生的計畫，並在你的應用程式中驗證每一項變更。

如果我建立一個新的WPF應用程式，會不會看起來比其他新的Windows應用程式過時？

在開發使用 .NET 9 或更新版本的 WPF 應用程式時，你可以確保你的應用程式與 Windows 11 的流暢現代外觀相符。 WPF 的新 Fluent 主題引入了當代 Windows 11 美學，整合了明暗模式及系統強調色彩支援。 這能現代化你的應用程式外觀，帶來精緻且統一的使用者體驗。

我的團隊擅長開發 WinForms 應用程式，且它符合我們的需求。我們應該考慮遷移到 WinUI 3 或其他框架嗎？

如果 WinForms 符合你的需求，且團隊對它感到熟悉，你就可以繼續使用 WinForms 來處理現有的應用程式。 WinForms 是一個成熟且穩定的框架，廣泛用於 Windows 桌面開發。

WinForms 團隊持續投資於該平台。 近期及持續進行的工作包括：

  • 非同步表單與對話 API
  • 暗黑模式與視覺風格支援
  • 無障礙性、高DPI、版面設計與設計師改進
  • 剪貼簿與 DataObject 的現代化改造

跨平臺原生開發

有哪些理由要打造跨平台、原生應用程式來針對Windows？

如果你目標是跨多個作業系統平台的使用者，使用 .NET MAUI 或 React Native 來打造跨平台應用程式，可以帶來多項好處：

  • 覆蓋範圍： 跨平台應用程式能在不同裝置與作業系統上覆蓋更廣泛的群體。
  • 程式碼重用： 跨平台重複使用程式碼，減少開發時間與成本。 為 Windows、Android、iOS 和 macOS 分別開發應用程式的成本可能高得令人望而卻步。
  • 穩定的使用者體驗： 跨平台框架有助於提供跨平台一致的外觀與操作感。
  • 整合： 跨平台應用程式仍可整合平台專屬服務，提供完整的體驗。
我可以確定.NET MAUI應用程式在 Windows 上能順利運行嗎？

當你為 Windows 建置 .NET MAUI 應用程式時，輸出會使用 WinUI 3。 在開發過程中，.NET MAUI 提供跨平台的單一 .NET 體驗，但在底層卻產生平台專屬的程式碼。

.NET MAUI 如何在每個平台上提供原生裝置 API？

.NET MAUI 提供跨 Windows、iOS、Android 及 macOS 的統一 .NET 體驗。 它提供跨平台 API，支援儲存、網路及裝置感測器等共通功能。 你也可以呼叫平台專屬的 API，或為每個平台提供專門的實作。

我可以先從 WinUI 3 開始，之後如果想針對跨平台場景，再整合 .NET MAUI 嗎？

目前不是。 雖然 .NET MAUI 在 Windows 上運行時使用 WinUI 3，但預期針對多平台的團隊應該從 .NET MAUI 或桌面版 React Native 開始。

我們團隊具備強大的網頁前端開發能力。我們應該考慮在桌面版使用 React Native 嗎？

有豐富網頁開發經驗的團隊可以考慮 React Native for Desktop。 它包含適用於Windows和macOS的 React Native。 採用「學一次，隨處寫」的做法，現有的 JavaScript、TypeScript 和 React 技能可以用來打造原生的 Windows 和 macOS 應用程式。

React Native for Desktop 直接將使用者介面渲染到低階原生元素，以提供原生效能及平台功能。

若要開始，請參考React Native for Desktop 文件。

React Native for Desktop 還支援其他Windows裝置嗎？

React Native for Windows 支援其相容性文件中列出的 Windows 版本。 請確認你目標的 React Native for Windows 版本的裝置家族支援，而不是假設所有 Windows 裝置都支援。

如果我想打造能在Windows和Xbox上運作的應用程式，該用什麼？

對於 Xbox 應用程式，請使用 UWP，並考慮 Xbox 專屬的 UWP 限制。 遊戲開發時，使用 Microsoft 遊戲開發套件。

如果我想打造能在 Windows 和 Surface Hub 上運作的應用程式，應該用什麼？

對於運行標準 Teams Rooms 或 Surface Hub 環境的 Surface Hub，請使用符合 Surface Hub 應用程式要求的 UWP 應用程式。 配置為 Windows 11 Pro 或 Enterprise 的 Surface Hub 3 可以執行支援的桌面應用程式技術，因此 UWP 並非該配置中唯一的選項。

混合式和 Web 開發

什麼是混合式應用程式？為什麼我應該考慮打造一個？

混合式應用程式會混合 Web 和原生應用程式開發的最佳功能。 其核心是利用 HTML、CSS 和 JavaScript 等網頁技術建構，並包裝在原生容器中，能access某些原生平台功能與硬體。 它們也可以透過應用商店散發。

主要優點是混合式應用程式允許你打造一個能在多個原生平台和網頁上運行的單一應用程式，降低開發時間與成本。 混合式應用程式開發平台的範例包括：

  • Electron 桌面應用程式
  • Ionic手機應用程式
  • .NET MAUI Blazor Hybrid 用於跨平台應用程式
我該如何在 Windows 上建立帶有原生感的漸進式網頁應用（PWA）？

詳見在Windows上的Web開發及漸進式Web應用程式概述。

什麼是.NET MAUI Blazor 混合應用程式？

透過 .NET MAUI，Blazor 應用程式能原生運行於 Windows、iOS、Android 和 macOS。 這讓你能建立結合 Blazor 與 .NET MAUI 元件的混合客戶端應用程式，並能完整存取原生平台功能。

欲了解更多資訊，請見 ASP.NET Core Blazor Hybrid。

.NET MAUI混合應用程式的網頁元件需要用 Blazor 建立嗎？

否。 從 .NET 9 開始，.NET MAUI 包含 HybridWebView 控制項，允許在原生應用程式中托管其他基於 JavaScript 的使用者介面。

這讓你能在 .NET MAUI 應用程式中架設 Angular、React、Vue 或其他 HTML/JavaScript 應用程式。 混合控制項提供 C# 與 JavaScript 之間的互通性，因此 C# 程式碼可以呼叫 JavaScript 函式，反之亦然。

其他原生應用程式類型能否承載 Blazor 混合元件？

是的。 WPF 與 WinForms 應用程式也能承載 Blazor 混合元件，讓現有應用程式能新增現代化的網頁介面。 這不支援基於 .NET Framework 建置的 WPF 或 WinForms 應用程式。

我的整個應用程式需要是混合式應用程式，還是可以混合搭配原生和混合元件？

原生與混合元件可以混用在應用程式中。 例如，應用程式的核心可能由 .NET MAUI 元件建構，而混合元件則提供額外功能。 這使得能結合原生元件的性能與能力，與混合元件的彈性與成本效益。

我有哪些選擇可以打造在現代瀏覽器上看起來很棒的.NET網頁應用程式Windows？

Web apps 是所有客戶端應用平台中覆蓋範圍最廣的。 製作美麗 .NET 網頁應用程式的選項包括：

  • ASP.NET Core 應用程式搭配 Razor Pages
  • ASP.NET Core MVC 應用程式
  • ASP.NET Core Blazor 應用程式，提供主機模型選項：
    • Blazor WebAssembly（Blazor 網頁組件）
    • Blazor Server

Blazor 主機模型現在可以在元件層級設定，實現像是在 Blazor Server 應用程式中託管 Blazor WebAssembly 元件等情境。

詳情請參見 ASP.NET Core 文件。

選擇一種方法，了解 Microsoft 的投資

有非常多針對Windows的應用程式框架選項！我該怎麼決定？

Windows 是一個開放平台，支援多種技術。 以下是一些能幫助你選擇平台的標準：

  • 你是以 Windows 為優先進行開發，還是進行跨平台開發？
  • 你已經掌握哪些語言或技能——.NET、JavaScript，還是其他什麼？
  • 你需要存取 Windows 專用的 API 嗎？
  • 哪個框架的功能最符合你應用程式的需求？
  • 更多比較因素請參 見此表 。

對於許多商業應用程式，團隊通常會根據現有技能及團隊最熟悉的使用方式來選擇。

我如何選擇最適合我的網頁應用程式的開發方法？

在為您的網頁應用程式選擇開發方法時，請考慮以下幾點：

  • Blazor 推薦用來用 .NET 建置前端網頁應用程式。 它讓你能用 .NET 來建立前端和後端，節省時間和成本，尤其適合企業應用程式。
  • 如果你想善用現有的 JavaScript 技能，或是需要與既有的 JS 函式庫或框架整合，JavaScript web apps 仍然很有意義。
  • 使用舊框架如 Web Forms、MVC 或 Razor Pages 的現有應用程式仍受支援，且可持續開發與維護。
現在誰在用 WinUI 3 開發應用程式？

Microsoft Photos 就是一個有紀錄的例子。 該應用程式從 UWP 遷移到 Windows 應用程式 SDK，並持續使用 WinUI 3。 關於架構與遷移的詳細資訊，請參閱 Microsoft Photos：從 UWP 遷移到 Windows 應用程式 SDK。

現在誰在開發.NET MAUI應用程式？

組織使用 .NET MAUI 來打造跨平台應用程式，支援 Android、iOS、macOS 及 Windows。 請參見 .NET 客戶展示會的範例。

現在誰在開發WPF應用程式？

大部分Microsoft Visual Studio介面都是用WPF打造的。 Visual Studio IDE 本身就是一個複雜且高效能的 WPF 應用程式範例。

現在誰在打造 Blazor 應用程式？

GE Digital 的 FlightPulse 航空系統使用 Blazor 來設定飛行員所見所有的後端設定，將感測器數據與分析直接提供給飛行員，以提升安全性與效率。

在.NET網站上查看更多Blazor客戶故事。

語言選擇（.NET 與 C++）

我應該用 C# 還是 C++ 來管理我的 Windows 應用程式？

大多數情況下使用 C#（.NET）。 C# 提供更快的開發速度、記憶體安全、豐富的函式庫和優秀的工具。 大多數 Windows 應用程式——包括 WinUI 3、WPF、WinForms 和 .NET MAUI 應用程式——最好用 C# 來編譯。

請使用 C++，當你需要直接存取硬體、最低的執行階段負擔，或與現有 C++ 程式碼庫互通時。 常見的 C++ 情境包括遊戲引擎（DirectX）、驅動程式、系統層級的工具程式，以及對效能至關重要的元件。

因數 C#（.NET） C++
開發速度 ✅ 更快 — 管理記憶體，豐富的生態系統 ⚠️ 較慢 — 手動資源管理
執行時效能 ✅對現代 .NET（AOT、Span<T>）支援出色 ✅ 最佳情況——沒有 GC 暫停
記憶體安全 ✅ 垃圾回收 ⚠️ 手冊 — 洩漏與漏洞風險
Windows API 存取 ✅ 透過 C#/WinRT 投影 ✅ 透過 C++/WinRT 投影
WinUI 3 支援 ✅ 完整支援 ✅ 透過 C++/WinRT 完全支援
跨平台 ✅.NET 可在 Windows、Linux、macOS 上運行 ✅ 使用平台專屬程式碼
最適合用於 商業應用程式、CRUD、服務、介面密集的應用程式 遊戲、驅動程式、系統工具、低延遲

你也可以兩者混合：用 C# 建置應用程式，並透過 P/Invoke（CsWin32） 或 C++/WinRT 元件呼叫對效能至關重要的原生程式碼。

我要如何從 C# 呼叫 Win32 API？

使用 CsWin32，這是一個可在建置階段產生型別安全 P/Invoke 簽章的原始碼產生器。 你加入 Microsoft.Windows.CsWin32 NuGet 套件，在檔案 NativeMethods.txt 中列出你需要的 API，然後透過產生 PInvoke 的類別呼叫它們。

CsWin32 取代手寫[DllImport]宣告，並可在任何 C# 專案中使用，包括 WinUI 3、WPF、WinForms 及主控台應用程式。 請參閱「從 C# Windows 應用程式呼叫 Win32 API」（CsWin32）以獲得逐步教學。

什麼是 C++/WinRT？我應該什麼時候使用它？

C++/WinRT 是一種標準的 C++17 語言投影，適用於 Windows 執行階段 API。 在使用 C++ 建置會使用或撰寫 WinRT API 的 Windows 應用程式時，請使用它。 它取代了 C++/CX 以及 Windows 執行階段 C++ 模板函式庫（WRL）。

當以下情況選擇 C++/WinRT：

  • 你正在打造一個 C++ WinUI 3 應用程式
  • 你需要編寫供其他語言使用的 Windows 執行階段 元件
  • 你是從 C++/CX 移植過來的
什麼是 C#/WinRT？我什麼時候需要它？

C#/WinRT 為 C# 提供 WinRT 投影支援。 大多數情況下你不會直接與它互動——針對 Windows 的 .NET 應用程式會透過目標框架名稱（TFM）自動取得 WinRT API 的存取權。 在用 C# 撰寫 Windows 執行階段 元件，或為第三方 WinRT 元件產生互操作組件時，你明確需要 C#/WinRT。

封裝、部署和更新

打包、未打包和帶有外部位置的應用程式有什麼差別？

打包後的應用程式會將其檔案、身份與部署資訊整合在像 MSIX 這樣的套件中。 未封裝的應用程式會使用安裝程式或部署程序，且在Windows套件系統之外，預設沒有套件身份。 以外部位置方式封裝的應用程式會使用小型識別套件，同時保留位於外部位置的二進位檔，以及其現有的安裝程式和更新流程。

請參閱 包裝概述 以了解需求與取捨。

我需要套件識別嗎？

這取決於你的應用程式使用的 Windows 功能。 套件識別是已封裝的背景工作、分享目標、啟動工作、自訂內容功能表套件擴充功能、以資訊清單為基礎的檔案類型與通訊協定關聯，以及許多 Windows AI API 等案例所必需的。 Windows 應用程式 SDK 推播通知在沒有身分識別的情況下，僅支援有限的前景情境，但背景傳遞和 COM 啟用則需要具備身分識別。 WinUI 3 和本地應用程式的通知可以在沒有套件身份的情況下運作。

請參閱需要套件識別的功能。 如果您需要身分識別，但必須保留現有的安裝程式，可以考慮使用外部位置進行封裝。

依賴框架部署與自包含部署有什麼不同？

依賴框架的應用程式會使用分別安裝在裝置上的 Windows 應用程式 SDK 執行時套件。 這減少了應用程式的部署規模，並讓已安裝的框架能接收服務更新。 自含式應用程式會隨附其 Windows 應用程式 SDK 相依性，這會增加部署大小，並使應用程式發行者必須隨新的應用程式版本一併散發 Windows 應用程式 SDK 維護更新。

依賴額外 MSIX 套件的 API，如 Singleton 套件，即使在自成一體的應用程式中，也可能需要獨立的部署或執行時支援檢查。 封裝與執行時部署是分開的決策。 請參閱 Windows 應用程式 SDK 部署概觀。

我的 WinUI 3 應用程式會自動更新給終端使用者嗎？

WinUI 3 應用程式可以透過 Microsoft Store、.appinstaller檔案、MSI 或設定執行檔提供。 商店套件可透過 Microsoft Store 服務更新，但須依 Store 及組織設定而定。 .appinstaller 部署僅在其 UpdateSettings 會設定啟動時檢查或背景檢查時，才支援自動更新。 MSI 與安裝程式部署必須提供或整合自己的更新機制。

我可以用Windows 應用程式 SDK而不使用 MSBuild 嗎？

是的，在某些情況下可以。 WinUI 3 XAML 專案目前需要 MSBuild，雖然 Visual Studio 並非必須，且dotnet build可從命令列呼叫 MSBuild。 你可以透過預覽版 Windows 應用程式 Development CLI 使用來自 C++ 和 CMake 專案的非 XAML Windows 應用程式 SDK API，或手動整合執行環境。

Windows 人工智慧

我該如何在 Windows AI API、Foundry Local 和 Windows ML 之間做選擇？

前三項技術是 Microsoft Foundry 在 Windows 上的一部分。 你可以在同一個應用程式中將它們彼此結合，並與雲端模型結合：

  • 使用 Windows 的 AI API 來獲取現成型功能，這些功能由 Windows 管理其模型與硬體加速。
  • 使用 Foundry Local 在本地發現、下載並執行支援的開源語言與語音模型。
  • 使用 Windows ML 來執行你自己的 ONNX 模型，並搭配可用的 CPU、GPU 和 NPU 硬體執行提供者。
  • 當你需要雲端模型、檢索、集中治理或目標裝置無法具備的功能時，請使用 Microsoft Foundry，這是一個獨立的雲端 AI 平台。

比較「選擇你的 Windows AI 解決方案」中的選項。 考慮模型能力、隱私、連線性、延遲、硬體覆蓋範圍、部署規模及營運成本。

Windows AI 功能需要 Copilot+ PC 嗎？

不是全部。 許多 Windows AI API 需要 Copilot+ PC，但有些 API 也支援特定的 GPU 或 CPU。 Foundry Local 與 Windows ML 支援更廣泛的硬體配置，但須依其當前作業系統、型號、執行時及執行提供者的需求。

請查看 Windows AI API 硬體表及該 API 或模型的需求。 在執行時偵測支援與模型準備狀態，並在功能無法使用時提供非 AI、本地模型或雲端備援。

Windows 的 AI 功能可以在本地和離線模式下執行嗎？

是的。 Windows AI API、Foundry Local 和 Windows ML 可以在使用者裝置上執行推論，這能降低延遲並保持輸入資料在本地。 某些模型或執行提供者必須先下載或配置，且在設定或維護時可能需要網路連線。 雲端 AI 服務需要連線，並依據其資料處理條款向服務傳送資料。

告訴使用者何時需要下載模型，以及資料何時離開裝置。 在測試完完整的首次執行、更新和備用體驗之前，不要稱某功能為離線功能。

AI 工具可以幫助我建立或現代化 Windows 應用程式嗎？

是的。 AI 編碼代理能協助專案架構、解釋 API、遷移程式碼、產生測試並診斷建置問題。 使用 GitHub Copilot 的 AI 輔助 Windows 開發指引、WinUI 代理外掛、Microsoft Learn MCP Server、遷移工作流程及 AI 輔助測試。

像審查其他貢獻一樣檢視並測試產生的程式碼。 特別是，請驗證 API 名稱與版本、套件功能、安全敏感程式碼、無障礙性，以及任何 UWP 到 WinUI 3 的替換。

在推出 AI 輔助功能之前，我應該考慮什麼？

定義功能預期用途與限制，利用具代表性的數據評估品質與安全性，適當時揭露 AI 行為，保護使用者資料，並在模型或所需硬體無法取得時提供備用方案。 將秘密與特權服務憑證排除在用戶端應用程式之外，並要求使用者確認後才能做出後續或不可逆的行動。 請參閱 Windows 上的負責任生成式 AI 開發 和 Windows 開發的安全性與負責任 AI。

效能與最佳化

我該怎麼做才能讓我的Windows應用程式讓終端使用者感覺良好？

請參閱 Windows 應用程式開發 - 最佳實務 以及 Windows應用程式效能與基礎概述。

Compatibility

我的使用者是否需要更新 Windows 才能使用 WinUI 3 應用程式？

Windows 應用程式 SDK 的最低相容作業系統為 Windows 10，版本 1809，建構版 17763。 若要獲得 Microsoft 支援，必須使用受支援的 Windows 應用程式 SDK 發行版本及其最新維護更新，並搭配仍在支援中的 Windows 版本、發行版本及維護通道。 個別 API 可能需要更新的 Windows 版本或特定硬體。 請參閱 Windows 應用程式 SDK 支援與發佈頻道。

我可以用 WinUI 3 應用程式來鎖定 Arm64 嗎？

是的。 打造一個原生的 Arm64 應用程式，以獲得最佳效能與效率。 對於大型 C++ 程式碼庫且有 x64 相依， Arm64EC 允許你逐步遷移模組。 Windows 11 on Arm 也能透過 Prism 模擬執行許多現有的 x86 和 x64 應用程式，但你應該在代表性的 Arm 裝置上測試效能與相容性。

棄用和遷移

UWP / WinUI 用於 UWP 是否已經被棄用？

UWP 和 WinUI 2 並沒有正式被棄用。 Visual Studio 2026 支援 UWP，支援現代 .NET 與原生 AOT，而 WinUI 2.8 仍是 UWP 最新穩定的 WinUI 版本。 不過，Microsoft 建議 WinUI 3 和 Windows 應用程式 SDK 用於新的通用型 Windows 桌面應用程式。

現代 .NET 與原生 AOT 的 UWP 支援已普遍提供，且是 Visual Studio 2026 中預設的 C# UWP 專案類型。 將現有的 UWP 應用程式從 .NET Native 移植到現代 .NET，是與遷移 UI 到 WinUI 3 不同的現代化步驟。 請參考「用 .NET 和 Native AOT 現代化你的 UWP 應用程式」。

我應該什麼時候將 UWP / WinUI 的 UWP 應用程式遷移到 WinUI 3？

如果 UWP 開發者對 UWP 及其功能集感到滿意，就不必感到遷移壓力——對許多應用程式來說，正確的選擇可能是繼續使用 UWP。

想要利用最新 Windows 平台與 .NET 投資的應用程式，應考慮轉用 WinUI 3 與 Windows 應用程式 SDK。 請參見 從 UWP 遷移到 Windows 應用程式 SDK。

在什麼情況下，我不應該將使用 UWP 版 WinUI 的 UWP 應用程式遷移至 WinUI 3？

當您的目標裝置或應用程式模式需要時，例如Xbox應用程式、HoloLens 2D應用程式，或標準Surface Hub環境的應用程式，請繼續使用UWP。 Windows IoT Enterprise 支援桌面應用程式技術，包括 Windows 應用程式 SDK，因此物聯網目標本身並非使用 UWP 的理由。

WPF已棄用嗎？

否。 WPF 在新式 .NET 中受到支援，並持續獲得功能、效能、協助工具及 Fluent 風格方面的改進。 它仍然是現有 WPF 應用程式以及符合 WPF 需求的新應用程式的良好選擇。 對於新的通用 Windows 桌面應用程式，Microsoft 主要推薦使用 WinUI 3 搭配 Windows 應用程式 SDK。 請參閱GitHub上的WPF路線圖。

WinForms 已經棄用了嗎？

否。 WinForms 有支援並持續獲得功能更新。 請參閱GitHub上的Windows Forms路線圖。

Windows 執行階段（WinRT）是否已棄用？

否。 WinRT 是一種應用程式二進位介面（ABI），可實現跨多種語言的互通性。 WinRT 是 COM 的演進，而 Windows 應用程式 SDK 透過 WinRT API 提供大部分功能。

發布說明

我在哪裡可以找到Windows 應用程式 SDK的發行說明？

請參閱 Windows 應用程式 SDK 發布說明，了解穩定、預覽及實驗性版本。 「Windows 開發者新功能」頁面總結了最新的 Windows SDK、Windows 應用程式 SDK、WinUI 3、工具及平台更新。

相關內容

  • Last updated on