aplikacja dla systemu Windows programowanie — często zadawane pytania

Te często zadawane pytania zawierają odpowiedzi na często zadawane pytania dotyczące tworzenia aplikacji Windows, w tym wskazówki dotyczące wybierania odpowiedniej platformy dla projektów. Omawiane tematy to m.in.:

  • Wprowadzenie i środowisko tworzenia aplikacji Windows.
  • Tworzenie wyłącznie natywnych aplikacji Windows z użyciem WinUI 3, Windows Presentation Foundation (WPF) i Windows Forms (WinForms).
  • Windows Software Development Kit (SDK) i Zestaw SDK do aplikacji systemu Windows.
  • Określanie celu Windows w ramach strategii tworzenia aplikacji dla wielu platform.
  • Tworzenie aplikacji hybrydowych i internetowych za pomocą .NET MAUI, platformy Blazor i ASP.NET Core.
  • Jak wybrać podejście podczas zrozumienia inwestycji Microsoft.

Windows krajobraz tworzenia aplikacji

Gdzie mogę znaleźć proste omówienie technologii tworzenia aplikacji dla Windows?

Aby uzyskać omówienie dzisiejszych opcji dla deweloperów Windows, obejrzyj odcinek Windows Dev Chat Wybieranie idealnej platformy deweloperskiej, w którym omówiono platformę WinUI 3, .NET MAUI, React Native, Blazor i Progressive Web Apps (PWA). Inne odcinki można znaleźć na liście odtwarzania Windows Dev Chat.

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

Dlaczego tworzenie aplikacji klienckich nadal jest kluczowe dla nowoczesnej transformacji cyfrowej w czasach usług chmurowych?

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.

Tworzenie aplikacji natywnych tylko na Windows

Jak jest Zestaw SDK do aplikacji systemu Windows?

Zestaw SDK do aplikacji systemu Windows udostępnia niezależnie serwisowane składniki dla aplikacji klasycznych systemu Windows, w tym WinUI 3, obsługę cyklu życia aplikacji, obsługę okien, powiadomienia, zasoby i interfejsy API 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.

Jak różnica między Zestaw SDK do aplikacji systemu Windows a zestawem SDK 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. Zawiera WinUI 3 oraz interfejsy API dla cyklu życia aplikacji, obsługi okien, powiadomień, zasobów, obsługi 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 korzystające z pakietu Zestaw SDK do aplikacji systemu Windows mogą nadal używać interfejsów API pakietu Windows SDK, a aplikacje WinUI 3 często korzystają z obu tych rozwiązań.

Tworzysz nowy zespół do tworzenia aplikacji tylko do Windows. Dlaczego należy wybrać programowanie za pomocą natywnej platformy Windows, takiej jak WinUI 3, WPF lub WinForms?

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.
Który framework powinienem użyć, aby wykorzystać najnowsze inwestycje Microsoftu do tworzenia aplikacji Windows?

Jeśli tworzysz nową aplikację klasyczną ogólnego przeznaczenia Windows, zalecamy użycie interfejsu WinUI 3. WinUI 3 to natywna struktura interfejsu użytkownika dostarczana z Zestaw SDK do aplikacji systemu Windows. Obsługuje klasyczne aplikacje systemu Windows i zapewnia dostęp do aktualnych kontrolek Fluent oraz funkcji platformy Windows.

Czy mogę użyć Zestaw SDK do aplikacji systemu Windows/WinUI 3 w istniejącej aplikacji Windows?

Należy pamiętać, że platforma WinUI 3 (struktura interfejsu użytkownika) jest dostarczana z platformą Zestaw SDK do aplikacji systemu Windows (platformą deweloperów platformy Windows).

Interfejs użytkownika aplikacji można zmigrować do WinUI 3 lub użyć WinUI XAML Islands do osadzania kontrolek Zestaw SDK do aplikacji systemu Windows w obsługiwanym istniejącym hoście aplikacji klasycznej. 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 3. Przykłady obejmują cykl życia aplikacji, okna i powiadomienia aplikacji.

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

Czy muszę używać Visual Studio do tworzenia aplikacji WinUI 3?

Nie. Kompilacje XAML winUI 3 używają programu MSBuild, ale można tworzyć przy użyciu zestawu SDK .NET i bieżących szablonów WinUI 3 z wiersza polecenia w innym edytorze. Zobacz przewodnik Szybki start 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.

Otrzymuję błąd "Nie można załadować biblioteki DLL 'Microsoft.ui.xaml.dll'" podczas uruchamiania aplikacji. Jak mogę to naprawić?

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.

Jaka jest różnica między systemami WinUI 3 i WinUI 2 dla platformy UWP?

WinUI 3 to bieżąca natywna struktura interfejsu użytkownika Microsoft dla aplikacji klasycznych Windows i jest dostarczana w ramach Zestaw SDK do aplikacji systemu Windows.

WinUI 2, nazywany również WinUI dla platformy UWP, to biblioteka kontrolek i stylów dla aplikacji platformy UWP. Interfejsy WinUI 2 i WinUI 3 używają różnych przestrzeni nazw XAML i nie są zgodne z danymi binarnymi.

Czy podczas kompilowania aplikacji przy użyciu Zestaw SDK do aplikacji systemu Windows i winUI 3 kompiluję aplikację "WinUI"?

Tak. Aplikacja WinUI 3 to najtrafniejsze określenie aplikacji, której interfejs użytkownika jest oparty na WinUI 3 i zestawie Zestaw SDK do aplikacji systemu Windows. Aplikacja WinUI jest również często używana, gdy kontekst jest jasny.

Czy mogę przyrostowo zaktualizować moją aplikację UWP korzystającą z kontrolek WinUI dla UWP do WinUI 3, stopniowo zastępując te kontrolki?

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 3. Zobacz Przejdź z platformy UWP do Zestaw SDK do aplikacji systemu Windows.

Jak trudno jest migrować aplikację platformy UWP do systemu WinUI 3?

Platforma UWP i winUI 3 współdzielą wiele pojęć dotyczących języka XAML, ale migracja nie jest bezpośrednią zmianą przestrzeni nazw. Koszt 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 migrowania interfejsu użytkownika do interfejsu użytkownika WinUI 3.
  3. Biblioteki składników interfejsu użytkownika: Biblioteki muszą mieć wersje przeznaczone dla winUI 3.
  4. Interfejsy API obsługi okien i modelu aplikacji: Interfejsy API UWP powiązane z pojęciami, takimi jak CoreWindow, ApplicationView lub GetForCurrentView, wymagają odpowiedników w zestawie Zestaw SDK do aplikacji systemu Windows lub innego podejścia dla aplikacji klasycznych.
  5. Projekcja języka C++: Jeśli aplikacja platformy UWP używa zastąpionej projekcji C++/CX, przeportuj ten kod do języka C++/WinRT.

Aby uzyskać więcej informacji, zobacz artykuły Migrowanie z platformy UWP do zestawu Zestaw SDK do aplikacji systemu Windows i Mapowanie interfejsu API z UWP na Zestaw SDK do aplikacji systemu Windows.

Jeśli mam istniejącą aplikację platformy UWP w Sklepie, czy mogę opublikować nową spakowana aplikację WinUI 3 przy użyciu tych samych identyfikatorów?

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. Xbox, HoloLens i standardowe aplikacje usługi Surface Hub nie mogą migrować do usługi WinUI 3.

Jak mogę spakować lub dystrybuować moją aplikację WinUI 3?

Zobacz Omówienie wdrażania.

Gdzie mogę znaleźć wskazówki dotyczące migracji Zestaw SDK do aplikacji systemu Windows?

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

Czy muszę używać znaczników XAML, jeśli chcę użyć interfejsu WinUI 3?

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.

  • Migrowanie z platformy UWP do interfejsu WinUI 3: wiele pojęć dotyczących języka XAML i interfejsu użytkownika jest przenoszonych, ale przestrzenie nazw, model projektu i niektóre interfejsy API różnią się.
  • Migracja z WPF do interfejsu WinUI 3: wiele pojęć jest przenoszonych, ale zestaw kontrolek i interfejsy API różnią się.
Czy program Visual Studio ma powierzchnię projektową lub projektant interfejsu użytkownika dla WinUI 3?

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).

Czy Zestaw SDK do aplikacji systemu Windows zawiera winUI 3?

Tak. Pakiet WinUI 3 jest dostarczany jako część zestawu SDK aplikacji systemu Windows.

Czy Zestaw SDK do aplikacji systemu Windows zawiera WinUI dla UWP?

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

Czy platforma WinUI dla platform UWP i WinUI 3 jest oparta na tej samej technologii?

Nie całkiem. Mimo że platforma WinUI 3 została uruchomiona z 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ą w .NET i C++, ale winUI dla platform UWP i WinUI 3 nie są ze sobą zgodne.

Czy można używać interfejsu WinUI 3 bez używania Zestaw SDK do aplikacji systemu Windows?

Nie. Pakiet WinUI 3 jest dostarczany jako część zestawu SDK aplikacji systemu Windows.

Czy mogę używać interfejsu WinUI 3 w niezapakowanej aplikacji?

Tak. WinUI 3 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.

Jaka jest różnica między wyspami XAML i WinUI 3?

WinUI 3 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ę.

Czy jeśli utworzym aplikację WinUI 3, będzie ona wyglądać nowoczesne zarówno na Windows 11, jak i Windows 10?

Kontrolki WinUI 3 używają stylu Fluent w obsługiwanych wersjach Windows 10 i Windows 11 zarówno w aplikacjach spakowanych, jak i rozpakowanych. Niektóre efekty i zachowania systemu operacyjnego różnią się w zależności od wersji systemu Windows. Na przykład funkcja Mica jest dostępna w systemie Windows 11, a w systemie Windows 10 jest zastępowana jednolitym kolorem.

Czy mogę używać tła miki lub akrylu w aplikacjach zbudowanych przy użyciu Zestaw SDK do aplikacji systemu Windows?

Tak. Desktop Acrylic jest obsługiwany w Windows 10 w wersji 1809 lub nowszej. Mica wymaga systemu Windows 11 i w systemie Windows 10 przechodzi na jednolity kolor motywu. Wywołaj MicaController.IsSupported lub DesktopAcrylicController.IsSupported w czasie działania przed zastosowaniem warstwy tła. Zobacz Stosowanie materiałów Mica lub Akrylowych w aplikacjach desktopowych dla Windows 11.

Gdzie można znaleźć przykłady winUI 3?

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

Jeśli zainwestowałem już mocno w WPF, czy nadal używać WPF lub rozważyć migrację do winUI 3?

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.

Jeśli skompiluję nową aplikację WPF, czy będzie wyglądać przestarzale w porównaniu z innymi nowymi aplikacjami Windows?

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.

Mój zespół jest wygodny w tworzeniu aplikacji WinForms i odpowiada naszym potrzebom. Czy powinniśmy rozważyć migrację do systemu WinUI 3 lub innej platformy?

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ę. Najnowsze i bieżące prace obejmują:

  • Asynchroniczne interfejsy API formularzy i okien dialogowych
  • Obsługa trybu ciemnego i stylu wizualnego
  • Ulepszenia dotyczące ułatwień dostępu, wysokiego DPI, układu i projektanta interfejsu
  • Schowek i DataObject modernizacja

Programowanie natywne dla wielu platform

Jak są pewne przyczyny tworzenia międzyplatformowych aplikacji natywnych przeznaczonych dla Windows?

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.
Czy mogę być pewien, że aplikacje .NET MAUI będą działać dobrze na Windows?

Podczas tworzenia aplikacji .NET MAUI dla systemu Windows wynikowa aplikacja używa WinUI 3. Podczas programowania .NET MAUI oferuje jedno środowisko .NET na różnych platformach, ale generuje kod specyficzny dla platformy pod maską.

Jak .NET MAUI może dostarczać natywne interfejsy API urządzeń na każdej platformie?

.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.

Czy mogę zacząć od WinUI 3, a później zintegrować platformę .NET MAUI, jeśli docelowo chcę tworzyć rozwiązania wieloplatformowe?

Nie w tej chwili. Chociaż .NET MAUI korzysta z WinUI 3 podczas działania w systemie Windows, zespoły planujące tworzyć aplikacje na wiele platform powinny zacząć od .NET MAUI lub React Native for Desktop.

Nasz zespół ma silne umiejętności programistyczne frontonu internetowego. Czy powinniśmy rozważyć użycie oprogramowania React Native dla programu 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ąć.

Czy jakieś inne urządzenia z systemem Windows są obsługiwane przez React Native for Desktop?

Platforma React Native dla Windows obsługuje wersje Windows wymienione w dokumentacji zgodności. Sprawdź, czy dana rodzina urządzeń jest obsługiwana przez docelową wersję React Native for Windows, zamiast zakładać, że każde urządzenie z systemem Windows jest obsługiwane.

Co należy użyć, jeśli chcę tworzyć aplikacje działające na Windows i Xbox?

W przypadku aplikacji Xbox użyj platformy UWP i uwzględnij ograniczenia UWP specyficzne dla konsoli Xbox. W przypadku tworzenia gier użyj Zestaw deweloperski firmy Microsoft do tworzenia gier.

Co należy użyć, jeśli chcę tworzyć aplikacje działające na Windows i Surface Hub?

W przypadku urządzenia Surface Hub działającego w standardowym środowisku Teams Rooms lub Surface Hub należy użyć aplikacji UWP spełniającej wymagania aplikacji dla urządzenia Surface Hub. Surface Hub 3 skonfigurowany z systemem Windows 11 Pro lub Enterprise może uruchamiać obsługiwane technologie aplikacji komputerowych, więc platforma UWP nie jest jedyną opcją w tej konfiguracji.

Programowanie hybrydowe i internetowe

Co to są aplikacje hybrydowe i dlaczego należy rozważyć utworzenie aplikacji?

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
Jak zbudować progresywne aplikacje internetowe (PWA) dające wrażenie natywności w systemie Windows?

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

Co to jest aplikacja hybrydowa .NET MAUI Blazor?

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.

Czy komponenty webowe aplikacji hybrydowej .NET MAUI muszą być utworzone za pomocą platformy Blazor?

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.

Czy inne typy aplikacji natywnych mogą hostować składniki hybrydowe platformy Blazor?

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.

Czy cała moja aplikacja musi być aplikacją hybrydową lub czy mogę mieszać i dopasowywać składniki natywne i hybrydowe?

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.

Jakie są moje opcje tworzenia aplikacji internetowych opartych na .NET, które wyglądają świetnie w nowoczesnych przeglądarkach w Windows?

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.

Wybieranie podejścia i zrozumienie inwestycji Microsoft

Tak wiele opcji struktury do tworzenia aplikacji docelowych Windows! Jak mogę zdecydować?

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ół.

Jak wybrać najlepsze podejście programistyczne dla mojej aplikacji internetowej?

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.
Kto obecnie tworzy aplikacje za pomocą interfejsu WinUI 3?

Microsoft Photos jest jednym z udokumentowanych przykładów. Aplikacja została zmigrowana z platformy UWP do Zestaw SDK do aplikacji systemu Windows i nadal używa platformy WinUI 3. Aby uzyskać szczegółowe informacje na temat architektury i migracji, zobacz Microsoft Zdjęcia: migrowanie z platformy UWP do Zestaw SDK do aplikacji systemu Windows.

Who tworzy obecnie aplikacje .NET MAUI?

Organizacje używają .NET MAUI do tworzenia międzyplatformowych aplikacji dla systemów Android, iOS, macOS i Windows. Zobacz przykłady w prezentacji klientów platformy .NET.

Who tworzy obecnie aplikacje WPF?

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.

Kto obecnie tworzy aplikacje blazor?

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.

Wybór języka (.NET vs C++)

Czy należy używać języka C# lub C++ dla mojej aplikacji Windows?

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.

Jak wywołać interfejsy API Win32 z poziomu języka C#?

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#, w tym WinUI 3, WPF, WinForms i aplikacjach konsoli. Zobacz Wywoływanie interfejsów API Win32 z aplikacji Windows języka C# (CsWin32), aby zapoznać się z przewodnikiem krok po kroku.

Co to jest C++/WinRT i kiedy należy go używać?

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
Co to jest C#/WinRT i kiedy go potrzebuję?

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.

Pakowanie, wdrażanie i aktualizacje

Jaka jest różnica między aplikacjami w formie pakietu, niepakowanymi oraz pakietami zewnętrznymi?

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.

Czy potrzebuję identyfikatora pakietu?

Zależy to od Windows funkcji używanych przez aplikację. Tożsamość pakietu jest wymagana w scenariuszach, takich jak spakowane zadania w tle, udostępnianie obiektów docelowych, zadania uruchamiania, niestandardowe rozszerzenia pakietów menu kontekstowego, skojarzenia plików i protokołów opartych na manifeście oraz wiele interfejsów API sztucznej inteligencji Windows. Zestaw SDK do aplikacji systemu Windows obsługuje powiadomienia push w ograniczonych scenariuszach działania na pierwszym planie bez tożsamości, ale dostarczanie w tle i aktywacja COM wymagają tożsamości. WinUI 3 i lokalne powiadomienia aplikacji mogą działać bez tożsamości pakietu.

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ą.

Jaka jest różnica między wdrożeniem zależnym od struktury i samodzielnym?

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 i umożliwia zainstalowanej strukturze otrzymywanie aktualizacji obsługi. Samodzielna aplikacja niesie ze sobą Zestaw SDK do aplikacji systemu Windows zależności, co zwiększa rozmiar wdrożenia i sprawia, że wydawca aplikacji jest odpowiedzialny za dystrybucję aktualizacji obsługi Zestaw SDK do aplikacji systemu Windows przy użyciu nowych wersji aplikacji.

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.

Czy moja aplikacja WinUI 3 zostanie automatycznie zaktualizowana dla użytkowników końcowych?

Aplikację WinUI 3 można udostępniać za pośrednictwem Microsoft Store, jako plik .appinstaller albo pakiet MSI lub program instalacyjny. Pakiety sklepów można aktualizować za pomocą obsługi Microsoft Store, z zastrzeżeniem ustawień sklepu i organizacji. Wdrożenie .appinstaller obsługuje automatyczne aktualizacje tylko wtedy, gdy jego UpdateSettings konfiguruje sprawdzanie podczas uruchamiania lub w tle. Wdrożenia MSI i instalatorów muszą zapewniać własny mechanizm aktualizacji lub integrować się z nim.

Czy mogę używać Zestaw SDK do aplikacji systemu Windows bez używania MSBuild?

Tak, w niektórych scenariuszach. Projekty XAML winUI 3 wymagają obecnie programu MSBuild, chociaż Visual Studio nie jest wymagany i dotnet build może wywoływać program MSBuild z wiersza polecenia. Z interfejsów API pakietu Zestaw SDK do aplikacji systemu Windows innych niż XAML można korzystać w projektach C++ i CMake za pośrednictwem wersji zapoznawczej narzędzia wiersza polecenia aplikacja dla systemu Windows Development CLI albo ręcznie zintegrować środowisko uruchomieniowe.

Sztuczna inteligencja systemu Windows

Jak wybrać między interfejsami API sztucznej inteligencji Windows, lokalnymi rozwiązaniami Foundry i Windows ML?

Pierwsze trzy technologie są częścią Microsoft Foundry na Windows. Można je łączyć ze sobą i z modelami w chmurze w tej samej aplikacji:

  • Użyj interfejsów API AI systemu Windows, aby uzyskać gotowe do użycia funkcje, których modelami i akceleracją sprzętową zarządza system Windows.
  • Użyj narzędzia Foundry Local , aby lokalnie odnajdywać, pobierać i uruchamiać obsługiwane języki open source i modele mowy.
  • Użyj Windows ML, aby uruchamiać własne modele ONNX z dostawcami wykonania dla dostępnego sprzętu CPU, GPU i NPU.
  • Użyj platformy Microsoft Foundry, oddzielnej platformy AI w chmurze, gdy potrzebujesz modeli hostowanych w chmurze, wyszukiwania, scentralizowanych mechanizmów nadzoru lub funkcji, które nie są dostępne na urządzeniu docelowym.

Porównaj opcje w Wybierz rozwiązanie AI dla systemu Windows. Rozważ możliwości modelu, prywatność, łączność, opóźnienie, pokrycie sprzętu, rozmiar wdrożenia i koszt operacyjny.

Czy funkcje sztucznej inteligencji systemu Windows wymagają komputera Copilot+ PC?

Nie wszystkie z nich. Wiele interfejsów API sztucznej inteligencji systemu Windows wymaga komputera Copilot+ PC, ale niektóre interfejsy API obsługują również określone układy GPU lub procesory CPU. Foundry Local i Windows ML obsługują szerszy zakres konfiguracji sprzętowych, z zastrzeżeniem ich aktualnych wymagań dotyczących systemu operacyjnego, modelu, środowiska uruchomieniowego i dostawcy wykonania.

Sprawdź tabelę sprzętową interfejsu API sztucznej inteligencji Windows oraz wymagania dotyczące określonego interfejsu API lub modelu. Wykrywaj obsługę oraz gotowość modelu w czasie wykonywania i zapewniaj zastępcze rozwiązanie bez użycia SI, z użyciem modelu lokalnego lub chmury, gdy funkcja jest niedostępna.

Czy Windows funkcje sztucznej inteligencji mogą działać lokalnie i w trybie offline?

Tak. Interfejsy API AI systemu Windows, Foundry Local i Windows ML mogą uruchamiać inferencję na urządzeniu użytkownika, co może zmniejszyć opóźnienia i utrzymywać dane wejściowe lokalnie na urządzeniu. Niektóre modele lub dostawcy wykonania muszą najpierw zostać pobrane lub udostępnione i mogą wymagać połączenia z internetem podczas konfiguracji lub serwisowania. Usługi sztucznej inteligencji w chmurze wymagają łączności i wysyłają dane do usługi zgodnie z warunkami obsługi danych.

Poinformuj użytkowników, kiedy pobieranie modelu jest wymagane i kiedy dane opuszczają urządzenie. Nie opisuj funkcji jako działającej offline, dopóki nie przetestujesz w pełni jej pierwszego uruchomienia, aktualizacji i scenariusza awaryjnego.

Czy narzędzia sztucznej inteligencji mogą pomóc w tworzeniu lub modernizacji aplikacji Windows?

Tak. Agenci kodowania sztucznej inteligencji mogą pomóc w tworzeniu szkieletów projektów, wyjaśniać interfejsy API, migrować kod, generować testy i diagnozować problemy z kompilacją. Skorzystaj ze wskazówek dotyczących programowania wspomaganego przez sztuczną inteligencję Windows dla GitHub Copilot, wtyczki agenta WinUI, Microsoft Learn MCP Server, przepływów pracy migracji i testowania wspomaganego przez sztuczną inteligencję.

Przejrzyj i przetestuj wygenerowany kod, tak jak każdy inny wkład. W szczególności sprawdź nazwy i wersje interfejsów API, możliwości pakietów, kod wrażliwy z punktu widzenia zabezpieczeń, ułatwienia dostępu oraz wszelkie zastąpienia UWP przez WinUI 3.

Co należy wziąć pod uwagę przed wysyłką funkcji wspomaganej przez sztuczną inteligencję?

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. Przechowuj sekrety i uprzywilejowane poświadczenia usługi poza aplikacjami klienckimi oraz wymagaj potwierdzenia użytkownika przed wykonaniem działań o istotnych konsekwencjach lub nieodwracalnych. Zobacz Odpowiedzialne tworzenie generatywnej sztucznej inteligencji w systemie Windows i Zabezpieczenia i odpowiedzialna sztuczna inteligencja w programowaniu dla systemu Windows.

Wydajność i optymalizacja

W co mogę zrobić, aby moja aplikacja Windows czuła się świetnie dla użytkowników końcowych?

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

Compatibility

Czy moi użytkownicy będą musieli kiedykolwiek zaktualizować Windows, aby korzystać z mojej aplikacji WinUI 3?

Zestaw SDK do aplikacji systemu Windows jest minimalnie zgodny z systemem operacyjnym Windows 10 w wersji 1809, kompilacja 17763. Pomoc techniczna firmy Microsoft wymaga obsługiwanej wersji Zestaw SDK do aplikacji systemu Windows z najnowszą aktualizacją serwisową oraz edycji, wersji i kanału serwisowania systemu Windows, które są nadal obsługiwane. Poszczególne interfejsy API mogą wymagać nowszej Windows wersji lub określonego sprzętu. Zobacz obsługa Zestaw SDK do aplikacji systemu Windows i Kanały wydań.

Czy mogę kierować aplikację Arm64 do mojej aplikacji WinUI 3?

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.

Deprecacje i migracje

Czy UWP/WinUI dla UWP są przestarzałe?

Platformy UWP i WinUI 2 nie są formalnie przestarzałe. Visual Studio 2026 obsługuje platformę UWP z nowoczesnymi .NET i natywną funkcją AOT, a platforma WinUI 2.8 pozostaje najnowszą stabilną wersją WinUI dla platformy UWP. Jednak Microsoft zaleca korzystanie z WinUI 3 i zestawu Zestaw SDK do aplikacji systemu Windows w przypadku nowych aplikacji klasycznych ogólnego przeznaczenia dla systemu Windows.

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 migracji interfejsu użytkownika do winUI 3. Zobacz Modernizuj aplikację platformy UWP przy użyciu .NET i natywnej usługi AOT.

Kiedy należy przenieść aplikację UWP korzystającą z WinUI do WinUI 3?

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 platformę WinUI 3 i Zestaw SDK do aplikacji systemu Windows. Zobacz Przejdź z platformy UWP do Zestaw SDK do aplikacji systemu Windows.

Kiedy *nie* należy migrować aplikacji UWP + WinUI dla UWP do WinUI 3?

Kontynuuj korzystanie z platformy UWP, gdy urządzenie docelowe lub model aplikacji wymaga go, takich jak aplikacje Xbox, aplikacje HoloLens 2D lub aplikacje dla standardowego środowiska usługi Surface Hub. Windows IoT Enterprise obsługuje technologie aplikacji klasycznych, w tym Zestaw SDK do aplikacji systemu Windows, więc obiekt docelowy IoT nie jest samym powodem korzystania z platformy UWP.

Czy WPF jest wycofywane?

Nie. WPF jest wspierana i nadal zyskuje nowe funkcje oraz usprawnienia w zakresie wydajności, ułatwień dostępu i stylu Fluent w nowoczesnym środowisku .NET. Pozostaje dobrym wyborem dla istniejących aplikacji WPF oraz dla nowych aplikacji, których wymagania mieszczą się w możliwościach WPF. W przypadku nowych aplikacji klasycznych systemu Windows ogólnego zastosowania podstawowym zaleceniem Microsoftu jest WinUI 3 z zestawem Zestaw SDK do aplikacji systemu Windows. Zobacz mapę drogową WPF na GitHubie.

Czy WinForms są wycofane?

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

Czy środowisko wykonawcze systemu Windows (WinRT) jest przestarzały?

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.

Informacje o wydaniu

Gdzie mogę znaleźć uwagi do wydania dla Zestaw SDK do aplikacji systemu Windows?

Zapoznaj się z informacjami o wersji Zestaw SDK do aplikacji systemu Windows dotyczącymi wydań stabilnych, zapoznawczych i eksperymentalnych. Strona Co nowego dla deweloperów Windows zawiera podsumowanie najnowszych Windows SDK, Zestaw SDK do aplikacji systemu Windows, WinUI 3, narzędzi i aktualizacji platformy.

Treści powiązane

  • Last updated on