aplikacja dla systemu Windows programowanie — często zadawane pytania

Aby uzyskać świetny przegląd dzisiejszych opcji dla deweloperów Windows, obejrzyj najnowszy odcinek Windows Dev Chat, Wybór Twojej idealnej platformy deweloperskiej, gdzie omawiają WinUI, .NET MAUI, React Native, Blazor i Progressive Web Apps (PWA).

Możesz również zapoznać się z przegląd opcji tworzenia aplikacji dla deweloperów Windows.

W czasach usług w chmurze opracowywanie aplikacji klienckich pozostaje ważne w celu zapewnienia dynamicznych, znaczących interakcji na urządzeniach użytkowników.

Oto dlaczego aplikacje klienckie mają znaczenie:

• Dostęp do urządzenia: Aplikacje klienckie umożliwiają bezpośrednie przeniesienie aplikacji do użytkowników na ich urządzeniach.
• Gateway to Intelligent Services: Aplikacje klienckie często są pierwszym punktem interakcji użytkowników z Waszymi usługami. Oferują one bogaty, interaktywny interfejs, który umożliwia prezentowanie inteligentnych funkcji i odróżnienie produktu od innych.
• Skalowalność przy integracji z chmurą: Dobrze zintegrowana aplikacja kliencka może bezproblemowo synchronizować się z usługami chmurowymi zaplecza, umożliwiając dostęp do danych w czasie rzeczywistym i płynną skalowalność w miarę wzrostu bazy użytkowników.
• zwiększonej produktywności i lojalności użytkowników: Przemyślana aplikacja może zwiększyć produktywność i zapewnić użytkownikom zaangażowanie w produkt lub usługę w czasie.

Zestaw SDK do aplikacji systemu Windows udostępnia składniki serwisowane niezależnie dla klasycznych aplikacji systemu Windows, w tym WinUI, składniki cyklu życia aplikacji, obsługi okien, powiadomień, zasobów oraz interfejsy API obsługi tekstu. Obsługuje ona aplikacje uruchamiane w wersji Windows 10 w wersji 1809 lub nowszej, z zastrzeżeniem cyklu życia wsparcia wersji Windows i wersji Zestaw SDK do aplikacji systemu Windows.

Oba są zestawami SDK (software development kit), które umożliwiają tworzenie aplikacji Windows.

Zestaw SDK do aplikacji systemu Windows udostępnia składniki, które są dostarczane niezależnie od systemu Windows i działają we wszystkich obsługiwanych wersjach systemu Windows, począwszy od systemu Windows 10 w wersji 1809. Obejmuje interfejs WinUI oraz interfejsy API do obsługi cyklu życia aplikacji, okien, powiadomień, zasobów, tekstu i innych funkcji.

Windows SDK udostępnia nagłówki, biblioteki, metadane i narzędzia do interfejsów API systemu operacyjnego, takich jak Win32, WinRT, COM, DirectX, obsługa urządzeń i funkcje powłoki.

Zestaw SDK do aplikacji systemu Windows nie zastępuje zestawu WINDOWS SDK. Aplikacje, które przyjmują Zestaw SDK do aplikacji systemu Windows, mogą nadal korzystać z interfejsów API zestawu SDK Windows, a aplikacje WinUI często używają obu tych interfejsów.

Oto kilka powodów, dla których należy wybrać natywną strukturę Windows dla aplikacji tylko Windows:

• Performance: Natywne platformy Windows są zoptymalizowane pod kątem wykorzystania nowoczesnego sprzętu Windows, zapewniając szybkie i dynamiczne środowisko użytkownika.
• Integracja: Windows jest dostarczany z szeroką gamą interfejsów API, które umożliwiają tworzenie zaawansowanych środowisk, dostępnych tylko w Windows. Struktury natywne zapewniają głęboką integrację z tymi funkcjami i interfejsami API.
• Native user experience: Native frameworks zapewniają spójne środowisko na urządzeniach Windows, zapewniając, że aplikacja wygląda i działa świetnie wszędzie.
• Obsługa trybu offline: Natywne struktury obsługują scenariusze offline, umożliwiając aplikacjom działanie nawet bez łączności z Internetem.
• Obsługa i narzędzia: Microsoft obsługuje platformy natywne i udostępnia bieżące zestawy SDK, dokumentację, narzędzia debugowania i przykłady.

Jeśli tworzysz nową aplikację tylko Windows, zalecamy użycie interfejsu WinUI. WinUI to najnowsza natywna struktura interfejsu użytkownika służąca do tworzenia aplikacji Windows i zaprojektowana do pracy na wielu urządzeniach Windows. Zapewnia nowoczesną i elastyczną strukturę interfejsu użytkownika do tworzenia atrakcyjnych wizualnie i interaktywnych aplikacji Windows. WinUI jest częścią Zestaw SDK do aplikacji systemu Windows i działa najlepiej z najnowszymi wersjami Windows.

Należy pamiętać, że WinUI (struktura interfejsu użytkownika) jest częścią Zestaw SDK do aplikacji systemu Windows (platformy programistycznej Windows).

Interfejs użytkownika aplikacji można migrować do interfejsu użytkownika systemu WinUI lub użyć wysp XAML WinUI do hostowania kontrolek Zestaw SDK do aplikacji systemu Windows na obsługiwanym hoście pulpitu. Hosty XAML Islands w starszych systemach obsługują kontrolki UWP XAML i używają innych interfejsów API.

Elementy Zestaw SDK do aplikacji systemu Windows mogą być często używane w aplikacjach desktopowych, w zależności od sposobu tworzenia istniejącej aplikacji. Aplikacje platformy UWP nie są obsługiwane przez Zestaw SDK do aplikacji systemu Windows.

Oznacza to, że aplikacje WPF/MFC/WinForms mogą używać interfejsów API Zestaw SDK do aplikacji systemu Windows, które nie są powiązane z interfejsem WinUI. Przykłady obejmują cykl życia aplikacji, zarządzanie oknami oraz powiadomienia typu toast.

Aby uzyskać więcej informacji, zobacz Użyj Zestaw SDK do aplikacji systemu Windows w istniejącym projekcie.

Nie. Kompilacje XAML systemu WinUI używają programu MSBuild, ale można tworzyć za pomocą zestawu SDK .NET i bieżących szablonów WinUI z wiersza polecenia w innym edytorze. Zobacz ścieżkę .NET i wiersza polecenia.

Visual Studio 2026 zapewnia najbogatszą zintegrowaną edycję, debugowanie, profilowanie i środowisko Przeładowywanie na gorąco XAML. Użyj przepływu pracy, który odpowiada wymaganiom dotyczącym narzędzi.

Ten błąd występuje zwykle w scenariuszach aplikacji unpackaged, w których środowisko uruchomieniowe Zestaw SDK do aplikacji systemu Windows nie zostało zainstalowane na maszynie. Spróbuj wykonać następujące czynności:

• Jeśli używasz aplikacji packaged (zalecana wartość domyślna), upewnij się, że uruchamiasz ją za pośrednictwem Visual Studio, wybierając profil uruchamiania MsixPackage (a nie zwykły profil wykonywalny). Krok pakowania MSIX instaluje wymagane składniki środowiska uruchomieniowego.
• Jeśli używasz rozpakowanej aplikacji zależnej od platformy, zainstaluj pasujące środowisko uruchomieniowe Zestaw SDK do aplikacji systemu Windows. Wdrożenie autonomiczne zawiera własne zależności pakietu Zestaw SDK do aplikacji systemu Windows.
• Upewnij się, że projekt jest zgodny z modelem wdrażania. W przypadku normalnej .NET rozpakowanej aplikacji ustawienie <WindowsPackageType>None</WindowsPackageType> umożliwia automatyczne inicjowanie środowiska uruchomieniowego Zestaw SDK do aplikacji systemu Windows. Korzystaj bezpośrednio z interfejsu API programu rozruchowego tylko wtedy, gdy potrzebujesz jawnej kontroli nad inicjowaniem zależności dynamicznych.

Aby uzyskać więcej informacji na temat wymagań dotyczących wdrażania, zobacz Wdrażanie aplikacji korzystających z Zestaw SDK do aplikacji systemu Windows.

WinUI (wcześniej nazywany WinUI 3) to najnowsza natywna struktura interfejsu użytkownika na potrzeby tworzenia aplikacji Windows. Zapewnia nowoczesną i elastyczną strukturę interfejsu użytkownika do tworzenia atrakcyjnych wizualnie i interaktywnych aplikacji Windows. WinUI jest częścią Zestaw SDK do aplikacji systemu Windows i działa najlepiej z najnowszymi wersjami Windows.

WinUI dla platformy UWP (wcześniej określanej jako WinUI 2) to zestaw kontrolek interfejsu użytkownika i stylów opartych na platformie UWP. Zapewnia nowoczesny wygląd i działanie aplikacji Uniwersalnej platformy Windows (UWP) i jest zaprojektowane dla Windows 10.

Tak — "Aplikacja WinUI" jest zalecanym terminem. Aplikacje WinUI są nazywane "aplikacjami WinUI", ponieważ interfejs WinUI dla platformy UWP nie jest typem aplikacji, ale zestawem składników używanych w aplikacjach platformy UWP.

Nie. Zestaw SDK do aplikacji systemu Windows nie można używać w aplikacjach platformy UWP, a interfejs WinUI dla platformy UWP nie może być mieszany z interfejsem WinUI. Zobacz Przejdź z platformy UWP do Zestaw SDK do aplikacji systemu Windows.

Migrowanie składników interfejsu użytkownika jest ogólnie proste (w przypadku języka C# i C++/WinRT). W przeciwnym razie koszt migracji zależy przede wszystkim od:

1. Plik projektu i dostosowywanie MSBuild: Nakład pracy nad migracją różni się w zależności od zaawansowanego wykorzystania MSBuild.
2. Migracja interfejsu API platformy .NET: aplikacje UWP korzystające z .NET Native mogą przejść na obecnie obsługiwaną wersję platformy .NET z funkcją Native AOT. Ta modernizacja jest oddzielona od migracji interfejsu użytkownika do interfejsu użytkownika WinUI.
3. Biblioteki składników interfejsu użytkownika: Biblioteki muszą mieć wersje przeznaczone dla winUI.
4. Jeśli aplikacja platformy UWP została zapisana w zastąpionym języku C++/CX, wymagane jest przenoszenie kodu źródłowego. Zobacz Przejście z C++/CX na C++/WinRT.

Aby uzyskać więcej informacji, zobacz Migrate z platformy UWP do Zestaw SDK do aplikacji systemu Windows.

Tak, uaktualnione aplikacje można publikować bez aktualizowania tożsamości aplikacji. Użytkownicy starej wersji zostaną zaktualizowani do nowej wersji. Dotyczy to tylko aplikacji na komputery stacjonarne. aplikacje Xbox, HoloLens i Surface Hub nie mogą migrować do usługi WinUI.

Zobacz Omówienie wdrażania.

Zobacz Przejdź z platformy UWP do Zestaw SDK do aplikacji systemu Windows.

Nie. Kontrolki interfejsu użytkownika można tworzyć w kodzie. Jednak reprezentowanie interfejsu użytkownika w deklaratywnym zapisie XAML oferuje wiele korzyści, w tym ulepszone środowisko deweloperskie.

• Migracja z platformy UWP do winUI: wiele składników XAML i interfejsu użytkownika może być ponownie używanych, chociaż wymagane są pewne dostosowania składni.
• Migracja z WPF do winUI: wiele pojęć jest przenoszonych, ale zestaw kontrolek i interfejsy API różnią się.

Obecnie nie. Użyj Przeładowywanie na gorąco XAML, dynamicznego drzewa wizualnego, Eksploratora właściwości na żywo i powiązanych narzędzi środowiska uruchomieniowego, aby sprawdzić i zaktualizować kod XAML podczas działania aplikacji.

Pełny przewodnik po narzędziach projektowych środowiska uruchomieniowego dostępnych dla interfejsu WinUI 3 można znaleźć w temacie XAML runtime design tools for WinUI 3 (Narzędzia projektowania środowiska uruchomieniowego XAML dla interfejsu WinUI 3).

Tak. WinUI jest dostarczany jako część Zestaw SDK do aplikacji systemu Windows.

Nie. WinUI dla platformy UWP jest częścią platformy UWP.

Nie całkiem. Chociaż winUI pierwotnie rozpoczął się od bazy kodu WinUI dla platformy UWP, są to odrębne technologie. Oba są strukturami interfejsu użytkownika opartymi na języku XAML, które działają między .NET i C++, ale winUI dla platform UWP i WinUI nie są ze sobą zgodne.

Nie. WinUI jest dostarczany jako część Zestaw SDK do aplikacji systemu Windows.

Tak. WinUI i wiele interfejsów API zestawu Zestaw SDK do aplikacji systemu Windows działa w aplikacjach bez pakietu. Jednak niektóre funkcje systemu Windows wymagają identyfikatora pakietu, a niespakietowane aplikacje zależne od struktury muszą zainicjować środowisko uruchomieniowe Zestaw SDK do aplikacji systemu Windows. Porównaj opcje w temacie Omówienie tworzenia pakietów i Funkcje, które wymagają tożsamości pakietu.

WinUI to struktura interfejsu użytkownika zawarta w Zestaw SDK do aplikacji systemu Windows. Wyspy XAML to technika hostingu, która umożliwia istniejącej aplikacji klasycznej umieszczenie zawartości XAML wraz z interfejsem użytkownika z innej platformy.

Termin może odnosić się do starszych systemów wysp XAML hostujących kontrolki XAML platformy UWP lub wysp XAML WinUI hostujących kontrolki Zestaw SDK do aplikacji systemu Windows w obsługiwanych hostach pulpitu. Interfejsy API, przestrzenie nazw i wymagania dotyczące hosta różnią się.

Tak. Interfejs użytkownika Twojej aplikacji będzie przejmować (dziedziczyć) najnowsze zasady projektowania Fluent UI we wszystkich obsługiwanych wersjach systemu Windows 11 i Windows 10, aż do wersji 1809, zarówno w scenariuszach pakietowych, jak i niepakietowych.

Tak. Zobacz Stosowanie materiałów Mica lub Akrylowych w aplikacjach desktopowych dla Windows 11.

Zobacz Przykład i zasoby. Niektóre istotne repozytoria:

• WindowsAppSDK-Samples: Pokazuje, jak używać określonych zestawów interfejsów API Zestaw SDK do aplikacji systemu Windows.
• Przykłady tematów dla Windows: zawiera przykładowe notatki WinUI używane w samouczku 'Tworzenie aplikacji WinUI'.
• WinUI 3 Gallery: Prezentuje interfejs WinUI i Zestaw SDK do aplikacji systemu Windows. Dostępne również w Microsoft Store.

Jeśli zainwestowano już w WPF, możesz nadal korzystać z niej w przypadku istniejących aplikacji. WPF jest dojrzałą, stabilną strukturą powszechnie używaną do tworzenia aplikacji klasycznych Windows.

Użyj funkcji GitHub Copilot upgrade do oceny i uaktualnienia aplikacji WPF opartej na .NET Framework do nowoczesnej platformy .NET. Przejrzyj wygenerowany plan i zweryfikuj każdą zmianę w aplikacji.

Podczas tworzenia aplikacji WPF z .NET 9 lub nowszym możesz upewnić się, że aplikacja jest zgodna z eleganckim, nowoczesnym wyglądem Windows 11. Nowy motyw Fluent dla WPF wprowadza współczesną Windows 11 estetykę, ze zintegrowanym trybem jasnym/ciemnym i obsługą kolorów akcentów systemowych. To modernizuje wygląd aplikacji i zapewnia dopracowane, spójnie środowisko użytkownika.

Jeśli rozwiązanie WinForms spełnia Twoje potrzeby, a Twój zespół jest w nim wygodny, możesz nadal używać formularzy WinForms dla istniejących aplikacji. WinForms to dojrzała i stabilna struktura powszechnie używana do tworzenia aplikacji klasycznych Windows.

Zespół WinForms nadal inwestuje w platformę. Niektóre bieżące obszary inwestycji obejmują:

• Obsługa asynchronicznych kontrolek typowych
• Tryb ciemny
• Elastyczność układu
• Funkcje zabezpieczeń pulpitu, takie jak dostęp do schowka

Jeśli kierujesz użytkowników na wiele platform systemu operacyjnego, tworzenie aplikacji międzyplatformowych za pomocą .NET MAUI lub React Native może oferować kilka korzyści:

• Osiągnąć: Aplikacje międzyplatformowe docierają do większej grupy odbiorców na różnych urządzeniach i systemach operacyjnych.
• Ponowne użycie kodu: Ponowne tworzenie kodu na różnych platformach skraca czas programowania i koszty. Tworzenie oddzielnych aplikacji dla systemów Windows, Android, iOS i macOS może być zbyt kosztowne.
• Spójne środowisko użytkownika: Platformy międzyplatformowe pomagają zapewnić spójny wygląd i działanie na różnych platformach.
• Integracja: Aplikacje międzyplatformowe mogą nadal integrować się z usługami specyficznymi dla platformy, aby zapewnić kompleksowe środowisko.

Podczas budowania aplikacji .NET MAUI dla Windows, wynikiem jest aplikacja WinUI. Podczas programowania .NET MAUI oferuje jedno środowisko .NET na różnych platformach, ale generuje kod specyficzny dla platformy pod maską. Dzięki temu .NET MAUI aplikacje działają dobrze na każdej platformie i zapewniają natywne środowisko użytkownika.

.NET MAUI zapewnia ujednolicone środowisko .NET w systemach Windows, iOS, Android i macOS. Oferuje ona wieloplatformowe interfejsy API dla typowych możliwości, takich jak pamięć masowa, sieci i czujniki urządzenia. Możesz również wywoływać interfejsy API specyficzne dla platformy lub udostępniać wyspecjalizowane implementacje dla każdej platformy.

Nie w tej chwili. Mimo że .NET MAUI używa interfejsu WinUI podczas uruchamiania na Windows, zespoły planujące obsługę wielu platform powinny zacząć od platformy .NET MAUI lub React Native for Desktop.

Zespoły z silnym środowiskiem tworzenia aplikacji internetowych mogą chcieć rozważyć rozwiązanie React Native for Desktop. Obejmuje ona oprogramowanie React Native dla Windows i macOS. Dzięki podejściu "Dowiedz się raz, napisz w dowolnym miejscu", istniejące umiejętności javaScript, TypeScript i React mogą służyć do tworzenia natywnych aplikacji Windows i macOS.

Platforma React Native for Desktop renderuje interfejs użytkownika bezpośrednio z natywnymi elementami pierwotnymi, zapewniając natywną wydajność i możliwości platformy.

Zobacz dokumentację React Native for Desktop, aby rozpocząć.

Aplikacje react native można wdrażać na wszystkich urządzeniach obsługiwanych przez Windows 10 i nowsze, w tym komputery, tablety, 2-in-1, Xbox i urządzenia rzeczywistości mieszanej.

Jeśli aplikacja musi obsługiwać Xbox, HoloLens lub IoT, zaleca się platformę UWP. Zestaw SDK do aplikacji systemu Windows nie obsługuje tych platform. W przypadku tworzenia gier użyj Zestaw deweloperski firmy Microsoft do tworzenia gier.

Jeśli celujesz zarówno w Windows, jak i Surface Hub, zaleca się UWP.

Aplikacje hybrydowe łączą najlepsze rozwiązania dotyczące tworzenia aplikacji internetowych i natywnych. Ich podstawowe funkcje są tworzone przy użyciu technologii internetowych, takich jak HTML, CSS i JavaScript, i opakowane w natywny kontener, który zapewnia access do niektórych natywnych funkcji platformy i sprzętu. Można je również dystrybuować za pośrednictwem sklepów z aplikacjami.

Główną zaletą jest to, że aplikacje hybrydowe umożliwiają tworzenie pojedynczej aplikacji, która może działać na wielu platformach natywnych i w Internecie, skracając czas programowania i koszty. Przykłady platform programowania aplikacji hybrydowych obejmują:

• Electron dla aplikacji desktopowych
• Ionic dla aplikacji mobilnych
• .NET MAUI Blazor Hybrid dla aplikacji wieloplatformowych

Zobacz Tworzenie stron internetowych na Windows oraz Przegląd progresywnych aplikacji internetowych.

Dzięki .NET MAUI aplikacje Platformy Blazor mogą być uruchamiane natywnie w systemach Windows, iOS, Android i macOS. Umożliwia to tworzenie hybrydowych aplikacji klienckich łączących komponenty Blazor i .NET MAUI w jednej natywnej aplikacji klienckiej z pełnym dostępem do możliwości natywnej platformy.

Dowiedz się więcej na stronie ASP.NET Core Blazor Hybrid.

Nie. Począwszy od .NET 9, .NET MAUI zawiera kontrolkę HybridWebView, która umożliwia hostowanie innych interfejsów użytkownika opartych na języku JavaScript wewnątrz aplikacji natywnej.

Umożliwia to hostowanie aplikacji Angular, React, Vue lub innych aplikacji HTML/JavaScript w aplikacji .NET MAUI. Kontrolka hybrydowa zapewnia współdziałanie między językami C# i JavaScript, więc kod języka C# może wywoływać funkcje Języka JavaScript i na odwrót.

Tak. WPF i aplikacje WinForms mogą również hostować składniki hybrydowe platformy Blazor, co umożliwia dodanie nowoczesnego internetowego interfejsu użytkownika do istniejących aplikacji. Nie jest to obsługiwane w przypadku aplikacji WPF ani WinForms opartych na platformie .NET Framework.

Składniki natywne i hybrydowe można mieszać w aplikacji. Na przykład rdzeń aplikacji może zostać skompilowany przy użyciu .NET MAUI składników, podczas gdy składniki hybrydowe zapewniają dodatkowe funkcje. Umożliwia to połączenie wydajności i możliwości składników natywnych z elastycznością i wydajnością kosztów składników hybrydowych.

Web apps oferują najszerszy zasięg dowolnej platformy aplikacji klienckiej. Opcje tworzenia pięknych .NET aplikacji internetowych obejmują:

• ASP.NET Core aplikacje z Razor Pages
• ASP.NET Core aplikacje MVC
• ASP.NET Core aplikacje Blazor z opcjami modelu hostingu:
  • Blazor WebAssembly
  • Blazor Server

Modele hostingu platformy Blazor można teraz skonfigurować na poziomie składnika, umożliwiając scenariusze takie jak hostowanie składnika Zestawu WebAssembly platformy Blazor w aplikacji blazor Server.

Aby uzyskać więcej informacji, zobacz dokumentację ASP.NET Core.

Windows to otwarta platforma, która obsługuje wiele technologii. Poniżej przedstawiono kilka kryteriów, które mogą pomóc w wyborze platformy:

• Czy tworzysz najpierw Windows czy międzyplatformowo?
• Jakie języki lub umiejętności już masz — .NET, JavaScript, coś innego?
• Czy potrzebujesz dostępu do interfejsów API specyficznych dla Windows?
• Które możliwości platformy najlepiej odpowiadają wymaganiom aplikacji?
• Zobacz tę tabelę , aby uzyskać dodatkowe czynniki porównania.

W przypadku wielu aplikacji biznesowych zespoły często wybierają na podstawie istniejących umiejętności i tego, z czego najlepiej korzysta zespół.

Podczas wybierania podejścia programistycznego dla aplikacji internetowej należy wziąć pod uwagę następujące kwestie:

• Platforma Blazor jest zalecana do tworzenia aplikacji webowych front-endu przy użyciu .NET. Umożliwia ona tworzenie zarówno frontonu, jak i zaplecza przy użyciu .NET, oszczędzania czasu i kosztów oraz jest szczególnie dobre w przypadku aplikacji dla przedsiębiorstw.
• Aplikacje internetowe w JavaScript nadal mają sens, jeśli chcesz wykorzystać istniejące umiejętności JavaScript lub potrzebujesz zintegrować się z ustalonymi bibliotekami JS lub frameworkami.
• Istniejące aplikacje korzystające ze starszych struktur, takich jak Web Forms, MVC lub Razor Pages, pozostają obsługiwane i mogą być nadal opracowywane i obsługiwane.

Wielu klientów korzysta z WinUI, w tym Adobe i Apple.

• Adobe Fresco, bezpłatna aplikacja do rysowania i malowania.
• Apple Music, Apple TV i Apple Devices zostały skompilowane za pomocą interfejsu WinUI i Zestaw SDK do aplikacji systemu Windows.

Microsoft utworzył również wiele aplikacji WinUI, takich jak Eksplorator plików Windows 11 i aplikacja Zdjęcia.

Wielu klientów, w tym Microsoft, tworzy międzyplatformowe aplikacje z .NET MAUI. Na przykład aplikacja mobilna Microsoft Azure jest tworzona przy użyciu .NET MAUI.

Zobacz więcej na pokazie klientów .NET.

Większość interfejsu użytkownika Microsoft Visual Studio jest kompilowana przy użyciu WPF. Sam Visual Studio IDE jest głównym przykładem złożonej, wysokowydajnej aplikacji WPF.

GE Digitalowy system FlightPulse dla linii lotniczych używa platformy Blazor do konfiguracji zaplecza technicznego wszelkich interfejsów pilotów, dostarczając dane z czujników i analizy bezpośrednio do pilotów w celu poprawy bezpieczeństwa i wydajności.

Zobacz więcej historii klientów Blazor w witrynie .NET.

W większości przypadków użyj języka C# (.NET). Język C# oferuje szybsze programowanie, bezpieczeństwo pamięci, bogate biblioteki i doskonałe narzędzia. Większość aplikacji Windows — w tym WinUI 3, WPF, WinForms i .NET MAUI — najlepiej kompiluje się za pomocą języka C#.

Użyj języka C++ , jeśli potrzebujesz bezpośredniego dostępu sprzętowego, minimalnego nakładu pracy środowiska uruchomieniowego lub współdziałania z istniejącymi bazami kodu C++. Typowe zastosowania C++ obejmują silniki gier (DirectX), sterowniki, narzędzia systemowe oraz komponenty krytyczne pod względem wydajności.

Czynnik	C# (.NET)	C++
Szybkość programowania	✅ Szybsze — pamięć zarządzana, bogaty ekosystem	⚠✔ Wolniejsze — ręczne zarządzanie zasobami
Wydajność środowiska uruchomieniowego	✅Świetnie współpracuje z nowoczesnym środowiskiem .NET (AOT, Span<T>)	✅ Najlepsze możliwe — brak wstrzymywania GC
Bezpieczeństwo pamięci	✅ Z automatycznym odśmiecaniem pamięci	⚠✔ Ręczne — ryzyko wycieków i luk w zabezpieczeniach
dostęp do interfejsu API Windows	✅ Za pośrednictwem projekcji C#/WinRT	✅ Projekcja C++/WinRT
Obsługa interfejsu WinUI 3	✅ Pełna obsługa	✅ Pełna obsługa za pośrednictwem języka C++/WinRT
Wieloplatformowy	✅.NET działa w systemach Windows, Linux, macOS	✅ Z kodem specyficznym dla platformy
Najlepsze dla	Aplikacje biznesowe, CRUD, usługi, aplikacje z dużymi interfejsami użytkownika	Gry, sterowniki, narzędzia systemowe, małe opóźnienia

Możesz również mieszać obie te elementy: kompilować aplikację w języku C# i wywoływać kod natywny o krytycznym znaczeniu dla wydajności za pośrednictwem P /Invoke (CsWin32) lub składnika C++/WinRT.

Użyj csWin32, generatora źródłowego, który tworzy bezpieczne dla typu podpisy P/Invoke w czasie kompilacji. Dodajesz pakiet NuGet Microsoft.Windows.CsWin32, wymieniasz potrzebne interfejsy API w pliku NativeMethods.txt i wywołujesz je za pomocą wygenerowanej klasy PInvoke.

CsWin32 zastępuje ręcznie napisane [DllImport] deklaracje i działa w dowolnym projekcie języka C# — WinUI, WPF, WinForms lub konsoli. Zobacz Wywoływanie interfejsów API Win32 z aplikacji Windows języka C# (CsWin32), aby zapoznać się z przewodnikiem krok po kroku.

C++/WinRT to standardowa projekcja języka C++17 dla interfejsów API środowisko wykonawcze systemu Windows. Użyj go podczas tworzenia aplikacji systemu Windows w języku C++, które korzystają z interfejsów API WinRT lub je tworzą. Zastępuje język C++/CX i bibliotekę szablonów języka C++ środowisko wykonawcze systemu Windows (WRL).

Wybierz pozycję C++/WinRT, gdy:

• Tworzysz aplikację WinUI 3 języka C++
• Musisz utworzyć składniki środowisko wykonawcze systemu Windows używane przez inne języki
• Migrowanie z C++/CX

Język C#/WinRT zapewnia obsługę projekcji WinRT dla języka C#. W większości przypadków nie wchodzisz z nim w bezpośrednią interakcję — aplikacje .NET kierowane na system Windows automatycznie uzyskują dostęp do interfejsów API systemu WinRT za pośrednictwem monikerów platform docelowych (TFM). Podczas tworzenia składników środowisko wykonawcze systemu Windows w języku C# lub generowania zestawów międzyoperacyjnych dla składników WinRT innych firm należy jawnie potrzebować języka C#/WinRT.

Spakowana aplikacja zawiera jej pliki, tożsamość i informacje o wdrożeniu w pakiecie, takim jak MSIX. Rozpakowana aplikacja używa instalatora lub procesu wdrażania poza systemem pakietów Windows i domyślnie nie ma tożsamości pakietu. Aplikacja spakowana z użyciem lokalizacji zewnętrznej używa małego pakietu identyfikacyjnego, przy zachowaniu plików binarnych znajdujących się w lokalizacji zewnętrznej oraz istniejącego instalatora i procesu aktualizacji.

Zobacz Omówienie pakowania, aby uzyskać informacje na temat wymagań i kompromisów.

Zależy to od Windows funkcji używanych przez aplikację. Niektóre operacje wykonywane w tle, powiadomienia push, rozszerzenia powłoki, skojarzenia plików i scenariusze SI w systemie Windows wymagają tożsamości pakietu. Inne możliwości pakietu Zestaw SDK do aplikacji systemu Windows, w tym WinUI i lokalne powiadomienia aplikacji, mogą działać bez niego.

Zobacz funkcje , które wymagają tożsamości pakietu. Jeśli potrzebujesz tożsamości, ale musisz zachować istniejącego instalatora, rozważ opakowanie z lokalizacją zewnętrzną.

Aplikacja zależna od platformy używa pakietów środowiska uruchomieniowego Zestaw SDK do aplikacji systemu Windows zainstalowanych oddzielnie na urządzeniu. Zmniejsza to rozmiar wdrożenia aplikacji. Autonomiczna aplikacja zawiera zawartość pakietu Zestaw SDK do aplikacji systemu Windows Framework wraz z aplikacją, co zwiększa rozmiar wdrożenia, ale umożliwia aplikacji obsługiwanie tych składników struktury.

Interfejsy API, które zależą od dodatkowych pakietów MSIX, takich jak pakiet Singleton, mogą wymagać oddzielnego wdrożenia lub sprawdzenia obsługi w środowisku uruchomieniowym nawet w samodzielnej aplikacji. Wdrażanie pakietów i środowiska uruchomieniowego są oddzielnymi decyzjami. Zobacz Omówienie wdrażania zestawu Zestaw SDK do aplikacji systemu Windows.

Aplikację WinUI można dostarczyć za pośrednictwem Sklepu, pliku .appinstaller lub za pomocą istniejącego pakietu MSI albo setup.exe. Aplikacja Store i AppInstaller obsługują automatyczne aktualizacje dla użytkowników końcowych, którzy mają włączone aktualizacje automatyczne, ale aplikacje MSI/setup.exe muszą zapewnić własny mechanizm aktualizacji.

Projekty XAML winUI wymagają programu MSBuild, ale Visual Studio nie jest wymagane. Możesz użyć .NET sdk i szablonów WinUI, aby uruchomić program MSBuild za pomocą dotnet build wiersza polecenia. Składniki zestawu Zestaw SDK do aplikacji systemu Windows, które nie korzystają z WinUI, można również zintegrować z obsługiwanymi projektami klasycznymi opartymi na technologii MSBuild.

Użyj interfejsów API AI systemu Windows, aby korzystać z gotowych do użycia funkcji sztucznej inteligencji zarządzanych przez system Windows. Użyj narzędzia Foundry Local , aby lokalnie odnajdywać, pobierać i uruchamiać obsługiwane modele języka i mowy. Użyj Windows ML, aby uruchamiać niestandardowe modele ONNX za pomocą providerów wykonawczych dla dostępnego sprzętu CPU, GPU i NPU.

Wymagania dotyczące sprzętu, Windows wersji, tożsamości pakietu, modelu i dystrybucji różnią się. Sprawdź bieżące wymagania dotyczące wybranego interfejsu API lub środowiska uruchomieniowego zamiast zakładać, że każda funkcja sztucznej inteligencji Windows jest dostępna na każdym komputerze.

Zdefiniuj zamierzone użycie i ograniczenia funkcji, oceń jakość i bezpieczeństwo za pomocą reprezentatywnych danych, ujawnij zachowanie sztucznej inteligencji, jeśli jest to odpowiednie, chroń dane użytkownika i zapewnij rezerwę, gdy model lub wymagany sprzęt nie jest dostępny. Zobacz Odpowiedzialne opracowywanie sztucznej inteligencji w Windows.

Zobacz Windows tworzenie aplikacji — najlepsze praktyki i Windows przegląd wydajności i podstaw aplikacji.

Aplikacje Zestaw SDK do aplikacji systemu Windows mogą działać w obsługiwanych edycjach systemu Windows 10 w wersji 1809 i nowszych, ale poszczególne interfejsy API i funkcje aplikacji mogą wymagać nowszych wersji systemu Windows lub odpowiedniego sprzętu. Aby zapewnić obsługę produkcyjną, na urządzeniu musi być uruchomiona wersja Windows i wersja, która jest nadal obsługiwana, a aplikacja powinna używać obsługiwanej wersji Zestaw SDK do aplikacji systemu Windows z bieżącymi aktualizacjami obsługi. Zobacz obsługa Zestaw SDK do aplikacji systemu Windows i Kanały wydań.

Tak. Zbuduj natywną aplikację Arm64, aby uzyskać najlepszą wydajność i efektywność. W przypadku dużej bazy kodu C++ z zależnościami x64 usługa Arm64EC umożliwia przyrostowe migrowanie modułów. Windows 11 na Arm może także uruchamiać wiele istniejących aplikacji x86 i x64 za pośrednictwem emulacji Prism, ale należy przetestować wydajność i zgodność na reprezentatywnych urządzeniach z procesorami Arm.

Nie. Platforma UWP i winUI dla platformy UWP pozostają obsługiwane i otrzymują poprawki błędów, niezawodności i zabezpieczeń. Jednak WinUI i Zestaw SDK do aplikacji systemu Windows są zalecanym rozwiązaniem dla nowych uniwersalnych aplikacji klasycznych dla systemu Windows i to na nie kierowana jest większość nowych inwestycji w platformę.

Obsługa UWP dla nowoczesnego środowiska .NET z technologią Native AOT jest już ogólnie dostępna i stanowi domyślny typ projektu C# dla UWP w programie Visual Studio 2026. Przeniesienie istniejącej aplikacji platformy UWP z .NET Native na nowoczesne .NET to oddzielny krok modernizacji od migrowania interfejsu użytkownika do interfejsu użytkownika WinUI. Zobacz Modernizuj aplikację platformy UWP przy użyciu .NET i natywnej usługi AOT.

Deweloperzy platformy UWP nie powinni czuć nacisku na migrację, jeśli są zadowoleni z platformy UWP i jej zestawu funkcji — w przypadku wielu aplikacji właściwym wyborem może być pozostanie na platformie UWP.

Aplikacje, które chcą korzystać z najnowszej platformy Windows i .NET inwestycji, powinny rozważyć przejście na Zestaw SDK do aplikacji systemu Windows. Zobacz Przejdź z platformy UWP do Zestaw SDK do aplikacji systemu Windows.

Kontynuuj korzystanie z platformy UWP, jeśli tworzysz aplikację Xbox, Surface Hub lub HoloLens.

Nie. WPF jest obsługiwana, zalecana i nadal otrzymuje aktualizacje funkcji. Zobacz mapę drogową WPF na GitHubie.

Nie. Formularze WinForms są obsługiwane i nadal otrzymują aktualizacje funkcji. Zobacz mapę drogową Windows Forms na GitHubie.

Nie. WinRT to interfejs binarny aplikacji (ABI), który umożliwia współdziałanie w wielu językach. WinRT to ewolucja modelu COM, a Zestaw SDK do aplikacji systemu Windows zapewnia większość funkcji za pośrednictwem interfejsów API WinRT.

Najnowsze informacje o najnowszej wersji można znaleźć na stronie Co nowego.