Foire aux questions sur le développement d'applications Windows

Ce FAQ fournit des réponses aux questions courantes sur Windows développement d’applications, notamment des conseils sur le choix de l’infrastructure appropriée pour vos projets. Sont abordés les sujets suivants :

  • Introduction au paysage du développement d’applications Windows.
  • Développement d’applications natives Windows uniquement avec WinUI 3, Windows Presentation Foundation (WPF) et Windows Forms (WinForms).
  • Windows Kit de développement logiciel (SDK) et SDK d'application Windows.
  • Ciblage de Windows dans le cadre de votre stratégie de développement multiplateforme.
  • Développement d’applications hybrides et web avec .NET MAUI, Blazor et ASP.NET Core.
  • Comment choisir une approche tout en comprenant les investissements de Microsoft.

paysage de développement d’applications Windows

Partout puis-je trouver une vue d’ensemble simple des technologies de développement Windows ?

Pour une vue d'ensemble des options d'aujourd'hui pour les développeurs Windows, regardez l'épisode Windows Dev Chat Choix de votre plateforme de développement idéale, qui traite de WinUI 3, .NET MAUI, React Native, Blazor et Progressive Web Apps (PWA). Vous trouverez d’autres épisodes dans la playlist Windows Dev Chat.

Vous pouvez également faire référence à la overview des options de développement d’applications pour les développeurs Windows.

Quand le développement d’applications clientes est encore crucial pour la transformation numérique moderne à l’ère de cloud services ?

À l’âge des services cloud, le développement d’applications clientes reste important pour fournir des interactions réactives et significatives sur les appareils utilisateur.

Voici pourquoi les applications clientes sont importantes :

  • Portée de l’appareil : Les applications clientes vous permettent d’apporter directement votre application aux utilisateurs sur leurs appareils de choix.
  • Passerelle vers les Services Intelligents : Les applications clientes sont souvent le premier point d'interaction entre les utilisateurs et vos services. Ils offrent une interface riche et interactive qui vous permet de présenter des fonctionnalités intelligentes et de différencier votre produit des autres.
  • Extensibilité avec l'intégration au cloud : Une application cliente bien intégrée peut être synchronisée sans effort avec les services cloud de back-end, permettant un accès aux données en temps réel et une extensibilité transparente à mesure que votre base d’utilisateurs augmente.
  • productivité améliorée et la fidélité des utilisateurs : une application conçue de manière réfléchie peut améliorer la productivité et maintenir les utilisateurs engagés avec votre produit ou service au fil du temps.

Développement d’applications natives Windows uniquement

Quelle est la SDK d'application Windows ?

Le SDK d'application Windows fournit des composants gérés indépendamment pour les applications de bureau Windows, notamment WinUI 3, le cycle de vie des applications, la fenêtre, les notifications, les ressources et les API de texte. Il prend en charge les applications qui s’exécutent sur Windows 10 à partir de la version 1809, sous réserve du cycle de vie du support de la version de Windows et de la version du SDK d’application Windows.

Quelle est la différence entre le SDK d'application Windows et le SDK Windows ?

Les deux sont des kits de développement logiciel (SDK) qui vous permettent de créer des applications Windows.

Le SDK d'application Windows fournit des composants fournis indépendamment de Windows et fonctionnent dans les versions de Windows prises en charge jusqu’à Windows 10, version 1809. Il inclut WinUI 3 et les API pour le cycle de vie des applications, la fenêtre, les notifications, les ressources, le texte et d’autres fonctionnalités.

Le sdk Windows fournit des en-têtes, des bibliothèques, des métadonnées et des outils pour les API de système d’exploitation telles que Win32, WinRT, COM, DirectX, appareils et fonctionnalités shell.

Le SDK d'application Windows ne remplace pas le Windows SDK. Les applications qui adoptent le SDK d'application Windows peuvent continuer à utiliser Windows API sdk, et les applications WinUI 3 utilisent couramment les deux.

Je crée une nouvelle équipe pour développer une application Windows uniquement. Pourquoi dois-je choisir de développer avec un framework de Windows natif tel que WinUI 3, WPF ou WinForms ?

Voici quelques raisons de choisir une infrastructure de Windows native pour votre application Windows uniquement :

  • Performance : Les infrastructures natives Windows sont optimisées pour tirer parti du matériel moderne Windows, offrant ainsi des expériences utilisateur rapides et réactives.
  • Integration : Windows est fourni avec une grande variété d’API qui permettent des expériences sophistiquées uniquement disponibles sur Windows. Les frameworks natifs fournissent une intégration approfondie à ces fonctionnalités et API.
  • Native expérience utilisateur : Les infrastructures natives offrent une expérience cohérente sur les appareils Windows, ce qui garantit que votre application ressemble et fonctionne parfaitement partout.
  • Prise en charge hors connexion : Les frameworks natifs prennent en charge les scénarios hors connexion, ce qui permet aux applications de fonctionner même sans connectivité Internet.
  • Prise en charge et outils : Microsoft gère les frameworks natifs et fournit des kits SDK, de la documentation, des outils de débogage et des exemples actuels.
Which framework dois-je utiliser pour tirer parti des derniers investissements de Microsoft dans le développement d'applications Windows ?

Si vous créez une nouvelle application de bureau à usage général Windows, nous vous recommandons d'utiliser WinUI 3. WinUI 3 est l’infrastructure d’interface utilisateur native fournie avec le SDK d'application Windows. Il prend en charge les applications de bureau Windows et donne accès aux contrôles Fluent les plus récents ainsi qu’aux fonctionnalités de la plateforme Windows.

Puis-je utiliser SDK d'application Windows /WinUI 3 dans mon application Windows existante ?

Notez que WinUI 3 (une infrastructure d’interface utilisateur) est fourni avec le SDK d'application Windows (infrastructure de développement de plateforme Windows).

Vous pouvez migrer l'interface utilisateur d'une application vers WinUI 3 ou utiliser WinUI XAML Islands pour héberger des contrôles SDK d'application Windows dans un hôte de bureau existant pris en charge. Les XAML Islands du système hérité hébergent des contrôles XAML UWP et utilisent des API différentes.

Les éléments du SDK d'application Windows peuvent souvent être utilisés dans les applications de bureau, en fonction de la façon dont l’application existante a été créée. Les applications UWP ne sont pas prises en charge par SDK d'application Windows.

Cela signifie que les applications WPF/MFC/WinForms peuvent utiliser SDK d'application Windows API qui ne sont pas liées à WinUI 3. Les exemples incluent le cycle de vie des applications, la fenêtrage et les notifications d’application.

Pour plus d’informations, consultez Utilisez la SDK d'application Windows dans un projet existant.

Dois-je utiliser Visual Studio pour générer des applications WinUI 3 ?

Non. Les builds XAML WinUI 3 utilisent MSBuild, mais vous pouvez créer avec le SDK .NET et les modèles WinUI 3 actuels à partir de la ligne de commande dans un autre éditeur. Consultez le guide de démarrage rapide en ligne de commande.

Visual Studio 2026 offre l’expérience d’édition, de débogage, de profilage et de Rechargement à chaud XAML intégrées les plus riches. Utilisez le flux de travail qui correspond à vos exigences en matière d’outils.

Je reçois une erreur « Impossible de charger la DLL 'Microsoft.ui.xaml.dll' » lorsque je lance mon application. Comment résoudre ce problème ?

Cette erreur se produit généralement dans les scénarios d'application unpackaged où le runtime SDK d'application Windows n'a pas été installé sur l'ordinateur. Essayez les solutions suivantes :

  • Si vous exécutez une application packaged (la valeur par défaut recommandée), vérifiez que vous lancez via Visual Studio avec le MsixPackage profil de lancement sélectionné (et non le profil exécutable brut). L’étape d’empaquetage MSIX installe les composants d’exécution requis.
  • Si vous exécutez une application non empaquetée dépendante de l'infrastructure, installez le runtime correspondant SDK d'application Windows. Un déploiement autonome inclut ses dépendances SDK d'application Windows.
  • Vérifiez que votre projet correspond à votre modèle de déploiement. Pour une application normale .NET non empaquetée, le paramètre <WindowsPackageType>None</WindowsPackageType> active SDK d'application Windows l’initialisation automatique du runtime. Utilisez directement l’API de démarrage lorsque vous avez besoin d’un contrôle explicite sur l’initialisation des dépendances dynamiques.

Consultez Déployer des applications qui utilisent le SDK d'application Windows pour plus d’informations sur les exigences de déploiement.

Quelle est la différence entre WinUI 3 et WinUI 2 pour UWP ?

WinUI 3 est l'infrastructure d'interface utilisateur native actuelle de Microsoft pour les applications de bureau Windows et est fournie dans le cadre du SDK d'application Windows.

WinUI 2, également appelé WinUI pour UWP, est une bibliothèque de contrôle et de style pour les applications UWP. WinUI 2 et WinUI 3 utilisent différents espaces de noms XAML et ne sont pas compatibles binaires.

Quand je crée une application à l’aide de SDK d'application Windows et winUI 3, est-ce que je crée une « application WinUI » ?

Yes. L’application WinUI 3 est le terme le plus clair pour une application dont l’interface utilisateur utilise WinUI 3 et le SDK d'application Windows. L’application WinUI est également couramment utilisée lorsque le contexte n’est pas ambigu.

Puis-je mettre à jour de manière incrémentielle mon application UWP avec WinUI pour les contrôles UWP vers WinUI 3 en remplaçant progressivement les contrôles ?

Non. SDK d'application Windows ne peuvent pas être utilisés dans les applications UWP et WinUI pour UWP ne peuvent pas être mélangés avec WinUI 3. Consultez Migrate de UWP au SDK d'application Windows.

Quelle est la difficulté de migrer une application UWP vers WinUI 3 ?

UWP et WinUI 3 partagent de nombreux concepts XAML, mais la migration n’est pas une modification directe de l’espace de noms. Le coût dépend principalement des éléments suivants :

  1. Fichier projet et personnalisation de MSBuild : L’effort de migration varie en fonction de l’utilisation avancée de MSBuild.
  2. migration d’API .NET : les applications UWP utilisant .NET Native peuvent passer à une version .NET actuellement prise en charge avec AOT natif. Cette modernisation est distincte de la migration de l’interface utilisateur vers WinUI 3.
  3. Bibliothèques de composants d’interface utilisateur : Les bibliothèques doivent avoir des versions ciblant WinUI 3.
  4. API de fenêtrage et de modèle d’application : Les API UWP liées à des concepts tels que CoreWindow, ApplicationViewou GetForCurrentView nécessitent des remplacements SDK d'application Windows ou une autre approche de bureau.
  5. Projection de langage C++ : Si l’application UWP utilise la projection C++/CX remplacée, portez ce code vers C++/WinRT.

Pour plus d’informations, consultez Migrer d’UWP vers SDK d'application Windows et la correspondance des API entre UWP et SDK d'application Windows.

Si j’ai une application UWP existante dans le Windows Store, puis-je publier une nouvelle application WinUI 3 empaquetée à l’aide des mêmes identificateurs ?

Oui, les applications mises à niveau peuvent être publiées sans mettre à jour l’identité de l’application. Les utilisateurs de l’ancienne version seront mis à jour vers la nouvelle version. Cela s’applique uniquement aux applications de bureau. les applications Xbox, HoloLens et standard Surface Hub ne peuvent pas migrer vers WinUI 3.

Comment empaqueter ou distribuer mon application WinUI 3 ?

Consultez Vue d’ensemble du déploiement.

Où trouver SDK d'application Windows conseils de migration ?

Consultez Migrate de UWP au SDK d'application Windows.

Dois-je utiliser le balisage XAML si je souhaite utiliser WinUI 3 ?

Non. Les contrôles d’interface utilisateur peuvent être créés dans le code. Toutefois, la représentation de l’interface utilisateur dans le balisage XAML déclaratif offre de nombreux avantages, notamment une expérience de développement améliorée.

  • Migration de UWP vers WinUI 3 : de nombreux concepts XAML et d’interface utilisateur sont reportés, mais les espaces de noms, le modèle de projet et certaines API diffèrent.
  • Migration de WPF vers WinUI 3 : de nombreux concepts sont reportés, mais le jeu de contrôles et les API diffèrent.
Visual Studio dispose-t-il d’une aire de conception ou d’un concepteur d’interface utilisateur pour WinUI 3 ?

Actuellement non. Utilisez xaml Rechargement à chaud, Live Visual Tree, Live Property Explorer et les outils d’exécution associés pour inspecter et mettre à jour le code XAML pendant l’exécution de l’application.

Pour obtenir une procédure pas à pas complète des outils de conception du runtime disponibles pour WinUI 3, consultez les outils de conception du runtime XAML pour WinUI 3.

Est-ce que SDK d'application Windows incluez WinUI 3 ?

Yes. WinUI 3 est fourni dans le SDK d’application Windows.

Does SDK d'application Windows inclure WinUI pour UWP ?

Non. WinUI pour UWP fait partie de la plateforme UWP.

WinUI pour UWP et WinUI 3 reposent-ils sur la même technologie ?

Pas tout à fait. Bien que WinUI 3 a commencé à partir de la base de code WinUI pour UWP, ils sont des technologies distinctes. Les deux sont des frameworks d'interface utilisateur XAML qui fonctionnent entre .NET et C++, mais WinUI pour UWP et WinUI 3 ne sont pas compatibles les uns avec les autres.

Puis-je utiliser WinUI 3 sans utiliser SDK d'application Windows ?

Non. WinUI 3 est fourni dans le SDK d’application Windows.

Puis-je utiliser WinUI 3 dans une application non empaquetée ?

Yes. WinUI 3 et de nombreuses API SDK d'application Windows fonctionnent dans des applications non empaquetées. Toutefois, certaines fonctionnalités Windows nécessitent une identité de package et les applications non empaquetées dépendantes du framework doivent initialiser le runtime SDK d'application Windows. Comparez les options dans Vue d’ensemble du packaging et Fonctionnalités nécessitant une identité de package.

Quelle est la différence entre XAML Islands et WinUI 3 ?

WinUI 3 est l’infrastructure d’interface utilisateur incluse dans le SDK d'application Windows. XAML Islands est une technique d’hébergement qui permet à une application de bureau existante de placer du contenu XAML en même temps que l’interface utilisateur d’un autre framework.

Le terme peut faire référence aux îles XAML système héritées qui hébergent des contrôles XAML UWP ou à WinUI XAML Islands qui hébergent des contrôles SDK d'application Windows dans les hôtes de bureau pris en charge. Les API, espaces de noms et exigences de l’hôte diffèrent.

Si je crée une application WinUI 3, sera-t-elle moderne à la fois sur Windows 11 et Windows 10 ?

Les contrôles WinUI 3 utilisent le style Fluent sur les versions prises en charge de Windows 10 et de Windows 11, dans les applications empaquetées et non empaquetées. Certains effets et comportements du système d’exploitation diffèrent par Windows version. Par exemple, Mica est disponible sur Windows 11 et revient à une couleur unie sur Windows 10.

Puis-je utiliser des arrière-plans Mica ou Acrylique dans les applications créées avec SDK d'application Windows ?

Yes. L’acrylique de bureau est pris en charge sur Windows 10, version 1809 et ultérieure. Mica nécessite Windows 11 et revient à une couleur de thème unie sur Windows 10. Appelez MicaController.IsSupported ou DesktopAcrylicController.IsSupported au moment de l’exécution avant d’appliquer un arrière-plan. Consultez Appliquer des matériaux Mica ou acryliques dans les applications de bureau pour Windows 11.

Où puis-je trouver des exemples WinUI 3 ?

Consultez l’exemple et les ressources. Voici quelques référentiels notables :

Si j’ai déjà investi dans WPF, dois-je continuer à utiliser WPF ou envisager de migrer vers WinUI 3 ?

Si vous avez déjà investi dans WPF, vous pouvez continuer à l'utiliser pour les applications existantes. WPF est un framework mature et stable largement utilisé pour créer des applications de bureau Windows.

Utilisez la fonctionnalité de mise à niveau de GitHub Copilot pour évaluer et mettre à niveau une application WPF .NET Framework vers .NET moderne. Passez en revue le plan généré et validez chaque modification dans votre application.

Si je crée une nouvelle application WPF, semblera-t-elle datée par rapport à d'autres applications Windows récemment créées ?

Lors du développement d’une application WPF avec .NET 9 ou version ultérieure, vous pouvez vous assurer que votre application correspond à l’apparence moderne et élégante de Windows 11. Le nouveau thème Fluent pour WPF introduit une esthétique Windows 11 contemporaine, avec le mode Clair/Foncé intégré et la prise en charge des couleurs d’accentuation système. Cela modernise l’apparence de votre application et offre une expérience utilisateur soignée et cohérente.

Mon équipe est à l’aise dans la création d’applications WinForms, et elle répond à nos besoins. Devrions-nous envisager de migrer vers WinUI 3 ou un autre framework ?

Si WinForms répond à vos besoins et que votre équipe est à l’aise avec elle, vous pouvez continuer à utiliser WinForms pour les applications existantes. WinForms est un framework mature et stable largement utilisé pour Windows développement de bureau.

L’équipe WinForms continue d’investir dans la plateforme. Les travaux récents et continus incluent :

  • API de formulaire et de boîte de dialogue asynchrones
  • Prise en charge du mode sombre et du style visuel
  • Améliorations de l’accessibilité, de la haute résolution, de la disposition et du concepteur
  • Presse-papiers et DataObject modernisation

Développement natif multiplateforme

Voici quelques raisons de créer des applications natives multiplateformes qui ciblent Windows ?

Si vous ciblez des utilisateurs sur plusieurs plateformes de système d'exploitation, la création d'applications multiplateformes avec .NET MAUI ou React Native peut offrir plusieurs avantages :

  • Atteindre: Les applications multiplateformes atteignent un public plus large sur différents appareils et systèmes d’exploitation.
  • Réutilisation du code : La réutilisation du code sur plusieurs plateformes réduit le temps de développement et le coût. La création d’applications distinctes pour Windows, Android, iOS et macOS peut être très coûteuse.
  • Expérience utilisateur cohérente : Les infrastructures multiplateformes permettent de fournir une apparence cohérente entre les plateformes.
  • Intégration: Les applications multiplateformes peuvent toujours s’intégrer à des services spécifiques à la plateforme pour offrir une expérience complète.
Can je suis certain que les applications .NET MAUI s’exécuteront correctement sur Windows ?

Lorsque vous générez une application .NET MAUI pour Windows, la sortie utilise WinUI 3. Pendant le développement, .NET MAUI offre une expérience de .NET unique sur plusieurs plateformes, mais elle génère du code spécifique à la plateforme sous le capot.

Comment .NET MAUI peut-il fournir des API d’appareil natives sur chaque plateforme ?

.NET MAUI offre une expérience de .NET unifiée dans Windows, iOS, Android et macOS. Il offre des API multiplateformes pour des fonctionnalités courantes telles que le stockage, la mise en réseau et les capteurs d’appareils. Vous pouvez également appeler des API spécifiques à la plateforme ou fournir des implémentations spécialisées pour chaque plateforme.

Puis-je commencer avec WinUI 3 et intégrer ultérieurement .NET MAUI si je souhaite éventuellement cibler des scénarios multiplateformes ?

Pas à ce moment-là. Bien que .NET MAUI utilise WinUI 3 lors de l’exécution sur Windows, les équipes qui s’attendent à cibler plusieurs plateformes doivent commencer par .NET MAUI ou React Native for Desktop.

Notre équipe possède de solides compétences en développement web front-end. Devrions-nous envisager d’utiliser React Native for Desktop ?

Teams disposant d’une expérience de développement web forte peut prendre en compte React Native for Desktop. Il inclut React Native pour Windows et macOS. Avec l’approche « Learn once, write anywhere », les compétences JavaScript, TypeScript et React existantes peuvent être utilisées pour créer des applications natives Windows et macOS.

React Native for Desktop restitue directement l’interface utilisateur aux primitives natives, offrant des performances et des fonctionnalités de plateforme natives.

Consultez la documentation React Native for Desktop pour commencer.

Y a-t-il d'autres appareils Windows pris en charge par React Native for Desktop ?

React Native pour Windows prend en charge les versions Windows répertoriées dans sa documentation de compatibilité. Vérifiez la prise en charge de la famille d’appareils pour React Native pour Windows version que vous ciblez plutôt que de supposer que chaque appareil Windows est pris en charge.

Que dois-je utiliser si je souhaite créer des applications qui fonctionnent sur Windows et Xbox ?

Pour une application Xbox, utilisez UWP et tenez compte des limitations UWP spécifiques à Xbox. Pour le développement de jeux, utilisez le Trousse de développement de jeux Microsoft.

Que dois-je utiliser si je souhaite créer des applications qui fonctionnent sur Windows et Surface Hub ?

Pour un Surface Hub exécutant les salles Teams standard ou l’environnement hub Surface, utilisez une application UWP qui répond aux exigences de l’application Surface Hub. Un Surface Hub 3 configuré avec Windows 11 Pro ou Enterprise peut exécuter des technologies d'application de bureau prises en charge. UWP n'est donc pas la seule option de cette configuration.

Développement hybride et web

Qu’est-ce que les applications hybrides et pourquoi dois-je envisager de en créer une ?

Les applications hybrides combinent le meilleur du développement d’applications web et natives. Leur architecture centrale est créée à l’aide de technologies web telles que HTML, CSS et JavaScript, et encapsulé dans un conteneur natif qui donne accès à certaines fonctionnalités et au matériel de plateforme natif. Ils peuvent également être distribués via les magasins d’applications.

L’avantage principal est que les applications hybrides vous permettent de créer une application unique qui peut s’exécuter sur plusieurs plateformes natives et sur le web, ce qui réduit le temps de développement et le coût. Voici quelques exemples de plateformes de développement d’applications hybrides :

  • Electron pour les applications de bureau
  • Ionic pour les applications mobiles
  • .NET MAUI Blazor Hybrid pour les applications multiplateformes
Comment créer des applications web progressives semblables à des applications natives sur Windows ?

Consultez Développement web sous Windows et Vue d’ensemble des applications web progressives.

Qu’est-ce qu’une application hybride .NET MAUI Blazor ?

Avec .NET MAUI, les applications Blazor peuvent s’exécuter en mode natif sur Windows, iOS, Android et macOS. Cela vous permet de créer des applications clientes hybrides qui combinent Blazor et .NET MAUI composants dans une application cliente native unique, avec un accès total aux fonctionnalités de plateforme native.

En savoir plus sur ASP.NET Core Blazor Hybrid.

Les composants web d'une application hybride .NET MAUI doivent-ils être créés avec Blazor ?

Non. À compter de .NET 9, .NET MAUI inclut un contrôle HybridWebView qui permet d’héberger d’autres interfaces utilisateur JavaScript à l’intérieur d’une application native.

Cela vous permet d’héberger Angular, React, Vue ou d’autres applications HTML/JavaScript à l’intérieur d’une application .NET MAUI. Le contrôle hybride fournit une interopérabilité entre C# et JavaScript, afin que le code C# puisse appeler des fonctions JavaScript et vice versa.

Les autres types d’applications natifs peuvent-ils héberger des composants hybrides Blazor ?

Yes. WPF et les applications WinForms peuvent également héberger des composants hybrides Blazor, ce qui permet d’ajouter l’interface utilisateur web moderne aux applications existantes. Cela n’est pas pris en charge pour les applications WPF ou WinForms basées sur .NET Framework.

Mon application entière doit-elle être une application hybride, ou puis-je combiner et faire correspondre des composants natifs et hybrides ?

Les composants natifs et hybrides peuvent être mélangés dans une application. Par exemple, le cœur d’une application peut être généré avec des composants .NET MAUI tandis que les composants hybrides fournissent des fonctionnalités supplémentaires. Cela permet de combiner les performances et les fonctionnalités des composants natifs avec la flexibilité et l’efficacité des coûts des composants hybrides.

Quelles sont mes options pour créer des applications web basées sur des .NET qui semblent intéressantes sur les navigateurs modernes sur Windows ?

Web apps offre la plus grande portée de n’importe quelle plateforme d’application cliente. Les options de création d’applications web .NET belles sont les suivantes :

  • applications ASP.NET Core avec Razor Pages
  • Applications ASP.NET Core MVC
  • Applications Blazor ASP.NET Core, avec des options de modèle d’hébergement :
    • WebAssembly Blazor
    • Serveur Blazor

Les modèles d’hébergement Blazor peuvent désormais être configurés au niveau du composant, ce qui permet d’activer des scénarios comme l’hébergement d’un composant Blazor WebAssembly dans une application Blazor Server.

Pour plus d’informations, consultez la documentation ASP.NET Core.

Choisir une approche et comprendre les investissements de Microsoft

Il y a tellement d'options de cadre pour la création d'applications qui ciblent Windows ! Comment décider ?

Windows est une plateforme ouverte qui prend en charge de nombreuses technologies. Voici quelques critères qui peuvent vous aider à choisir une plateforme :

  • Concentrez-vous sur Windows en premier ou sur le multiplateforme ?
  • Quels langages ou compétences avez-vous déjà : .NET, JavaScript, autre chose ?
  • Avez-vous besoin d’accéder aux API spécifiques à Windows ?
  • Quelles fonctionnalités de l’infrastructure correspondent le mieux aux exigences de votre application ?
  • Consultez ce tableau pour connaître les facteurs de comparaison supplémentaires.

Pour de nombreuses applications métier, les équipes choisissent souvent en fonction des compétences existantes et de ce que l’équipe est la plus à l’aise à utiliser.

Comment choisir la meilleure approche de développement pour mon appli web ?

Tenez compte des éléments suivants lors du choix d’une approche de développement pour votre application web :

  • Blazor est recommandé pour créer des applications web frontales avec .NET. Il vous permet de créer à la fois le serveur frontal et le back-end à l’aide de .NET, d’économiser du temps et des coûts, et c’est particulièrement utile pour les applications d’entreprise.
  • Les applications web en JavaScript restent pertinentes si vous souhaitez utiliser vos compétences en JavaScript existantes ou avez besoin d’intégrer des bibliothèques ou des frameworks JavaScript établis.
  • Les applications existantes utilisant des infrastructures plus anciennes telles que Web Forms, MVC ou Razor Pages restent prises en charge et peuvent continuer à être développées et gérées.
Qui crée des applications avec WinUI 3 aujourd’hui ?

Microsoft Photos est un exemple documenté. L’application a migré de UWP vers le SDK d'application Windows et continue à utiliser WinUI 3. Pour plus d’informations sur l’architecture et la migration, consultez Microsoft Photos : Migration d’UWP vers SDK d'application Windows.

Who crée aujourd’hui des applications .NET MAUI ?

Les organisations utilisent .NET MAUI pour créer des applications multiplateformes pour Android, iOS, macOS et Windows. Consultez des exemples dans la vitrine clients .NET.

Who crée des applications WPF aujourd’hui ?

La plupart de l’interface utilisateur Microsoft Visual Studio est générée avec WPF. L’IDE Visual Studio lui-même est un exemple majeur d’une application WPF hautes performances complexe.

Qui crée des applications Blazor aujourd’hui ?

GE Digital FlightPulse système aérien utilise Blazor pour la configuration du backend de tout ce que voient les pilotes, fournissant directement des données de capteurs et des analyses aux pilotes pour améliorer la sécurité et l'efficacité.

Consultez davantage de histoires de clients Blazor sur le site .NET.

Choix de langue (.NET vs C++)

Dois-je utiliser C# ou C++ pour mon application Windows ?

Utilisez C# (.NET) dans la plupart des cas. C# offre un développement plus rapide, la sécurité de la mémoire, les bibliothèques riches et d’excellents outils. La plupart des applications Windows ( y compris WinUI 3, WPF, WinForms et .NET MAUI applications ) sont les mieux conçues avec C#.

Utilisez C++ lorsque vous avez besoin d’un accès matériel direct, d’une surcharge minimale du runtime ou d’interopérabilité avec des bases de code C++ existantes. Les scénarios C++ courants incluent les moteurs de jeu (DirectX), les pilotes, les utilitaires au niveau du système et les composants critiques en matière de performances.

Facteur C# (.NET) C++
Vitesse de développement ✅ Plus rapide : mémoire managée, écosystème riche ⚠️ Plus lent — gestion manuelle des ressources
Performances du runtime ✅Excellent avec des .NET modernes (AOT, Span<T>) Meilleure valeur ✅ possible : aucune pause GC
Sécurité de la mémoire ✅ récupéré par le garbage collector ⚠️ Manuel : risque de fuites et de vulnérabilités
accès à l’API Windows ✅ Par le biais de la projection C#/WinRT ✅ À l’aide de la projection C++/WinRT
Prise en charge de WinUI 3 ✅ Prise en charge complète ✅ Prise en charge complète via C++/WinRT
Multiplateforme ✅.NET s’exécute sur Windows, Linux, macOS ✅ Avec du code spécifique à la plateforme
Idéal pour Applications métier, CRUD, services, applications lourdes d’interface utilisateur Jeux, pilotes, outils système, faible latence

Vous pouvez également combiner les deux : créer votre application en C# et appeler du code natif critique pour les performances via P/Invoke (CsWin32) ou un composant C++/WinRT.

Comment appeler des API Win32 à partir de C# ?

Utilisez CsWin32, un générateur source qui crée des signatures P/Invoke de type sécurisé au moment de la génération. Vous ajoutez le Microsoft.Windows.CsWin32 package NuGet, listez les API dont vous avez besoin dans un fichier NativeMethods.txt et les appelez via une classe PInvoke générée.

CsWin32 remplace les déclarations écrites [DllImport] manuellement et fonctionne dans n’importe quel projet C#, y compris WinUI 3, WPF, WinForms et les applications console. Consultez Appeler des API Win32 à partir d’une application Windows en C# (CsWin32) pour un guide pas à pas.

Qu’est-ce que C++/WinRT et quand dois-je l’utiliser ?

C++/WinRT est une projection de langage C++17 standard pour les API Windows Runtime. Utilisez-le lors de la création d’applications Windows en C++ qui consomment ou créent des API WinRT. Il remplace C++/CX et la Windows Runtime bibliothèque de modèles C++ (WRL).

Choisissez C++/WinRT quand :

  • Vous créez une application WinUI 3 C++
  • Vous devez créer des composants Windows Runtime consommés par d’autres langages
  • Vous effectuez le portage à partir de C++/CX
Qu’est-ce que C#/WinRT et quand ai-je besoin ?

C#/WinRT fournit la prise en charge des projections WinRT pour C#. Dans la plupart des cas, vous n’interagissez pas directement avec elles — les applications .NET ciblant Windows ont automatiquement accès aux API WinRT via les identifiants de framework cible (TFM). Vous avez besoin de C#/WinRT explicitement lors de la création de composants Windows Runtime en C# ou lors de la génération d’assemblys d’interopérabilité pour les composants WinRT tiers.

Empaquetage, déploiement et mises à jour

Quelle est la différence entre les applications empaquetées, non empaquetées et empaquetées avec un emplacement externe ?

Une application empaquetée contient ses fichiers, son identité et ses informations de déploiement dans un package tel que MSIX. Une application non empaquetée utilise un programme d'installation ou un processus de déploiement en dehors du système de package Windows et n'a pas d'identité de package par défaut. Une application empaquetée avec un emplacement externe utilise un petit package d’identité tout en conservant les fichiers binaires situés en externe et son programme d’installation et son processus de mise à jour existants.

Consultez la vue d’ensemble des emballages pour connaître les exigences et les compromis.

Ai-je besoin d’une identité de package ?

Cela dépend des fonctionnalités Windows que votre application utilise. L’identité de package est requise pour les scénarios tels que les tâches en arrière-plan empaquetées, les cibles de partage, les tâches de démarrage, les extensions de package de menu contextuel personnalisées, les associations de type de fichier et de protocole basées sur un manifeste et de nombreuses API IA Windows. Les notifications push du SDK d’application Windows prennent en charge des scénarios limités au premier plan sans identité, mais la distribution en arrière-plan et l’activation COM requièrent une identité. Les notifications d’application WinUI 3 et locales peuvent fonctionner sans identité de package.

Consultez Fonctionnalités nécessitant une identité de package. Si vous avez besoin d’une identité, mais que vous devez conserver un programme d’installation existant, envisagez le package avec un emplacement externe.

Quelle est la différence entre le déploiement dépendant de l’infrastructure et le déploiement autonome ?

Une application dépendante du framework utilise les packages d’exécution du runtime SDK d'application Windows installés séparément sur le périphérique. Cela réduit la taille de déploiement de l’application et permet à l’infrastructure installée de recevoir les mises à jour de maintenance. Une application autonome porte ses dépendances SDK d'application Windows avec elle, ce qui augmente la taille du déploiement et rend l’éditeur d’application responsable de la distribution des mises à jour de maintenance SDK d'application Windows avec les nouvelles versions d’application.

Les API qui dépendent de packages MSIX supplémentaires, tels que le package Singleton, peuvent nécessiter des vérifications de prise en charge distinctes du déploiement ou du runtime, même dans une application autonome. L’empaquetage et le déploiement à l’exécution sont deux décisions distinctes. Consultez Vue d’ensemble du déploiement du SDK d’application Windows.

Mon application WinUI 3 sera-t-elle automatiquement mise à jour pour les utilisateurs finaux ?

Une application WinUI 3 peut être fournie par le biais de l’Microsoft Store, d’un .appinstaller fichier ou d’un exécutable MSI ou d’installation. Les packages du Microsoft Store peuvent être mis à jour via la maintenance de Microsoft Store, sous réserve des paramètres du Store et de l’organisation. Un déploiement .appinstaller prend en charge les mises à jour automatiques uniquement lorsque son UpdateSettings configure des vérifications au lancement ou en arrière-plan. Les packages MSI et les programmes d’installation doivent fournir ou intégrer leur propre mécanisme de mise à jour.

Can J’utilise SDK d'application Windows sans utiliser MSBuild ?

Oui, pour certains scénarios. Les projets XAML WinUI 3 nécessitent actuellement MSBuild, même si Visual Studio n'est pas obligatoire et dotnet build peut appeler MSBuild à partir de la ligne de commande. Vous pouvez utiliser des API SDK d'application Windows non XAML dans des projets C++ et CMake via la version préliminaire de application Windows Development CLI, ou intégrer manuellement l’environnement d’exécution.

Intelligence Artificielle de Windows

Comment choisir entre Windows API IA, Foundry Local et Windows ML ?

Les trois premières technologies font partie de Microsoft Foundry sur Windows. Vous pouvez les combiner entre elles et avec des modèles cloud dans la même application :

  • Utilisez Windows API IA pour des fonctionnalités prêtes à l’emploi dont les modèles et l’accélération matérielle Windows gèrent.
  • Utilisez Foundry Local pour découvrir, télécharger et exécuter des modèles de reconnaissance vocale et de langage open source pris en charge localement.
  • Utilisez Windows ML pour exécuter vos propres modèles ONNX avec des fournisseurs d’exécution pour le matériel processeur, GPU et NPU disponibles.
  • Utilisez Microsoft Foundry, une plateforme IA cloud distincte, quand vous avez besoin de modèles hébergés dans le cloud, de récupération, de gouvernance centralisée ou de fonctionnalités qui ne sont pas disponibles sur l'appareil cible.

Comparez les options dans Choisir votre solution IA Windows. Tenez compte de la fonctionnalité de modèle, de la confidentialité, de la connectivité, de la latence, de la couverture matérielle, de la taille du déploiement et du coût d’exploitation.

Les fonctionnalités d’IA Windows nécessitent-elles une Copilot+ PC ?

Pas tous. De nombreuses API d’IA Windows nécessitent un Copilot+ PC, mais certaines API prennent également en charge des GPU ou des PROCESSEURs spécifiques. Foundry Local et Windows ML prennent en charge des configurations matérielles plus larges, soumises à leurs exigences actuelles en matière de système d’exploitation, de modèle, d’exécution et de fournisseur d’exécution.

Vérifiez la table matérielle de l’API IA Windows et la configuration requise pour l’API ou le modèle spécifique. Détectez la prise en charge et la préparation du modèle au moment de l’exécution et fournissez un modèle non-IA, un modèle local ou un secours cloud lorsque la fonctionnalité n’est pas disponible.

Les fonctionnalités d’IA de Windows peuvent-elles fonctionner localement et hors connexion ?

Yes. Windows API IA, Foundry Local et Windows ML peuvent exécuter l'inférence sur l'appareil de l'utilisateur, ce qui peut réduire la latence et conserver les données d'entrée locales. Certains modèles ou fournisseurs d’exécution doivent d’abord être téléchargés ou approvisionnés et peuvent nécessiter une connexion Internet pendant l’installation ou la maintenance. Les services IA cloud nécessitent une connectivité et envoient des données au service en fonction de ses conditions de gestion des données.

Indiquez aux utilisateurs quand un téléchargement de modèle est requis et quand les données quittent l’appareil. Ne décrivez pas une fonctionnalité en mode hors connexion tant que vous n’avez pas testé son expérience complète de première exécution, de mise à jour et de secours.

Les outils IA peuvent-ils m’aider à créer ou moderniser une application Windows ?

Yes. Les agents de codage IA peuvent aider à générer des projets, à expliquer les API, à migrer du code, à générer des tests et à diagnostiquer les problèmes de génération. Utilisez les instructions de développement Windows assistées par l’IA pour GitHub Copilot, le plug-in de l’agent WinUI, le Microsoft Learn MCP Server, les flux de travail de migration et les tests assistés par l’IA.

Passez en revue et testez le code généré comme vous le feriez pour toute autre contribution. En particulier, vérifiez les noms et versions de l’API, les fonctionnalités de package, le code sensible à la sécurité, l’accessibilité et toutes les substitutions UWP-to-WinUI 3.

Que dois-je prendre en compte avant d’envoyer une fonctionnalité assistée par l’IA ?

Définissez l’utilisation et les limitations prévues de la fonctionnalité, évaluez la qualité et la sécurité avec des données représentatives, divulguez le comportement de l’IA le cas échéant, protégez les données utilisateur et fournissez un secours lorsque le modèle ou le matériel requis n’est pas disponible. Conservez les secrets et les informations d’identification de service privilégiés hors des applications clientes et exigez la confirmation de l’utilisateur avant les actions consécutives ou irréversibles. Consultez le développement d’IA générative responsable sur Windows et la sécurité et l’IA responsable pour le développement Windows.

Niveau de performance et optimisation

Qu’est-ce que je peux faire pour rendre mon application Windows très agréable pour les utilisateurs finaux ?

Consultez Windows développement d’applications - Meilleures pratiques et Windows vue d’ensemble des performances et des principes de base des applications.

Compatibilité

Mes utilisateurs devront-ils mettre à jour Windows pour utiliser mon application WinUI 3 ?

Le SDK d'application Windows dispose d’un système d’exploitation compatible minimal de Windows 10, version 1809, build 17763. Le support Microsoft exige une version prise en charge du SDK d'application Windows avec sa dernière mise à jour de maintenance, ainsi qu’une édition, une version et un canal de maintenance de Windows encore pris en charge. Les API individuelles peuvent nécessiter une version plus récente Windows ou un matériel spécifique. Consultez la prise en charge de SDK d'application Windows et les canaux de publication.

Puis-je cibler Arm64 avec mon application WinUI 3 ?

Yes. Créez une application Arm64 native pour optimiser les performances et l’efficacité. Pour une base de code C++ volumineuse avec des dépendances x64, Arm64EC vous permet de migrer des modules de manière incrémentielle. Windows 11 sur Arm peut également exécuter de nombreuses applications x86 et x64 existantes via l’émulation Prism, mais vous devez tester les performances et la compatibilité sur les appareils Arm représentatifs.

Désapprobations et migrations

UWP / WinUI pour UWP est-il déconseillé ?

UWP et WinUI 2 ne sont pas officiellement déconseillés. Visual Studio 2026 prend en charge UWP avec des .NET modernes et un AOT natif, tandis que WinUI 2.8 reste la dernière version stable de WinUI pour UWP. Toutefois, Microsoft recommande WinUI 3 et le SDK d'application Windows pour les nouvelles applications de bureau à usage général Windows.

La prise en charge de UWP pour les .NET modernes avec AOT natif est généralement disponible et est le type de projet UWP C# par défaut dans Visual Studio 2026. Le déplacement d’une application UWP existante de .NET Native vers un .NET moderne est une étape de modernisation distincte de la migration de son interface utilisateur vers WinUI 3. Consultez Moderniser votre application UWP avec .NET et native AOT.

Quand dois-je migrer une application UWP /WinUI pour UWP vers WinUI 3 ?

Les développeurs UWP ne doivent pas se sentir pressés de migrer s’ils sont satisfaits de UWP et de son ensemble de fonctionnalités : pour de nombreuses applications, le bon choix peut être de rester sur UWP.

Les applications qui souhaitent bénéficier de la dernière plateforme Windows et des investissements .NET doivent envisager de passer à WinUI 3 et au SDK d'application Windows. Consultez Migrate de UWP au SDK d'application Windows.

Quand ne dois-je *pas* migrer une application UWP + WinUI pour UWP vers WinUI 3 ?

Continuez à utiliser UWP lorsque votre appareil ou modèle d’application cible l’exige, comme les applications Xbox, les applications HoloLens 2D ou les applications pour l’environnement standard Surface Hub. Windows IoT Enterprise prend en charge les technologies d'application de bureau, y compris les SDK d'application Windows, de sorte qu'une cible IoT n'est pas par elle-même une raison d'utiliser UWP.

Est-ce que WPF est déconseillé ?

Non. WPF est pris en charge et continue de recevoir des améliorations de fonctionnalités, de performances, d’accessibilité et de style Fluent dans les .NET modernes. Il reste un bon choix pour les applications WPF existantes et pour les nouvelles applications dont les exigences conviennent WPF. Pour les nouvelles applications de bureau à usage général Windows, la recommandation principale de Microsoft est WinUI 3 avec le SDK d'application Windows. Consultez la feuille de route WPF sur GitHub.

WinForms est-il déconseillé ?

Non. WinForms est pris en charge et continue de recevoir des mises à jour de fonctionnalités. Consultez la feuille de route Windows Forms sur GitHub.

Le Windows Runtime (WinRT) est-il obsolète ?

Non. WinRT est une interface binaire d’application (ABI) qui permet l’interopérabilité entre plusieurs langages. WinRT est l’évolution de COM, et le SDK d'application Windows fournit la plupart de ses fonctionnalités par le biais d’API WinRT.

Notes de publication

Partout puis-je trouver des notes de publication pour SDK d'application Windows ?

Consultez les notes de publication SDK d'application Windows pour obtenir des versions stables, préliminaires et expérimentales. La page Nouveautés pour les développeurs Windows récapitule les dernières mises à jour Windows SDK, SDK d'application Windows, WinUI 3, outils et mises à jour de plateforme.

Contenu connexe

  • Last updated on