Comment choisir entre WinForms, WPF et WinUI - Tableau de décision pratique

Lorsqu’on développe une application de bureau Windows en C# / .NET, la question discrètement récurrente est de choisir entre WinForms, WPF et WinUI.

Ce qui est dangereux ici, c’est de choisir de façon floue, du type :

• WinUI, parce que c’est le plus récent
• WinForms, parce que c’est ce qu’on connaît le mieux
• WPF, parce que ça semble être un entre-deux

En pratique, les axes à examiner sont un peu plus précis.

• S’agit-il d’un nouveau développement, ou du prolongement d’actifs existants ?
• Les écrans sont-ils centrés sur des formulaires de saisie, ou ont-ils besoin d’expressivité ?
• Une UI moderne et typiquement Windows est-elle la valeur même du produit ?
• Comment gérer la distribution, les mises à jour et l’exploitation en entreprise ?
• L’équipe a-t-elle une culture Designer, ou une culture XAML / MVVM ?

Dans cet article, nous organisons tout cela dans un tableau de décision unique et facile à parcourir. Notons que, dans cet article, WinUI désigne principalement WinUI 3 + le Windows App SDK. ¹²

Par ailleurs, ces trois technologies sont toutes exclusivement Windows. Si macOS / Linux entre également en ligne de compte, le problème posé est fondamentalement différent. ³⁴¹

1. D’abord, la conclusion (en une phrase)

Pour commencer de façon assez brute, mais utile en pratique, voici l’idée :

• Si l’application WinForms existante est importante, on regarde d’abord continuer sur WinForms
• Si l’application WPF existante est importante, on regarde d’abord continuer sur WPF
• Pour un nouvel outil interne de petite à moyenne taille, centré sur des contrôles standards et des écrans de saisie, que l’on veut construire vite, WinForms reste encore très solide ³⁵
• Pour une nouvelle application métier de taille moyenne à grande, avec de nombreux écrans, où l’on veut vraiment utiliser la liaison de données, les styles, les templates, les commandes et le MVVM, WPF est le plus souvent le choix le plus sûr ⁴⁶⁷
• Pour un nouveau produit exclusivement Windows, où une UI Windows moderne, Fluent et l’expérience Windows la plus récente sont directement liées à la valeur du produit, WinUI est un candidat sérieux ¹²
• Si vous voulez simplement utiliser les API Windows les plus récentes, WinUI n’est pas indispensable. WPF / WinForms peuvent eux aussi intégrer des fonctionnalités du Windows App SDK ²⁸⁹¹⁰
• Choisir en partant du principe que « on pourra toujours glisser un peu de WinUI plus tard » est un peu dangereux. La migration par étapes est plus laborieuse qu’il n’y paraît ¹⁰¹¹

En résumé, cela revient à peu près à ceci :

1. Si les actifs existants sont importants, préserver d’abord cette lignée
2. Pour un nouveau développement, si l’on veut construire vite des formulaires standards : WinForms
3. Pour un nouveau développement, si c’est une application métier Windows destinée à grandir longtemps : WPF
4. Pour un nouveau développement, si une UI Windows moderne est elle-même une exigence : WinUI
5. Si l’on veut seulement le Windows App SDK, ne pas tout basculer d’un coup vers WinUI

Le choix du framework est un choix de technologie UI, mais c’est en même temps un choix de distribution, d’exploitation, de coût d’apprentissage et de coût de migration. Décider cela uniquement sur « nouveau / ancien » finit par se payer discrètement plus tard. Et de façon désagréable.

2. Les trois technologies dont il est question dans cet article

D’abord, alignons un peu le vocabulaire.

WinForms est décrit, y compris sur Microsoft Learn, comme un framework doté de contrôles, de graphismes, de liaison de données et de saisie utilisateur, qui facilite la création d’applications grâce au Designer glisser-déposer de Visual Studio. ³

WPF est un framework UI très expressif qui inclut le rendu vectoriel indépendant de la résolution, XAML, la liaison de données, les styles / templates, la 2D / 3D, et même l’animation. ⁴

WinUI fait partie du Windows App SDK : c’est le framework UI d’aujourd’hui pour Windows, pensé pour le haut DPI, une saisie moderne, des animations fluides et une expérience de type Fluent. ¹² Il dispose également, tout à fait normalement, de chemins pour la liaison de données / le MVVM. ¹²

Ce qui compte ici, c’est que le Windows App SDK et WinUI ne sont pas la même chose. WinUI est la partie framework UI du Windows App SDK, mais le Windows App SDK lui-même peut aussi être ajouté à des applications WPF / WinForms / Win32 existantes. ²¹⁰

Donc :

• Utiliser WinUI
• Utiliser les fonctionnalités du Windows App SDK

sont des décisions qui se ressemblent, mais qui restent distinctes. Quand ces deux points se mélangent, la discussion en salle de réunion devient un peu brumeuse.

3. Le tableau de décision en un coup d’œil

Commençons par le tableau le plus utile en pratique.

Ce tableau suffit dans l’ensemble, mais deux points restent souvent sources d’hésitation.

1. Pour une nouvelle application métier Windows, faut-il pencher vers WinForms ou vers WPF ?
2. Alors qu’on a déjà du WPF / WinForms existant, faut-il aller vers WinUI ?

Ces deux points deviennent plus faciles à trancher en s’appuyant sur le tableau comparatif qui suit.

4. Tableau comparatif par critère

Ceci n’est pas un tableau officiel de supériorité, mais une comparaison très orientée vers la pratique.

L’astuce pour lire ce tableau n’est pas de chercher ce qui est le plus fort, mais ce qui génère le moins de friction.

Par exemple, si l’on a :

• Un outil interne de paramétrage
• Un écran de configuration d’équipement
• Des listes, des détails, une recherche, des paramètres, des boutons
• Un contexte où la stabilité opérationnelle et la vitesse de retouche comptent plus que l’apparence

alors WinForms reste tout à fait rationnel.

À l’inverse, si l’on a :

• De nombreux écrans
• Beaucoup de changements d’état d’affichage
• Le souhait de séparer la View de la logique
• Le souhait de connecter naturellement les changements de données à l’UI
• Le souhait de gouverner l’UI par des styles / templates

alors WPF est très efficace. ⁶⁷

Et si l’on a :

• Le souhait de partir d’une apparence typique de Windows 11
• Le souhait d’exploiter vraiment Fluent
• Le haut DPI, le tactile et les API de fenêtrage modernes comme prérequis
• Un nouveau produit exclusivement Windows où l’impression donnée par l’UI compte aussi

alors WinUI s’impose naturellement. ¹²

5. Pour quels types de projets chacun convient-il

5.1 WinForms

WinForms a tendance à être injustement sous-estimé, mais sur ce seul point — construire rapidement des écrans métier centrés sur des contrôles standards —, il reste aujourd’hui encore redoutable. ³⁵

Il convient particulièrement à des projets tels que :

• Des outils de paramétrage à usage interne
• Des écrans de configuration pour équipements, instruments de mesure, outils de surveillance
• Des écrans d’administration, des écrans de recherche, des listes + détails
• Des projets disposant d’actifs WinForms existants importants
• Des équipes ayant une culture forte de construction d’écrans via le Designer

La force de WinForms est de produire, sans avoir à importer de philosophie compliquée, des écrans assez proches du produit fini, et plutôt vite. Formulaires, boutons, étiquettes, zones de texte, grilles de données. Si ce monde-là est votre terrain de jeu principal, vous pouvez y être très efficace.

Ses faiblesses sont cependant tout aussi claires.

• Vouloir unifier fortement l’apparence de l’ensemble de l’application
• Vouloir contrôler l’UI par des styles et des templates
• Vouloir gérer des changements d’état complexes principalement par la liaison de données
• Vouloir séparer proprement la logique des écrans

Sur ces points, WPF et WinUI sont plus naturels.

Construire une grande application en WinForms, dès que l’on relâche l’attention, tend facilement à devenir une jungle de gestionnaires d’événements. Aussi, si l’on choisit WinForms, il est plus paisible de décider dès le départ, au minimum, de :

• Garder les responsabilités de chaque écran réduites
• Découper par UserControl
• Maintenir une frontière équivalente à un Presenter / ViewModel
• Ne pas écrire la logique métier directement dans les gestionnaires d’événements d’écran

Un autre point assez important en pratique : vouloir le Windows App SDK n’est pas une raison d’abandonner WinForms. Il existe un chemin officiel pour ajouter des fonctionnalités du Windows App SDK à une application WinForms existante. ⁹¹⁰

Autrement dit, avec WinForms, on peut choisir de :

• Garder l’UI telle quelle
• Moderniser uniquement les fonctionnalités Windows nécessaires

C’est un compromis réaliste.

5.2 WPF

Vu comme l’UI .NET du bureau Windows, WPF est le noyau le mieux équilibré. ⁴

Ses forces sont claires.

• Les écrans peuvent être écrits de façon déclarative en XAML
• Le Data Binding est puissant
• Les Style / Template sont disponibles
• Les Command sont disponibles
• Facile de séparer la View de la logique
• Facile d’organiser un nombre d’écrans moyen à grand

La documentation officielle de WPF décrit elle-même la liaison de données comme une fonctionnalité centrale de WPF, et les commandes comme un mécanisme qui sépare la saisie de la logique d’exécution. ⁶⁷

Il convient donc à des projets tels que :

• Des applications métier avec de nombreux écrans
• De nombreuses listes, détails, éditions, recherches, affichages d’état
• Des applications Windows maintenues sur le long terme par plusieurs personnes
• Le souhait de séparer la View de la logique
• Le souhait de séparer, en vue de futures retouches, les responsabilités d’apparence et de comportement
• Des écrans qui deviendraient vite lourds avec WinForms

Quand on hésite pour une nouvelle application métier exclusivement Windows, WPF reste aujourd’hui encore le premier candidat sûr. L’écarter en disant « WPF est vieux, donc non » est un peu brutal.

Au contraire, si l’on a :

• Des actifs WPF existants
• Une expertise XAML / MVVM déjà en place
• Fluent qui n’est pas la priorité absolue
• Mais le souhait de concevoir une UI plus propre qu’avec WinForms

il est tout à fait courant que WPF soit le choix le plus judicieux.

Bien sûr, WPF a lui aussi ses particularités.

• Un XAML trop travaillé devient difficile à lire
• Tomber dans l’enfer des contrôles personnalisés et des templates alourdit la maintenance
• Se rapprocher de la religion du « tout faire par Binding » peut au contraire rendre les choses difficiles à suivre

Ces travers existent bien, mais ce n’est pas tant que WPF soit mauvais : un outil expressif, manié sans soin, produit un contrecoup à la mesure de son expressivité.

Sur WPF aussi, on peut ajouter certaines fonctionnalités du Windows App SDK. Autrement dit, il existe une voie pour moderniser les fonctionnalités Windows tout en restant sur WPF. ⁸¹⁰

C’est pourquoi, plutôt que :

• Abandonner tout WPF pour une migration complète vers WinUI

l’approche consistant à :

• Rapprocher WPF du .NET actuel
• N’ajouter que les fonctionnalités Windows nécessaires via le Windows App SDK
• Réorganiser l’architecture en commençant par les nouvelles fonctionnalités importantes

l’emporte plus souvent en pratique.

5.3 WinUI

WinUI est le candidat moderne de choix pour créer une nouvelle application exclusivement Windows. ¹²

Officiellement, il est positionné comme :

• Optimisé pour le matériel et la saisie les plus récents
• Haut DPI
• Animations fluides
• Une partie du Windows App SDK

¹

Il convient donc à des projets tels que :

• Un nouveau produit exclusivement Windows
• Où l’impression et l’expérience de l’UI comptent en elles-mêmes
• Le souhait d’utiliser Fluent de façon naturelle
• Le souhait de se rapprocher de l’état actuel de Windows 11
• Le souhait de partir des nouvelles API de fenêtrage et de l’expérience Windows la plus récente

Les projets qui ont une véritable raison de choisir WinUI sont généralement non pas des projets où « l’apparence est nouvelle », mais des projets où l’on veut intégrer au produit l’expérience Windows d’aujourd’hui.

Cela dit, il y a aussi des points de vigilance.

5.3.1 WinUI n’est pas « juste un WPF plus récent »

Comme il utilise XAML, il semble proche, mais les points suivants diffèrent :

• Les API de base
• L’univers des contrôles
• La structure de projet
• La manière de penser le déploiement / packaging
• La façon de composer avec le Windows App SDK

Autrement dit, le considérer comme un remplacement facile de WPF est un peu dangereux.

5.3.2 Choisir WinUI met la question de la distribution au premier plan

Les applications WinUI 3 sont packaged par défaut. Le Windows App SDK lui-même, en revanche, gère à la fois le packaged et l’unpackaged. ¹³¹⁴²

Ce qui compte ici, c’est de décider tôt :

• Comment allez-vous distribuer l’application ?
• Comment allez-vous installer le runtime ?
• Une package identity est-elle nécessaire ?
• Distribution interne, Store, MSIX, ou la voie classique EXE / MSI ?

La distribution compte aussi pour WinForms / WPF, mais avec WinUI, ce sujet passe plus facilement au premier plan. On croit avoir choisi une UI, et l’on s’aperçoit qu’on avait en réalité choisi une stratégie de distribution — c’est ce qui rend ce monde un peu tordu.

5.3.3 « Mélanger progressivement WinUI dans du WPF / WinForms existant » : à expérimenter d’abord

C’est un point où les attentes ont tendance à gonfler. Mais la FAQ de Microsoft indique elle-même, en substance, que WinUI est souvent inutilisable tant qu’on n’est pas prêt à migrer complètement le framework UI. De plus, concernant XAML Islands, si la documentation officielle présente bien un chemin d’intégration dans des applications de bureau existantes, les notes de version du Windows App SDK 1.4 précisent qu’à l’heure actuelle, l’usage a surtout été testé dans des applications C++, et qu’aucun élément wrapper pratique pour WPF / WinForms n’est inclus. ¹⁰¹¹

Autrement dit :

• « La migration par étapes semble faisable »
• « On pourrait combler petit à petit »

sont des idées séduisantes sur le principe, mais qu’il vaut mieux valider à petite échelle avant d’en faire la stratégie principale d’un projet.

WinUI est le plus judicieux quand on :

• Part de zéro
• Construit l’expérience d’un produit exclusivement Windows

À l’inverse, en tant que destination pour un remplacement complet d’un WPF / WinForms existant, il lui faut une raison et une vérification.

6. Erreurs de décision courantes

6.1 « WinUI, parce que c’est le plus récent »

C’est facile à comprendre, et assez dangereux.

La raison de choisir une nouvelle technologie devrait plutôt être examinée sous l’angle de : existe-t-il une valeur qu’on ne peut obtenir qu’avec cette technologie ?

• L’expérience Windows moderne est-elle la valeur du produit ?
• Voulez-vous utiliser Fluent de façon naturelle ?
• S’agit-il d’un nouveau produit ?
• Pouvez-vous accepter les prérequis de distribution / d’exploitation ?

Si la réponse est oui sur ces points, WinUI est un candidat sérieux. À l’inverse, se contenter de « ça semble avoir de l’avenir » rend la justification du coût fragile.

6.2 « Je veux utiliser le Windows App SDK, donc je dois passer à WinUI »

C’est un malentendu fréquent, et c’est faux.

Le Windows App SDK peut aussi être ajouté à du WPF / WinForms existant. La FAQ officielle précise elle-même que les applications WPF / MFC / WinForms peuvent utiliser des API du Windows App SDK indépendantes de WinUI. ¹⁰⁸⁹

Par exemple, des fonctionnalités comme :

• App Lifecycle
• Windowing
• Toast Notifications

peuvent parfois être intégrées tout en conservant l’UI actuelle. ¹⁰

6.3 « WPF / WinForms, c’est déjà terminé »

Là aussi, mieux vaut ne pas trancher trop vite.

WinForms comme WPF continuent de bénéficier d’une documentation et de chemins de migration sur le .NET actuel, et sont officiellement traités comme des UI de bureau Windows toujours actives. ³⁴

En particulier pour les applications métier, les éléments suivants pèsent souvent plus lourd que la nouveauté du framework UI :

• Les actifs existants
• Les contrôles tiers
• Le nombre d’écrans
• Les états et l’impression
• L’intégration avec des équipements
• Les procédures de distribution

6.4 « Autant tout réécrire »

Une réécriture complète est plus proche d’une décision d’entreprise que d’un choix technologique.

S’il existe une application existante, ce qu’il faut examiner en premier est plutôt ceci :

1. Qu’est-ce qui pose vraiment problème ?
2. Est-ce un problème d’UI, ou un problème d’architecture ?
3. Les DLL dépendantes / COM / OCX / les états / la distribution ne sont-ils pas le véritable fardeau ?
4. Le problème peut-il être résolu sans changer toute l’UI ?

Une réécriture d’UI est spectaculaire, mais son coût l’est tout autant. Et même avec une nouvelle apparence, la complexité environnante reste généralement présente.

6.5 « XAML Islands arrangera les choses plus tard »

Cet espoir est compréhensible. Mais il est plus sûr de ne pas le traiter comme un canot de sauvetage dès le départ. ¹⁰¹¹

Pour une migration par étapes, mieux vaut d’abord tester à petite échelle :

• Quels contrôles souhaite-t-on intégrer ?
• Que deviennent le focus, la saisie, le DPI, le thème ?
• Cette configuration d’hébergement reste-t-elle réellement stable en pratique ?

7. Comment voir les choses quand on part d’une application existante

Ce chapitre compte davantage pour l’existant que pour le neuf.

7.1 Si vous avez du WinForms existant

Avant de sauter directement vers WinUI, vérifiez d’abord ceci :

• Peut-on se rapprocher du .NET actuel ?
• Une migration vers le 64 bits est-elle nécessaire ?
• Peut-on nettoyer async / await, la gestion des exceptions, les paramètres, la journalisation ?
• Peut-on améliorer la maintenabilité en découpant les écrans ou en extrayant des UserControl ?
• Peut-on ajouter uniquement les fonctionnalités Windows nécessaires via le Windows App SDK ?

Ce qui ressemble à un problème de WinForms n’est, en réalité, pas rarement, que :

• Les écrans et la logique sont mélangés
• Les frontières entre threads sont négligées
• Les responsabilités de paramètres / fichiers / COM / base de données sont entassées

Dans ce cas, déménager vers WinUI ne fait que renommer le problème tout en le conservant.

7.2 Si vous avez du WPF existant

WPF facilite l’exploitation des actifs existants.

• Les actifs XAML
• Le Binding
• Style / Template
• Command
• MVVM

La raison d’abandonner tout cela doit être assez explicite.

Par exemple :

• Vouloir refondre entièrement l’UI du produit
• Vouloir faire de Fluent l’axe principal
• Extraire un nouveau module en tant que produit séparé
• Vouloir se rapprocher d’une nouvelle expérience en tant que produit exclusivement Windows

sont des raisons valables d’envisager WinUI. Mais un simple « parce que WPF est vieux » est faible.

7.3 Ce qui pèse vraiment n’est souvent pas l’UI

En pratique, ce qui est pénible se trouve, de façon assez surprenante, souvent ici :

• ActiveX / OCX
• COM interop
• États personnalisés
• Impression
• Intégration Excel / Office
• DLL natives
• Les torsions entre 32 bits et 64 bits
• Installateur, permissions, mises à jour, signature

Prendre ces points à la légère fait que, même avec une UI embellie, le projet dans son ensemble ne devient pas plus léger.

Aussi, pour la migration d’une application existante, il vaut mieux commencer par faire l’inventaire de chaque frontière de dépendance, plutôt que de ne regarder que le framework UI.

8. Les cinq dernières questions à se poser en cas d’hésitation

Si vous hésitez encore à la fin, appliquez ces cinq questions dans l’ordre.

8.1 Les actifs existants sont-ils importants ?

• Importants → Conserver globalement la lignée existante
• Faibles / inexistants → Passer à une sélection pour un nouveau développement

8.2 Une « expérience Windows moderne et native » est-elle indispensable pour cette application ?

• Indispensable → WinUI est un candidat sérieux
• Pas vraiment → Vérifier si WPF / WinForms suffit

8.3 Les écrans sont-ils centrés sur des formulaires standards, ou faut-il l’expressivité propre à XAML ?

• Centrés sur des formulaires standards → WinForms
• Styles / templates / Binding / MVVM importants → WPF

8.4 Voulez-vous une refonte complète de l’UI, ou simplement l’ajout de fonctionnalités Windows ?

• Refonte complète de l’UI → Envisager WinUI
• Ajout de fonctionnalités seulement → Envisager d’abord le WPF / WinForms actuel + le Windows App SDK

8.5 Pouvez-vous expliquer à l’avance comment gérer la distribution / les mises à jour / l’exploitation ?

• Encore flou → Pour WinUI, régler tôt le packaging / le déploiement
• Vouloir s’appuyer fortement sur l’exploitation existante → WPF / WinForms génère souvent moins de friction

Ces cinq questions permettent de resserrer considérablement le choix. Pour résumer brièvement à la fin, cela donne à peu près ceci :

• Formulaires internes à construire vite → WinForms
• Application métier Windows destinée à grandir longtemps → WPF
• UI d’un nouveau produit Windows moderne → WinUI
• Exploiter l’existant tout en modernisant seulement les fonctionnalités Windows → Framework actuel + Windows App SDK

9. Conclusion

Le choix entre WinForms, WPF et WinUI n’est pas un jeu où l’on aligne les technologies par ordre de nouveauté et où l’on prend celle la plus à droite.

Ce qu’il faut d’abord examiner, ce sont ces quatre points.

1. Où se trouvent les actifs existants ?
2. Les écrans sont-ils centrés sur les formulaires, ou sur l’expressivité ?
3. Une UI moderne et typiquement Windows est-elle une exigence du produit ?
4. Comment faire tourner la distribution / les mises à jour / l’exploitation ?

Une fois ces quatre points clairs, l’orientation se décide presque d’elle-même.

• Si vous détenez un grand parc WinForms existant, continuer d’abord sur WinForms
• Si vous détenez un grand parc WPF existant, continuer d’abord sur WPF
• Nouveau développement centré sur des formulaires standards → WinForms
• Nouvelle application métier Windows de taille moyenne à grande → WPF
• Nouveau développement où l’expérience Windows moderne est elle-même l’exigence → WinUI
• Si l’on veut seulement le Windows App SDK, ne pas tout basculer d’un coup vers WinUI

Ce qu’il faut le plus éviter, ce sont ces trois choses :

• Abandonner parce que c’est vieux
• Choisir parce que c’est nouveau
• Commencer en se disant que ça s’arrangera en cours de route

Le bureau Windows est un monde où les actifs, la distribution, l’exploitation et les dépendances pèsent plus lourd que l’apparence. Aussi, en matière de choix, viser le moins de friction plutôt que l’effet brillant est, la plupart du temps, la façon de gagner.

10. Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Quelle est la différence entre WinUI 3 et WPF ?

Les deux utilisent XAML, mais WinUI n'est pas « juste un WPF plus récent ». Les API de base, l'univers des contrôles, la structure de projet, la manière de penser le déploiement / packaging et la façon de composer avec le Windows App SDK diffèrent. WPF est un framework UI pour applications métier de taille moyenne à grande, doté d'un rendu vectoriel indépendant de la résolution, de la liaison de données, de styles / templates et de commandes, tandis que WinUI, en tant que partie du Windows App SDK, est un framework UI moderne fondé sur Fluent, le haut DPI et l'expérience Windows la plus récente. Le considérer comme un remplacement facile de WPF est risqué.

Pour un nouveau développement, faut-il choisir WinForms, WPF ou WinUI ?

Cela dépend de la nature des écrans et des exigences du produit. Pour créer rapidement un outil interne de petite à moyenne taille, centré sur des contrôles standards et des formulaires de saisie, WinForms reste encore très solide. Pour une application métier de taille moyenne à grande, avec de nombreux écrans, où l'on veut vraiment utiliser la liaison de données, les styles, les templates et le MVVM, WPF est le plus souvent le choix le plus sûr. Pour un nouveau produit exclusivement Windows où Fluent et une expérience Windows moderne sont directement liés à la valeur du produit, WinUI est un candidat sérieux. Si vous avez des actifs existants importants, il faut d'abord envisager de rester sur cette lignée.

WPF et WinForms sont-ils déjà dépassés ?

Mieux vaut ne pas trancher trop vite. WinForms comme WPF continuent de bénéficier d'une documentation et de chemins de migration sur le .NET actuel, et sont officiellement traités comme des UI de bureau Windows toujours actives. En particulier pour les applications métier, les actifs existants, les contrôles tiers, le nombre d'écrans, les états et l'impression, l'intégration avec des équipements ou les procédures de distribution pèsent souvent plus lourd que la nouveauté du framework UI. Il n'est pas rare que, même pour un nouveau développement, WinForms ou WPF reste le choix générant le moins de friction.

Faut-il migrer vers WinUI pour utiliser les fonctionnalités Windows les plus récentes ?

Non. Le Windows App SDK et WinUI ne sont pas la même chose : WinUI est la partie framework UI du Windows App SDK. Le Windows App SDK lui-même peut être ajouté à des applications existantes en WPF / WinForms / Win32, et des fonctionnalités comme l'App Lifecycle, le Windowing ou les Toast Notifications peuvent parfois être adoptées tout en conservant l'UI actuelle. Autrement dit, il existe une voie permettant de moderniser uniquement les fonctionnalités Windows nécessaires tout en restant sur WPF / WinForms existant ; une migration complète de l'UI n'est pas obligatoire.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.