Häufig gestellte Fragen zur Entwicklung von Windows-Apps

Diese HÄUFIG gestellten Fragen enthalten Antworten auf häufig gestellte Fragen zur Windows Anwendungsentwicklung, einschließlich Anleitungen zur Auswahl des richtigen Frameworks für Ihre Projekte. Folgende Themen werden behandelt:

  • Erste Schritte und die Windows App-Entwicklungslandschaft.
  • Native Windows-only-App-Entwicklung mit WinUI 3, Windows Presentation Foundation (WPF) und Windows Forms (WinForms).
  • Windows Software Development Kit (SDK) und Windows App SDK.
  • Windows als Ziel Ihrer plattformübergreifenden Entwicklungsstrategie anvisieren.
  • Hybrid- und Web-App-Entwicklung mit .NET MAUI, Blazor und ASP.NET Core.
  • Wie man einen Ansatz auswählt, während man die Investitionen von Microsoft versteht.

Windows App-Entwicklungslandschaft

Wo finde ich eine einfache Übersicht über Windows Entwicklungstechnologien?

Eine Übersicht über die heutigen Optionen für Windows Entwickler finden Sie in der Windows Dev Chat-Episode "Auswählen Ihrer idealen Entwicklerplattform", die WinUI 3, .NET MAUI, React Native, Blazor und Progressive Web-Apps (PWAs) erläutert. Weitere Episoden finden Sie in der Windows Dev Chat-Wiedergabeliste.

Sie können auch auf die Overview der App-Entwicklungsoptionen für Windows Entwickler verweisen.

Warum ist die Entwicklung von Client-Apps noch entscheidend für die moderne digitale Transformation im Zeitalter von Cloud-Diensten?

Im Zeitalter der Clouddienste ist die Entwicklung von Client-Apps für die Bereitstellung reaktionsfähiger, aussagekräftiger Interaktionen auf Benutzergeräten wichtig.

Dies ist der Grund, warum Client-Apps wichtig sind:

  • Gerätereichweite: Mit Client-Apps können Sie Ihre Anwendung direkt an Benutzer auf ihren Geräten ihrer Wahl übertragen.
  • Gateway zu intelligenten Diensten: Client-Apps sind häufig der erste Berührungspunkt für Benutzer Ihrer Dienste. Sie bieten eine reichhaltige, interaktive Oberfläche, mit der Sie intelligente Features präsentieren und Ihr Produkt von anderen unterscheiden können.
  • Scalability with Cloud Integration: Eine gut integrierte Client-App kann mühelos mit Back-End-cloud services synchronisiert werden, wodurch Echtzeitdaten access und nahtlose Skalierbarkeit ermöglicht werden, während Ihre Benutzerbasis wächst.
  • verbesserte Produktivität und Benutzerbindung: Eine durchdachte App kann die Produktivität steigern und die Benutzer im Laufe der Zeit mit Ihrem Produkt oder Service beschäftigen.

Native Windows-App-Entwicklung nur für Windows

Was ist das Windows App SDK?

Die Windows App SDK stellt unabhängig gewartete Komponenten für Windows Desktop-Apps bereit, einschließlich WinUI 3, App-Lebenszyklus, Fenstern, Benachrichtigungen, Ressourcen und Text-APIs. Es unterstützt Apps, die auf Windows 10, Version 1809 und höher ausgeführt werden, vorbehaltlich des Supportlebenszyklus der Windows Release und Windows App SDK Version.

Was ist der Unterschied zwischen dem Windows App SDK und dem Windows SDK?

Beides sind Software Development Kits (SDKs), mit denen Sie Windows Apps erstellen können.

Die Windows App SDK stellt Komponenten bereit, die unabhängig von Windows ausgeliefert werden und über unterstützte Windows Versionen bis Windows 10 Version 1809 hinweg funktionieren. Sie enthält WinUI 3 und APIs für den App-Lebenszyklus, Fensterung, Benachrichtigungen, Ressourcen, Text und andere Funktionen.

Das Windows SDK stellt Header, Bibliotheken, Metadaten und Tools für Betriebssystem-APIs wie Win32, WinRT, COM, DirectX, Geräte und Shell-Funktionen bereit.

Das Windows App SDK ersetzt nicht das Windows SDK. Apps, die das Windows App SDK einsetzen, können weiterhin Windows SDK-APIs verwenden, und WinUI 3-Apps nutzen in der Regel beides.

Ich baue ein neues Team, um eine nur Windows-App zu entwickeln. Warum sollte ich mich für die Entwicklung mit einem systemeigenen Windows Framework wie WinUI 3, WPF oder WinForms entscheiden?

Hier sind einige Gründe für die Auswahl eines nativen Windows-Frameworks für Ihre ausschließlich Windows-App:

  • Performance: Native Windows Frameworks sind optimiert, um moderne Windows Hardware zu nutzen und schnelle und reaktionsfähige Benutzeroberflächen bereitzustellen.
  • Integration: Windows enthält eine Vielzahl von APIs, die anspruchsvolle Funktionen ermöglichen, die nur auf Windows verfügbar sind. Systemeigene Frameworks bieten eine umfassende Integration mit diesen Features und APIs.
  • Native Benutzeroberfläche: Native Frameworks bieten eine konsistente Benutzererfahrung auf Windows Geräten, um sicherzustellen, dass Ihre App überall gut aussieht und funktioniert.
  • Offlineunterstützung: Native Frameworks unterstützen Offlineszenarien, sodass Apps auch ohne Internetverbindung funktionieren können.
  • Unterstützung und Tools: Microsoft verwaltet die nativen Frameworks und stellt aktuelle SDKs, Dokumentationen, Debuggingtools und Beispiele bereit.
Which-Framework sollte ich verwenden, um die neuesten Investitionen Microsoft in Windows App-Entwicklung zu nutzen?

Wenn Sie eine neue allgemeine Windows Desktop-App erstellen, empfehlen wir die Verwendung von WinUI 3. WinUI 3 ist das systemeigene UI-Framework, das mit dem Windows App SDK bereitgestellt wird. Sie unterstützt Windows Desktop-Apps und bietet Zugriff auf aktuelle Fluent-Steuerelemente und Windows Plattformfunktionen.

Kann ich Windows App SDK / WinUI 3 in meiner vorhandenen Windows-App verwenden?

Beachten Sie, dass WinUI 3 (ein UI-Framework) mit dem Windows App SDK (einem Windows Plattformentwicklungsframework) ausgeliefert wird.

Sie können die Benutzeroberfläche einer App zu WinUI 3 migrieren oder WinUI-XAML-Inseln verwenden, um Windows App SDK Steuerelemente in einem unterstützten vorhandenen Desktophost zu hosten. Ältere System-XAML-Inseln hosten UWP-XAML-Steuerelemente und verwenden unterschiedliche APIs.

Elemente der Windows App SDK können häufig in Desktop-Apps verwendet werden, je nachdem, wie die vorhandene App erstellt wurde. UWP-Apps werden von Windows App SDK nicht unterstützt.

Dies bedeutet, dass WPF/MFC/WinForms-Apps Windows App SDK APIs verwenden können, die nicht mit WinUI 3 verbunden sind. Beispiele hierfür sind App-Lebenszyklus, Fenster und App-Benachrichtigungen.

Weitere Informationen finden Sie unter Use the Windows App SDK in an existing project.

Muss ich Visual Studio zum Erstellen von WinUI 3-Apps verwenden?

Nein. WinUI 3 XAML-Builds verwenden MSBuild, aber Sie können mit den .NET SDK- und aktuellen WinUI 3-Vorlagen über die Befehlszeile in einem anderen Editor erstellen. Sehen Sie sich die Schnellstartanleitung an.

Visual Studio 2026 bietet die besten integrierten Bearbeitungs-, Debugging-, Profilerstellungs- und XAML-Hot Reload-Funktionen. Verwenden Sie den Workflow, der Ihren Toolanforderungen entspricht.

Ich erhalte beim Ausführen meiner App einen Fehler 'DLL 'Microsoft.ui.xaml.dll' konnte nicht geladen werden'. Wie kann ich das beheben?

Dieser Fehler tritt in der Regel in unpackaged App-Szenarien auf, in denen die Windows App SDK Laufzeit nicht auf dem Computer installiert wurde. Probieren Sie Folgendes aus:

  • Wenn Sie eine packaged-App ausführen (die empfohlene Standardeinstellung), stellen Sie sicher, dass Sie über Visual Studio mit dem MsixPackage Startprofil (nicht mit dem einfachen ausführbaren Profil) starten. Der MSIX-Paketschritt installiert die erforderlichen Laufzeitkomponenten.
  • Wenn Sie eine frameworkabhängige entpackte App ausführen, installieren Sie die entsprechende Windows App SDK Laufzeit. Eine eigenständige Bereitstellung umfasst die Windows App SDK-Abhängigkeiten.
  • Vergewissern Sie sich, dass Ihr Projekt ihrem Bereitstellungsmodell entspricht. Bei einer normalen, nicht paketierten .NET-App wird durch das Festlegen von <WindowsPackageType>None</WindowsPackageType> die automatische Initialisierung der Windows App SDK-Runtime aktiviert. Verwenden Sie die Bootstrapper-API nur dann direkt, wenn Sie explizite Kontrolle über die dynamische Abhängigkeitsinitialisierung benötigen.

Weitere Informationen zu bereitstellungsanforderungen finden Sie unter Deploy apps that use the Windows App SDK.

Was ist der Unterschied zwischen WinUI 3 und WinUI 2 für UWP?

WinUI 3 ist das aktuelle systemeigene Benutzeroberflächenframework für Windows Desktop-Apps Microsoft und wird als Teil der Windows App SDK bereitgestellt.

WinUI 2, auch winUI für UWP genannt, ist eine Steuerelement- und Formatierungsbibliothek für UWP-Apps. WinUI 2 und WinUI 3 verwenden unterschiedliche XAML-Namespaces und sind nicht binärkompatibel.

Beim Erstellen einer App mit Windows App SDK und WinUI 3 erstellen ich eine "WinUI-App"?

Ja. WinUI 3-App ist der klarste Begriff für eine App, deren UI WinUI 3 und die Windows App SDK verwendet. WinUI-App wird auch häufig verwendet, wenn der Kontext eindeutig ist.

Kann ich meine UWP-App mit WinUI für UWP-Steuerelemente schrittweise auf WinUI 3 aktualisieren, indem ich die Steuerelemente schrittweise ersetzt?

Nein. Windows App SDK können in UWP-Apps nicht verwendet werden, und WinUI für UWP kann nicht mit WinUI 3 gemischt werden. Siehe Migrate von UWP zum Windows App SDK.

Wie schwierig ist es, eine UWP-App zu WinUI 3 zu migrieren?

UWP und WinUI 3 teilen viele XAML-Konzepte, die Migration ist jedoch keine direkte Namespaceänderung. Die Kosten hängen in erster Linie von:

  1. Projektdatei und MSBuild-Anpassung: Der Migrationsaufwand variiert abhängig von der fortgeschrittenen MSBuild-Nutzung.
  2. .NET API-Migration: UWP-Apps mit .NET Native können zu einer derzeit unterstützten .NET-Version mit Native AOT wechseln. Diese Modernisierung unterscheidet sich von der Migration der Benutzeroberfläche zu WinUI 3.
  3. Benutzeroberflächenkomponentenbibliotheken: Bibliotheken müssen Versionen für WinUI 3 haben.
  4. Fenster- und Anwendungsmodell-APIs: UWP-APIs, die an Konzepte wie CoreWindow, ApplicationView oder GetForCurrentView gebunden sind, erfordern Ersatzlösungen mit dem Windows App SDK oder einen anderen Desktopansatz.
  5. C++-Sprachprojektion: Wenn die UWP-App die abgelöste C++/CX-Projektion verwendet, portieren Sie diesen Code zu C++/WinRT.

Weitere Informationen finden Sie unter Migrieren von UWP zu Windows App SDK und der UWP zu Windows App SDK API-Zuordnung.

Wenn ich eine vorhandene UWP-App im Store habe, kann ich eine neue verpackte WinUI 3-App mit denselben Bezeichnern veröffentlichen?

Ja, aktualisierte Apps können veröffentlicht werden, ohne die Anwendungsidentität zu aktualisieren. Benutzer der alten Version werden auf die neue Version aktualisiert. Dies gilt nur für Desktop-Apps. Xbox, HoloLens und Standard-Surface Hub-Apps können nicht zu WinUI 3 migriert werden.

Wie kann ich meine WinUI 3-App packen oder verteilen?

Siehe Übersicht über die Bereitstellung.

Wo finde ich Windows App SDK Migrationsleitfaden?

Siehe Migrate von UWP zum Windows App SDK.

Muss ich XAML-Markup verwenden, wenn ich WinUI 3 verwenden möchte?

Nein. UI-Steuerelemente können im Code erstellt werden. Die Darstellung der Benutzeroberfläche im deklarativen XAML-Markup bietet jedoch viele Vorteile, einschließlich einer verbesserten Entwicklerumgebung.

  • Migration von UWP zu WinUI 3: Viele XAML- und UI-Konzepte werden übernommen, aber die Namespaces, das Projektmodell und einige APIs unterscheiden sich.
  • Migration von WPF zu WinUI 3: Viele Konzepte werden übernommen, die Steuerungssätze und APIs unterscheiden sich jedoch.
Verfügt Visual Studio über eine Entwurfsoberfläche oder einen UI-Designer für WinUI 3?

Derzeit nicht. Verwenden Sie XAML-Hot Reload, Live Visual Tree, Live Property Explorer und zugehörige Laufzeittools, um XAML zu prüfen und zu aktualisieren, während die App ausgeführt wird.

Eine vollständige exemplarische Vorgehensweise der für WinUI 3 verfügbaren Laufzeitdesigntools finden Sie unter XAML-Laufzeitdesigntools für WinUI 3.

Enthält Windows App SDK WinUI 3?

Ja. WinUI 3 ist im Lieferumfang des Windows App SDK enthalten.

Does Windows App SDK WinUI für UWP einschließen?

Nein. WinUI für UWP ist Teil der UWP-Plattform.

Basiert WinUI für UWP und WinUI 3 auf derselben Technologie?

Das trifft nicht vollständig zu. Obwohl WinUI 3 von der WinUI für UWP-Codebasis gestartet wurde, sind sie unterschiedliche Technologien. Beide sind XAML-basierte UI-Frameworks, die über .NET und C++ hinweg funktionieren, aber WinUI für UWP und WinUI 3 sind nicht miteinander kompatibel.

Kann ich WinUI 3 verwenden, ohne Windows App SDK zu verwenden?

Nein. WinUI 3 ist im Lieferumfang des Windows App SDK enthalten.

Kann ich WinUI 3 in einer entpackten App verwenden?

Ja. WinUI 3 und viele Windows App SDK APIs funktionieren in entpackten Apps. Einige Windows Funktionen erfordern jedoch Paketidentität, und frameworkabhängige entpackte Apps müssen die Windows App SDK Laufzeit initialisieren. Vergleichen Sie die Optionen in " Paketübersicht " und "Features", die eine Paketidentität erfordern.

Was ist der Unterschied zwischen XAML-Inseln und WinUI 3?

WinUI 3 ist das ui-Framework, das im Windows App SDK enthalten ist. XAML-Inseln sind eine Hostingtechnik, mit der eine vorhandene Desktop-App XAML-Inhalte zusammen mit der Benutzeroberfläche aus einem anderen Framework platzieren kann.

Der Begriff kann auf ältere System-XAML-Inseln verweisen, die UWP-XAML-Steuerelemente hosten, oder winUI-XAML-Inseln, die Windows App SDK Steuerelemente auf unterstützten Desktophosts hosten. Die APIs, Namespaces und Hostanforderungen unterscheiden sich.

Wenn ich eine WinUI 3-App erstelle, sieht sie sowohl für Windows 11 als auch für Windows 10 modern aus?

WinUI 3-Steuerelemente verwenden unter unterstützten Versionen von Windows 10 und Windows 11 in paketierten und nicht paketierten Apps das Fluent-Design. Einige Betriebssystemeffekte und -verhalten unterscheiden sich je nach Windows Version. Beispielsweise ist Mica auf Windows 11 verfügbar und fällt auf eine Volltonfarbe auf Windows 10 zurück.

Kann ich Mica- oder Acrylhintergründe in Apps verwenden, die mit Windows App SDK?

Ja. Desktop-Acryl wird auf Windows 10, Version 1809 und höher, unterstützt. Mica erfordert Windows 11 und fällt auf eine vollfarbige Designfarbe auf Windows 10 zurück. Rufen Sie MicaController.IsSupported oder DesktopAcrylicController.IsSupported zur Laufzeit auf, bevor Sie einen Hintergrund anwenden. Weitere Informationen finden Sie unter Anwenden von Mica oder Acrylmaterialien in Desktop-Apps für Windows 11.

Wo finde ich WinUI 3-Beispiele?

Siehe Muster und Ressourcen. Einige wichtige Repositorys:

Wenn ich bereits stark in WPF investiert habe, sollte ich weiterhin WPF verwenden oder die Migration zu WinUI 3 in Betracht ziehen?

Wenn Sie bereits stark in WPF investiert haben, können Sie sie weiterhin für vorhandene Apps verwenden. WPF ist ein ausgereiftes, stabiles Framework, das häufig verwendet wird, um Windows Desktop-Apps zu erstellen.

Verwenden Sie GitHub Copilot Upgrade, um eine .NET Framework-WPF-App auf moderne .NET zu bewerten und zu aktualisieren. Überprüfen Sie den generierten Plan, und überprüfen Sie jede Änderung in Ihrer App.

Wenn ich eine neue WPF-App erstelle, wird sie im Vergleich zu anderen neuen Windows-Apps veraltet aussehen?

Wenn Sie eine WPF Anwendung mit .NET 9 oder höher entwickeln, können Sie sicherstellen, dass Ihre App dem schlanken, modernen Look von Windows 11 entspricht. Das neue Fluent Design für WPF führt eine zeitgenössische Windows-11-Ästhetik mit integriertem Hell-/Dunkelmodus und Unterstützung für Systemakzentfarben ein. Dadurch wird das Erscheinungsbild Ihrer App modernisiert und eine ansprechende, einheitliche Benutzererfahrung gewährleistet.

Mein Team ist mit dem Erstellen von WinForms-Apps vertraut und passt zu unseren Anforderungen. Sollten wir die Migration zu WinUI 3 oder ein anderes Framework in Betracht ziehen?

Wenn WinForms Ihren Anforderungen entspricht und Ihr Team damit vertraut ist, können Sie WinForms weiterhin für vorhandene Apps verwenden. WinForms ist ein ausgereiftes und stabiles Framework, das häufig für Windows Desktopentwicklung verwendet wird.

Das WinForms-Team investiert weiterhin in die Plattform. Aktuelle und laufende Arbeiten umfassen:

  • Asynchrone Formular- und Dialogfeld-APIs
  • Unterstützung für dunklen Modus und visueller Stil
  • Verbesserungen bei Barrierefreiheit, High-DPI, Layout und Designer
  • Zwischenablage und DataObject-Modernisierung

Plattformübergreifende native Entwicklung

Was sind einige Gründe für die Erstellung plattformübergreifender nativer Apps, die auf Windows abzielen?

Wenn Sie Benutzer auf mehreren Betriebssystemplattformen ansprechen möchten, kann das Erstellen plattformübergreifender Apps mit .NET MAUI oder React Native zahlreiche Vorteile bieten.

  • Erreichen: Plattformübergreifende Apps erreichen ein größeres Publikum auf verschiedenen Geräten und Betriebssystemen.
  • Codewiederverwendung: Durch die Wiederverwendung von Code auf allen Plattformen wird die Entwicklungszeit und die Kosten reduziert. Das Erstellen separater Apps für Windows, Android, iOS und macOS kann unertragbar teuer sein.
  • Konsistente Benutzererfahrung: Plattformübergreifende Frameworks helfen dabei, ein einheitliches Aussehen und Verhalten auf allen Plattformen zu bieten.
  • Integration: Plattformübergreifende Apps können weiterhin mit plattformspezifischen Diensten integriert werden, um eine umfassende Erfahrung zu bieten.
Kann ich sicher sein, dass .NET MAUI-Apps gut auf Windows laufen?

Wenn Sie eine .NET MAUI-App für Windows erstellen, verwendet die Ausgabe WinUI 3. Während der Entwicklung bietet .NET MAUI eine einzige .NET Erfahrung auf allen Plattformen, generiert aber plattformspezifischen Code unter der Haube.

Wie kann .NET MAUI systemeigene Geräte-APIs auf jeder Plattform bereitstellen?

.NET MAUI bietet eine einheitliche .NET Erfahrung in Windows, iOS, Android und macOS. Es bietet plattformübergreifende APIs für allgemeine Funktionen wie Speicher, Netzwerk und Gerätesensoren. Sie können plattformspezifische APIs auch aufrufen oder spezielle Implementierungen für jede Plattform bereitstellen.

Kann ich mit WinUI 3 beginnen und später .NET MAUI integrieren, wenn ich schließlich plattformübergreifende Szenarien ansprechen möchte?

Zurzeit nicht. Obwohl .NET MAUI WinUI 3 bei der Ausführung auf Windows verwendet, sollten Teams, die davon ausgehen, dass sie auf mehrere Plattformen abzielen, mit .NET MAUI oder React Native für Desktop beginnen.

Unser Team verfügt über starke Web-Front-End-Entwicklungskompetenzen. Sollten wir die Verwendung von React Native für Desktop in Betracht ziehen?

Teams mit starker Webentwicklungserfahrung möchten möglicherweise React Native für Desktop in Betracht ziehen. Es enthält React Native für Windows und macOS. Mit dem Ansatz "Einmal lernen, überall schreiben" können vorhandene JavaScript-, TypeScript- und React-Fähigkeiten verwendet werden, um systemeigene Windows- und macOS-Apps zu erstellen.

React Native for Desktop rendert die Benutzeroberfläche direkt auf native Primitiven und liefert native Leistung sowie Plattformfähigkeiten.

Weitere Informationen zum Einstieg finden Sie in der React Native for Desktop-Dokumentation.

Werden noch andere Windows-Geräte von React Native für Desktop unterstützt?

React Native für Windows unterstützt die in der Kompatibilitätsdokumentation aufgeführten Windows Versionen. Überprüfen Sie die Gerätefamilienunterstützung für die React Native für Windows Version, die Sie als Ziel verwenden, anstatt davon auszugehen, dass jedes Windows Gerät unterstützt wird.

Was sollte ich verwenden, wenn ich Apps entwickeln möchte, die unter Windows und Xbox funktionieren?

Verwenden Sie für eine Xbox-App UWP und berücksichtigen Sie die Xbox-spezifischen UWP-Einschränkungen. Verwenden Sie für die Spieleentwicklung die Microsoft Game Development Kit.

Was sollte ich verwenden, wenn ich Apps entwickeln möchte, die auf Windows und Surface Hub funktionieren?

Verwenden Sie für einen Surface Hub, der die standardmäßige Teams-Räume- oder Surface Hub-Umgebung ausführt, eine UWP-App, die die anforderungen der Surface Hub-App erfüllt. Ein mit Windows 11 Pro oder Enterprise konfigurierter Surface Hub 3 kann unterstützte Desktop-App-Technologien ausführen, sodass UWP nicht die einzige Option in dieser Konfiguration ist.

Hybrid- und Webentwicklung

Was sind Hybrid-Apps, und warum sollte ich eins erstellen?

Hybrid-Apps kombinieren das Beste aus der Web- und nativen App-Entwicklung. Ihr Kern basiert auf Webtechnologien wie HTML, CSS und JavaScript und ist in einen systemeigenen Container eingeschlossen, der access bestimmten systemeigenen Plattformfeatures und -hardware bietet. Sie können auch über App-Stores verteilt werden.

Der Hauptvorteil besteht darin, dass Hybrid-Apps es Ihnen ermöglichen, eine einzelne App zu erstellen, die auf mehreren nativen Plattformen und im Web ausgeführt werden kann, wodurch die Entwicklungszeit und die Kosten reduziert werden. Beispiele für Hybrid-App-Entwicklungsplattformen sind:

  • Electron für Desktop-Apps
  • Ionic für mobile Apps
  • .NET MAUI Blazor Hybrid für plattformübergreifende Apps
Wie erstelle ich Progressive Web-Apps (PWAs) mit nativen Eindruck auf Windows?

Weitere Informationen finden Sie unter Web development on Windows and Overview of Progressive Web-Apps.

Was ist eine .NET MAUI Blazor Hybrid-App?

Mit .NET MAUI können Blazor-Apps nativ auf Windows, iOS, Android und macOS ausgeführt werden. Auf diese Weise können Sie hybride Client-Apps erstellen, die Blazor- und .NET MAUI-Komponenten in einer einzigen nativen Client-App kombinieren und vollzugriff auf systemeigene Plattformfunktionen haben.

Weitere Informationen finden Sie unter ASP.NET Core Blazor Hybrid.

Müssen die Webkomponenten einer .NET MAUI Hybrid-App mit Blazor erstellt werden?

Nein. Ab .NET 9 enthält .NET MAUI ein HybridWebView-Steuerelement, mit dem andere javaScript-basierte UIs in einer systemeigenen App gehostet werden können.

Auf diese Weise können Sie Angular-, React-, Vue- oder andere HTML/JavaScript-Apps in einer .NET MAUI-App hosten. Das Hybridsteuerelement stellt die Interoperabilität zwischen C# und JavaScript bereit, sodass C#-Code JavaScript-Funktionen aufrufen kann und umgekehrt.

Können andere systemeigene App-Typen Blazor-Hybridkomponenten hosten?

Ja. WPF- und WinForms-Apps können auch Blazor-Hybridkomponenten hosten, wodurch moderne Web-UIs zu bestehenden Apps hinzugefügt werden können. Dies wird für WPF- oder WinForms-Apps, die auf .NET Framework basieren, nicht unterstützt.

Muss meine gesamte App eine Hybrid-App sein oder kann ich systemeigene und hybride Komponenten kombinieren und abgleichen?

Systemeigene und Hybridkomponenten können innerhalb einer App gemischt werden. Beispielsweise kann der Kern einer App mit .NET MAUI Komponenten erstellt werden, während Hybridkomponenten zusätzliche Funktionen bereitstellen. Dies ermöglicht die Kombination der Leistung und Funktionen systemeigener Komponenten mit der Flexibilität und Kosteneffizienz von Hybridkomponenten.

Welche Optionen habe ich, um .NET-basierte Web-Anwendungen zu erstellen, die auf modernen Browsern unter Windows großartig aussehen?

Web apps bieten die größtmögliche Reichweite jeder Client-App-Plattform. Zu den Optionen zum Erstellen ansprechender .NET Web-Apps gehören:

  • ASP.NET Core Apps mit Razor Pages
  • ASP.NET Core MVC-Apps
  • ASP.NET Core Blazor-Apps mit Hostingmodelloptionen:
    • Blazor WebAssembly-Technologie
    • Blazor Server

Blazor-Hostingmodelle können jetzt auf Komponentenebene konfiguriert werden und ermöglichen Szenarien wie das Hosten einer Blazor WebAssembly-Komponente in einer Blazor Server-App.

Weitere Informationen finden Sie in der dokumentation ASP.NET Core.

Wählen Sie einen Ansatz aus, und verstehen Sie die Investitionen von Microsoft

There sind so viele Frameworkoptionen zum Erstellen von Apps, die auf Windows abzielen! Wie entscheide ich mich?

Windows ist eine offene Plattform, die viele Technologien unterstützt. Hier sind einige Kriterien, mit denen Sie eine Plattform auswählen können:

  • Entwickeln Sie primär für Windows oder plattformübergreifend?
  • Welche Sprachen oder Fähigkeiten haben Sie bereits – .NET, JavaScript, etwas anderes?
  • Benötigen Sie Zugriff auf Windows-spezifische APIs?
  • Welche Framework-Funktionen entsprechen den Anforderungen Ihrer App am besten?
  • Weitere Vergleichsfaktoren finden Sie in dieser Tabelle .

Bei vielen Geschäfts-Apps wählen Teams häufig basierend auf vorhandenen Fähigkeiten und dem, was das Team am bequemsten verwendet.

Wie wähle ich den besten Entwicklungsansatz für meine Web-App aus?

Berücksichtigen Sie beim Auswählen eines Entwicklungsansatzes für Ihre Web-App Folgendes:

  • Blazor wird für das Erstellen von Front-End-Web-Apps mit .NET empfohlen. Damit können Sie sowohl das Front-End als auch das Back-End mithilfe von .NET erstellen, Zeit und Kosten sparen und für Unternehmens-Apps besonders gut geeignet sein.
  • JavaScript-Webanwendungen sind nach wie vor sinnvoll, wenn Sie vorhandene JavaScript-Fähigkeiten nutzen möchten oder in etablierte JavaScript-Bibliotheken oder -Frameworks integrieren müssen.
  • Vorhandene Apps, die ältere Frameworks wie Webformulare, MVC oder Razor Pages verwenden, werden weiterhin unterstützt und können weiterhin entwickelt und verwaltet werden.
Wer erstellt Apps mit WinUI 3 heute?

Microsoft Fotos ist ein dokumentiertes Beispiel. Die App wurde von UWP zu dem Windows App SDK migriert und verwendet WinUI 3 weiterhin. Ausführliche Informationen zur Architektur und Migration finden Sie unter Microsoft Fotos: Migrieren von UWP zu Windows App SDK.

Who erstellt heute .NET MAUI Apps?

Organisationen verwenden .NET MAUI, um plattformübergreifende Apps für Android, iOS, macOS und Windows zu erstellen. Beispiele finden Sie im .NET Kunden-Showcase.

Who erstellt heute WPF Apps?

Die meisten der Microsoft Visual Studio UI werden mit WPF erstellt. Die Visual Studio-IDE selbst ist ein wichtiges Beispiel für eine komplexe, leistungsstarke WPF-App.

Wer erstellt heute Blazor-Apps?

Das FlightPulse Airline-System von GE Digital verwendet Blazor für die Back-End-Konfiguration aller Elemente, die Piloten sehen, und bringt Sensordaten und Analysen direkt zu den Piloten, um die Sicherheit und Effizienz zu verbessern.

Weitere Blazor-Kundengeschichten auf der .NET-Website anzeigen.

Sprachauswahl (.NET vs C++)

Sollte ich C# oder C++ für meine Windows-App verwenden?

Verwenden Sie in den meisten Fällen C# (.NET). C# bietet schnellere Entwicklung, Speichersicherheit, umfangreiche Bibliotheken und hervorragende Tools. Die meisten Windows Apps – einschließlich WinUI 3, WPF, WinForms und .NET MAUI Apps – werden am besten mit C# erstellt.

Verwenden Sie C++ , wenn Sie direkten Hardwarezugriff, minimalen Laufzeitaufwand oder Interoperabilität mit vorhandenen C++-Codebasen benötigen. Allgemeine C++-Szenarien umfassen Game Engines (DirectX), Treiber, Dienstprogramme auf Systemebene und leistungskritische Komponenten.

Faktor C# (.NET) C++
Entwicklungsgeschwindigkeit ✅ Schneller – verwalteter Speicher, reichhaltiges Ökosystem ⚠– Langsamer — manuelles Ressourcenmanagement
Laufzeitleistung ✅Hervorragend mit modernem .NET (AOT, Span<T>) ✅ Optimal möglich – keine GC-Pausen
Speichersicherheit ✅ Garbage-Collected ⚠️ Manuell — Risiko von Lecks und Schwachstellen
Windows API-Zugriff ✅ Über die C#/WinRT-Projektion ✅ Über C++/WinRT-Projektion
WinUI 3-Unterstützung ✅ Vollständiger Support ✅ Vollständiger Support über C++/WinRT
Plattformübergreifend ✅.NET wird unter Windows, Linux, macOS ausgeführt ✅ Mit plattformspezifischem Code
Am besten geeignet für Geschäfts-Apps, CRUD, Dienste, benutzeroberflächenintensive Apps Spiele, Treiber, Systemtools, geringe Latenz

Sie können auch beides kombinieren: Erstellen Sie Ihre App in C# und rufen Sie leistungskritischen systemeigenen Code über P/Invoke (CsWin32) oder eine C++/WinRT-Komponente auf.

Wie kann ich Win32-APIs aus C# aufrufen?

Verwenden Sie CsWin32, einen Quellgenerator, der während der Buildzeit typsichere P/Invoke-Signaturen generiert. Sie fügen das Microsoft.Windows.CsWin32 NuGet-Paket hinzu, listen die APIs auf, die Sie in einer NativeMethods.txt Datei benötigen, und rufen sie über eine generierte PInvoke Klasse auf.

CsWin32 ersetzt handschriftlichen [DllImport] Deklarationen und funktioniert in jedem C#-Projekt, einschließlich WinUI 3, WPF, WinForms und Konsolen-Apps. Eine schrittweise exemplarische Vorgehensweise finden Sie unter Aufrufen von Win32-APIs aus einer C#-Windows-App (CsWin32).

Was ist C++/WinRT und wann sollte ich es verwenden?

C++/WinRT ist eine C++17-Standardsprachenprojektion für Windows-Runtime-APIs. Verwenden Sie sie beim Erstellen Windows Apps in C++, die WinRT-APIs nutzen oder erstellen. Es ersetzt C++/CX und die Windows-Runtime C++-Vorlagenbibliothek (WRL).

Wählen Sie C++/WinRT in folgenden Fällen aus:

  • Sie erstellen eine C++-WinUI 3-App
  • Sie müssen Windows-Runtime komponenten erstellen, die von anderen Sprachen verwendet werden
  • Sie migrieren von C++/CX
Was ist C#/WinRT und wann benötige ich es?

C#/WinRT bietet WinRT-Projektionsunterstützung für C#. In den meisten Fällen interagieren Sie nicht direkt damit – .NET-Apps, die auf Windows abzielen, erhalten automatisch über Target-Framework-Moniker (TFMs) Zugriff auf WinRT-APIs. Sie benötigen C#/WinRT explizit beim Erstellen Windows-Runtime Komponenten in C# oder beim Generieren von Interopassemblys für WinRT-Komponenten von Drittanbietern.

Verpackung, Bereitstellung und Aktualisierungen

Was ist der Unterschied zwischen Apps, die verpackt, entpackt und mit externem Speicherort verpackt sind?

Eine verpackte App enthält ihre Dateien, Identitäts- und Bereitstellungsinformationen in einem Paket wie MSIX. Eine entpackte App verwendet einen Installationsprogramm- oder Bereitstellungsprozess außerhalb des Windows Paketsystems und besitzt standardmäßig keine Paketidentität. Eine mit externem Speicherort verpackte App verwendet ein kleines Identitätspaket, während extern gespeicherte Binärdateien und der vorhandene Installationsprogramm- und Aktualisierungsprozess beibehalten werden.

Siehe Verpackungsübersicht zu Anforderungen und Kompromissen.

Benötige ich paketidentität?

Dies hängt von den Windows Features ab, die Ihre App verwendet. Die Paketidentität ist für Szenarien wie verpackte Hintergrundaufgaben, Freigabeziele, Startaufgaben, benutzerdefinierte Kontextmenüpaketerweiterungen, manifestbasierte Dateityp- und Protokollzuordnungen und viele Windows AI-APIs erforderlich. Windows App SDK-Pushbenachrichtigungen unterstützen eingeschränkte Vordergrundszenarien ohne Identität, aber die Zustellung im Hintergrund und die COM-Aktivierung erfordern Identität. WinUI 3- und lokale App-Benachrichtigungen können ohne Paketidentität funktionieren.

Weitere Informationen finden Sie unter Features, für die Paketidentität benötigt wird. Wenn Sie eine Identität benötigen, aber ein vorhandenes Installationsprogramm beibehalten müssen, sollten Sie das Verpacken mit externem Speicherort in Betracht ziehen.

Was ist der Unterschied zwischen frameworkabhängiger und eigenständiger Bereitstellung?

Eine frameworkabhängige App verwendet Windows App SDK Laufzeitpakete, die separat auf dem Gerät installiert sind. Dies reduziert die Bereitstellungsgröße der App und ermöglicht es dem installierten Framework, Wartungsupdates zu erhalten. Eine eigenständige App bringt ihre Windows App SDK-Abhängigkeiten mit, was die Größe der Bereitstellung erhöht und den App-Herausgeber dafür verantwortlich macht, Windows App SDK-Wartungsupdates mit neuen App-Versionen zu verteilen.

APIs, die von zusätzlichen MSIX-Paketen wie dem Singleton-Paket abhängen, können separate Bereitstellungs- oder Laufzeitunterstützungsprüfungen auch in einer eigenständigen App erfordern. Paketierung und Laufzeitbereitstellung sind voneinander getrennte Entscheidungen. Weitere Informationen finden Sie unter Übersicht über die Windows App SDK-Bereitstellung.

Wird meine WinUI 3-App automatisch für Endbenutzer aktualisiert?

Eine WinUI 3-App kann über den Microsoft Store, eine .appinstaller-Datei oder ein MSI-Paket bzw. Setupprogramm bereitgestellt werden. Store-Pakete können über die Wartung im Microsoft Store aktualisiert werden, abhängig von den Einstellungen des Stores und der Organisation. Eine .appinstaller-Bereitstellung unterstützt automatische Updates nur, wenn ihre UpdateSettings Startzeit oder Hintergrundprüfungen konfiguriert. MSI- und Setup-Installationen müssen einen eigenen Aktualisierungsmechanismus bereitstellen oder integrieren.

Kann ich Windows App SDK verwenden, ohne MSBuild zu benutzen?

Ja, für einige Szenarien. WinUI 3-XAML-Projekte erfordern derzeit MSBuild, obwohl Visual Studio nicht erforderlich ist und dotnet build MSBuild über die Befehlszeile aufrufen kann. Sie können nicht-XAML-basierte Windows App SDK-APIs aus C++- und CMake-Projekten über die Vorschau Windows-App Development CLI verwenden oder die Laufzeit manuell integrieren.

Windows Künstliche Intelligenz (KI)

Wie wähle ich zwischen Windows AI-APIs, Foundry Local und Windows ML aus?

Die ersten drei Technologien sind Teil Microsoft Foundry on Windows. Sie können sie miteinander und mit Cloudmodellen in derselben App kombinieren:

  • Verwenden Sie Windows KI-APIs für sofort einsatzbereite Funktionen, deren Modelle und Hardwarebeschleunigung von Windows verwaltet werden.
  • Verwenden Sie Foundry Local , um unterstützte Open Source-Sprach- und Sprachmodelle lokal zu ermitteln, herunterzuladen und auszuführen.
  • Verwenden Sie Windows ML, um Ihre eigenen ONNX-Modelle mit Ausführungsanbietern für verfügbare CPU-, GPU- und NPU-Hardware auszuführen.
  • Verwenden Sie Microsoft Foundry, eine separate Cloud AI-Plattform, wenn Sie in der Cloud gehostete Modelle, Abrufe, zentralisierte Governance oder Funktionen benötigen, die auf dem Zielgerät nicht verfügbar sind.

Vergleichen Sie die Optionen in "Auswählen Ihrer Windows KI-Lösung". Berücksichtigen Sie modellfähige Funktionen, Datenschutz, Konnektivität, Latenz, Hardwareabdeckung, Bereitstellungsgröße und Betriebskosten.

Benötigen Windows KI-Features eine Copilot+ PC?

Nicht alle. Viele Windows KI-APIs erfordern eine Copilot+ PC, aber einige APIs unterstützen auch bestimmte GPUs oder CPUs. Foundry Local und Windows ML unterstützen umfassendere Hardwarekonfigurationen, vorbehaltlich ihrer aktuellen Betriebssystem-, Modell-, Laufzeit- und Ausführungsanbieteranforderungen.

Überprüfen Sie die Windows AI-API-Hardwaretabelle und die Anforderungen für die spezifische API oder das spezifische Modell. Erkennen Sie zur Laufzeit die Unterstützung und die Einsatzbereitschaft des Modells und stellen Sie eine nicht KI-basierte, lokale Modell- oder Cloud-Ausweichlösung bereit, wenn die Funktion nicht verfügbar ist.

Können Windows KI-Features lokal und offline ausgeführt werden?

Ja. Windows AI-APIs, Foundry Local und Windows ML können auf dem Gerät des Benutzers ausgeführt werden, wodurch die Latenz reduziert und Eingabedaten lokal gehalten werden können. Einige Modelle oder Ausführungsanbieter müssen zuerst heruntergeladen oder bereitgestellt werden und können während der Einrichtung oder Wartung eine Internetverbindung erfordern. Cloud AI-Dienste erfordern Konnektivität und Senden von Daten an den Dienst gemäß ihren Datenverarbeitungsbedingungen.

Informieren Sie Benutzer, wann ein Modelldownload erforderlich ist und wenn Daten das Gerät verlassen. Bezeichnen Sie eine Funktion erst dann als offlinefähig, wenn Sie ihren ersten Start, Aktualisierungen und das Fallback-Verhalten vollständig getestet haben.

Können KI-Tools mir helfen, eine Windows-App zu erstellen oder zu modernisieren?

Ja. KI-Codierungs-Agents können Gerüstprojekte unterstützen, APIs erläutern, Code migrieren, Tests generieren und Buildprobleme diagnostizieren. Verwenden Sie die KI-unterstützte Windows Entwicklungsanleitung für GitHub Copilot, das WinUI-Agent-Plug-In, die Microsoft Learn MCP Server, Migrationsworkflows und KI-unterstützte Tests.

Überprüfen und testen Sie generierten Code wie alle anderen Beiträge. Überprüfen Sie insbesondere API-Namen und -Versionen, Paketfunktionen, sicherheitsrelevanten Code, Barrierefreiheit und alle UWP-zu-WinUI 3-Ersetzungen.

Was sollte ich berücksichtigen, bevor ich ein KI-unterstütztes Feature versenden kann?

Definieren Sie die beabsichtigte Verwendung und Einschränkungen des Features, bewerten Sie Qualität und Sicherheit mit repräsentativen Daten, geben Sie gegebenenfalls KI-Verhalten offen, schützen Sie Benutzerdaten und stellen Sie einen Fallback bereit, wenn das Modell oder die erforderliche Hardware nicht verfügbar ist. Halten Sie Geheimnisse und privilegierte Service-Anmeldeinformationen aus Client-Apps heraus, und verlangen Sie vor folgenschweren oder irreversiblen Aktionen eine Benutzerbestätigung. Siehe Verantwortungsvolle Entwicklung generativer KI für Windows und Sicherheit und verantwortungsvolle KI für die Windows-Entwicklung.

Leistung und Optimierung

Was kann ich tun, damit meine Windows-App großartig für die Endbenutzer wirkt?

Siehe Windows Anwendungsentwicklung – Bewährte Methoden und Windows Übersicht über app-Leistung und Grundlagen.

Compatibility

Müssen meine Benutzer jemals Windows aktualisieren, um meine WinUI 3-App zu verwenden?

Die Windows App SDK verfügt über ein mindestkompatibles Betriebssystem von Windows 10, Version 1809, Build 17763. Microsoft Unterstützung erfordert eine unterstützte Windows App SDK-Version mit dem neuesten Wartungsupdate und einer Windows Edition, Version und Wartungskanal, die noch unterstützt wird. Einzelne APIs können eine neuere Windows Version oder spezifische Hardware erfordern. Siehe Windows App SDK Support- und Veröffentlichungskanäle.

Kann ich arm64 mit meiner WinUI 3-App als Ziel verwenden?

Ja. Erstellen Sie eine systemeigene Arm64-App für optimale Leistung und Effizienz. Bei einer großen C++-Codebasis mit x64-Abhängigkeiten können Sie Module inkrementell migrieren. Windows 11 auf Arm können auch viele vorhandene x86- und x64-Apps über Prism-Emulation ausführen, aber Sie sollten die Leistung und Kompatibilität auf repräsentativen Arm-Geräten testen.

Veraltete Versionen und Migrationen

Sind UWP/WinUI für UWP veraltet?

UWP und WinUI 2 sind nicht formal veraltet. Visual Studio 2026 unterstützt UWP mit modernen .NET und Native AOT, während WinUI 2.8 die neueste stabile WinUI-Version für UWP bleibt. Microsoft empfiehlt jedoch WinUI 3 und die Windows App SDK für neue allgemeine Windows Desktop-Apps.

UWP-Unterstützung für moderne .NET mit nativem AOT ist allgemein verfügbar und ist der Standardmäßige C#-UWP-Projekttyp in Visual Studio 2026. Das Verschieben einer vorhandenen UWP-App von .NET Native auf moderne .NET ist ein separater Modernisierungsschritt vom Migrieren der Benutzeroberfläche zu WinUI 3. Weitere Informationen finden Sie unter Modernisieren Ihrer UWP-App mit .NET und nativem AOT.

Wann sollte ich eine UWP/WinUI für UWP-App zu WinUI 3 migrieren?

UWP-Entwickler sollten sich nicht unter Druck setzen, zu migrieren, wenn sie mit UWP und seinem Featuresatz zufrieden sind – für viele Apps kann die richtige Wahl darin bestehen, auf UWP zu bleiben.

Apps, die von den neuesten Neuerungen der Windows-Plattform und von .NET profitieren möchten, sollten einen Umstieg auf WinUI 3 und das Windows App SDK in Betracht ziehen. Siehe Migrate von UWP zum Windows App SDK.

Wann sollte ich *nicht* eine UWP + WinUI für UWP-App zu WinUI 3 migrieren?

Verwenden Sie UWP weiterhin, wenn ihr Zielgerät oder App-Modell dies erfordert, z. B. Xbox Apps, HoloLens 2D-Apps oder Apps für die Standard-Surface Hubumgebung. Windows IoT Enterprise unterstützt Desktop-App-Technologien, einschließlich des Windows App SDK, daher ist ein IoT-Ziel nicht allein ein Grund für die Verwendung von UWP.

Ist WPF abgekündigt?

Nein. WPF wird unterstützt und erhält im modernen .NET weiterhin Verbesserungen bei Funktionen, Leistung, Barrierefreiheit und im Fluent-Design. Es bleibt eine gute Wahl für vorhandene WPF-Apps und für neue Apps, deren Anforderungen WPF passen. Für neue allgemeine Windows Desktop-Apps empfiehlt Microsoft WinUI 3 mit dem Windows App SDK. Siehe die WPF-Roadmap auf GitHub.

Ist WinForms veraltet?

Nein. WinForms wird unterstützt und empfängt weiterhin Funktionsupdates. Sehen Sie die Windows Forms Roadmap auf GitHub.

Ist die Windows-Runtime (WinRT) veraltet?

Nein. WinRT ist eine Binärschnittstelle (Application Binary Interface, ABI), die die Interoperabilität über mehrere Sprachen hinweg ermöglicht. WinRT ist die Entwicklung von COM, und die Windows App SDK bietet die meisten Funktionen über WinRT-APIs.

Versionshinweise

Wo finde ich Versionshinweise für Windows App SDK?

Lesen Sie die Windows App SDK Versionshinweise zu stabilen, Vorschau- und experimentellen Versionen. Die Seite "Neuigkeiten für Windows Entwickler" fasst die neuesten Windows SDK-, Windows App SDK-, WinUI 3-, Tool- und Plattformupdates zusammen.

Verwandte Inhalte

  • Last updated on