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 開發者聊天室,標題為選擇你的理想開發平台,在這集裡他們討論了 WinUI、.NET MAUI、React Native、Blazor 以及 漸進式網頁應用程式 (PWAs)。

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

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

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

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

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

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

是什麼 Windows 應用程式 SDK?

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

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

兩者都是軟體開發套件(SDK),讓你能建立 Windows 應用程式。

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

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

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

我正在組建一支新團隊,開發一款僅限Windows的應用程式。為什麼我要選擇用原生Windows框架來開發,比如 WinUI、WPF 或 WinForms?

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

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

如果你正在開發一個全新的 Windows 專用應用程式,我們建議使用 WinUI。 WinUI 是最新的原生 Windows 應用程式開發框架,設計用於多種 Windows 裝置。 它提供了一個現代且靈活的 UI 架構,用以打造視覺吸引且互動的 Windows 應用程式。 WinUI 是 Windows 應用程式 SDK 的一部分,且在最新版本的 Windows 上運作最佳。

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

請注意,WinUI(一個 UI 框架)隨 Windows 應用程式 SDK(一個Windows平台開發框架)一起出廠。

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

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

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

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

我需要用Visual Studio來建立 WinUI 應用程式嗎?

否。 WinUI XAML 建置是使用 MSBuild,但你也可以用 .NET SDK 和現有的 WinUI 範本,從其他編輯器的指令列建立。 請參考 .NET 和命令列路徑

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(前稱 WinUI 3)是最新的原生 UI 框架,用於Windows應用程式開發。 它提供了一個現代且靈活的 UI 架構,用以打造視覺吸引且互動的 Windows 應用程式。 WinUI 是 Windows 應用程式 SDK 的一部分,且在最新版本的 Windows 上運作最佳。

UWP 的 WinUI (前稱 WinUI 2)是一套建立在 UWP 之上的 UI 控制項與樣式。 它為 UWP 應用程式提供現代化的外觀與使用感,並專為 Windows 10 設計。

當我用 Windows 應用程式 SDK 和 WinUI 建置應用程式時,我是在建一個「WinUI 應用程式」嗎?

是的——「WinUI 應用程式」是推薦的術語。 WinUI 應用程式被稱為「WinUI 應用程式」,因為 WinUI for UWP 不是一種應用程式,而是一組用於 UWP 應用程式的元件。

我可以逐步將 UWP 應用程式中的「WinUI 用於 UWP 控制項」替換成 WinUI 組件,以便更新我的 UWP 應用程式嗎?

否。 Windows 應用程式 SDK 不能用在 UWP 應用程式中,而 UWP 的 WinUI 也不能和 WinUI 混用。 請參見 從 UWP 遷移到 Windows 應用程式 SDK

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

移轉 UI 元件通常很簡單 (適用於 C# 和 C++/WinRT)。 否則,遷移成本主要取決於:

  1. Project 檔案與 MSBuild 自訂:遷移工作量會依進階 MSBuild 使用情況而異。
  2. .NET API 遷移:使用 .NET Native 的 UWP 應用程式可遷移至目前支援的 .NET 版本,並搭配 Native AOT。 這種現代化與將 UI 遷移到 WinUI 是分開的。
  3. UI 元件函式庫: 函式庫必須有針對 WinUI 的版本。
  4. 若 UWP 應用程式是以現已取代的 C++/CX 撰寫,則需要進行部分原始碼移植。 請參閱從 C++/CX 移到 C++/WinRT

更多資訊請參見 從 UWP 遷移到 Windows 應用程式 SDK

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

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

我該如何打包或發佈 WinUI 應用程式?

請參閱部署概觀

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

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

如果我想使用 WinUI,是否需要使用 XAML 標記?

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

  • 從 UWP 遷移到 WinUI:許多 XAML 與 UI 元件可重複使用,但需部分語法調整。
  • 從 WPF 遷移到 WinUI:許多概念可以延續,但控制項集和 API 有所不同。
Visual Studio 有 WinUI 的設計表面/UI 設計器嗎?

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

欲完整了解 WinUI 3 執行時設計工具,請參見 XAML 執行時設計工具(適用於 WinUI 3)。

Windows 應用程式 SDK 包含 WinUI嗎?

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

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

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

WinUI for UWP 和 WinUI 是否是基於相同技術打造的?

不完全正確。 雖然 WinUI 最初是從 UWP 的 WinUI 程式碼庫開始,但它們是不同的技術。 兩者都是基於 XAML 的 UI 框架,都可以在 .NET 和 C++ 中使用,但用於 UWP 的 WinUI 和一般的 WinUI 並不相容。

我可以用 WinUI 而不使用 Windows 應用程式 SDK?

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

我可以在未封裝的應用程式中使用 WinUI(WinUI)嗎?

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

XAML Islands 和 WinUI 有什麼不同?

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

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

如果我建立一個 WinUI 應用程式,它在 Windows 11 和 Windows 10 上看起來都會現代嗎?

是的。 您的應用程式介面將在所有支援的 Windows 11 和 Windows 10 版本(可至 1809 版本)上繼承最新的 Fluent UI 設計原則,無論是打包或非打包的情境。

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

是的。 請參考在 Windows 11 桌面應用程式中應用雲母或壓克力材料。

我在哪裡可以找到 WinUI 範例?

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

如果我已經在WPF上投入了大量資源,應該繼續用WPF還是考慮遷移到 WinUI?

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

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

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

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

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

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

WinForms 團隊持續投資於該平台。 一些目前的投資領域包括:

  • 對常用控制項的非同步支援
  • 深色模式
  • 版面配置彈性
  • 桌面安全功能如剪貼板存取(clipboard access)

跨平臺原生開發

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

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

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

當你為 Windows 建立一個 .NET MAUI 應用程式時,輸出是一個 WinUI 應用程式。 在開發過程中,.NET MAUI 提供跨平台的單一 .NET 體驗,但在底層卻產生平台專屬的程式碼。 這確保 .NET MAUI 應用程式在各平台都能良好表現,並提供原生使用者體驗。

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

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

我可以先從 WinUI 開始,之後如果想針對跨平台情境整合.NET MAUI嗎?

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

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

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

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

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

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

React Native 應用程式可部署至所有支援 Windows 10 及更新版本的裝置,包括 PC、平板、2 合 1 裝置、Xbox 及混合實境裝置。

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

如果你的應用程式需要支援 Xbox、HoloLens 或 IoT,建議使用 UWP。 Windows 應用程式 SDK 不支援這些平台。 遊戲開發時,使用 Microsoft 遊戲開發套件

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

如果你同時針對 Windows 和 Surface Hub,建議使用 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 開發應用程式?

許多客戶目前都使用 WinUI 建置,包括 Adobe 和 Apple:

Microsoft 也開發了許多 WinUI 應用程式,例如 Windows 11 檔案總管和照片應用程式。

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

包括 Microsoft 在內的許多客戶,正在使用 .NET MAUI 建構跨平台應用程式。 例如,Microsoft Azure 行動應用程式 就是使用 .NET MAUI 建置。

更多內容請見 .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、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 功能。 部分背景執行、推送通知、shell 擴充、關聯及 Windows AI 情境都需要套件身份。 其他 Windows 應用程式 SDK 功能,包括 WinUI 和本地應用程式通知,也能在沒有 Windows App 的情況下運作。

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

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

依賴框架的應用程式會使用分別安裝在裝置上的 Windows 應用程式 SDK 執行時套件。 這會減少應用程式的部署規模。 自包含的應用程式會隨應用程式攜帶 Windows 應用程式 SDK Framework 套件內容,這增加了部署規模,但讓應用程式能服務這些框架元件。

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

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

WinUI 應用程式可以透過商店、.appinstaller 檔案,或現有的 MSI 或 setup.exe 套件提供。 商店和 AppInstaller 支援啟用自動更新的終端用戶自動更新,但 MSI/setup.exe 應用程式必須提供自己的更新機制。

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

WinUI XAML 專案需要 MSBuild,但 Visual Studio 並非必需。 你可以使用 .NET SDK 和 WinUI 範本,透過 dotnet build 從命令列執行 MSBuild。 不使用 WinUI 的 Windows 應用程式 SDK 元件也能整合到支援的 MSBuild 桌面專案中。

Windows 人工智慧

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

使用 Windows AI API 以獲得現成且由 Windows 管理的 AI 功能。 使用 Foundry Local 來發現、下載並執行支援的語言與語音模型。 使用 Windows ML 執行自訂 ONNX 模型,並搭配可用的 CPU、GPU 與 NPU 硬體執行提供者。

硬體、Windows 版本、套件識別碼、型號及發行版本需求各異。 請檢查你選擇的 API 或執行環境目前的需求,而不是假設每台 PC 都有所有 Windows AI 功能。

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

定義功能預期用途與限制,利用具代表性的數據評估品質與安全性,適當時揭露 AI 行為,保護使用者資料,並在模型或所需硬體無法取得時提供備用方案。 請參見 Windows 上的負責任生成式 AI 開發

效能與最佳化

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

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

Compatibility

我的使用者會需要更新Windows才能使用我的 WinUI 應用程式嗎?

Windows 應用程式 SDK 應用程式可在支援的 Windows 10、1809 及更新版本上執行,但個別 API 與應用程式功能可能需要更新的 Windows 版本或硬體。 若要支援生產環境,裝置必須執行仍在支援的 Windows 版本,且應用程式應使用支援的 Windows 應用程式 SDK 版本及最新的服務更新。 請參閱 Windows 應用程式 SDK 支援發佈頻道

我可以用我的 WinUI 應用程式來鎖定 Arm64 嗎?

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

棄用和遷移

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

否。 UWP 與 WinUI 仍持續支援,並獲得錯誤、可靠性及安全修正。 然而,WinUI 與 Windows 應用程式 SDK 是新通用 Windows 桌面應用程式的推薦路徑,並獲得大多數新平台投資。

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

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

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

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

我什麼時候不應該把 UWP + WinUI 的 UWP 應用程式遷移到 WinUI?

如果你是為 Xbox、Surface Hub 或 HoloLens 製作,請繼續使用 UWP。

WPF已棄用嗎?

否。 WPF 受到支援、推薦,並持續獲得功能更新。 請參閱GitHub上的WPF路線圖。

WinForms 已經棄用了嗎?

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

Windows 執行階段(WinRT)是否已棄用?

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

發布說明

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

最新發行說明可在 「What's new」 頁面找到。