Mettre à niveau une application Windows Forms pour .NET avec la modernisation de GitHub Copilot

Cet article décrit la mise à niveau d’une application de bureau Windows Forms pour .NET à l’aide de l’agent de modernisation GitHub Copilot. L’agent s’exécute dans votre éditeur, analyse le projet et génère un flux de travail en trois étapes : évaluation, planification et exécution.

L’exemple s’appuie sur l’exemple de jeu d’association, une petite application Windows Forms .NET Framework qui se compose d’un projet principal et d’une bibliothèque de classes.

Prerequisites

• Windows système d’exploitation.
• Visual Studio 2026.
• Téléchargez et extrayez l’application de démonstration utilisée avec cet article.
• Kit de développement logiciel (SDK) .NET pour la version que vous ciblez. Cet article cible .NET 10.
• Référentiel Git pour la solution. L’agent valide sa progression, de sorte que le projet doit être sous contrôle de code source.
• Modernisation GitHub Copilot activée pour Visual Studio. Pour plus d’informations, consultez Installer GitHub Copilot modernisation.

Ouvrir la solution

Les projets de jeu correspondant ciblent .NET Framework 4.5. Visual Studio vous invite à recibler les projets vers une version prise en charge de .NET Framework lorsque vous ouvrez la solution.

1. Ouvrez la solution MatchingGame dans Visual Studio.
2. Visual Studio affiche la boîte de dialogue Infrastructure cible non installée.
3. Sélectionnez Mettre à jour la cible pour .NET Framework 4.8 (recommandé), puis sélectionnez Continuer.
4. Ouvrez la fenêtre Modifications Git et validez les modifications de reciblage.

Remarques importantes pour Visual Basic

L'agent de modernisation GitHub Copilot ne prend pas entièrement en charge les projets Visual Basic .NET. L’agent inclut des garde-fous spécialement conçus pour garantir la fiabilité de la mise à niveau des projets C#, et ces garde-fous interfèrent avec l’analyse et l’exécution des projets VB. Si votre solution contient des projets VB, utilisez l’une de ces alternatives à la place :

• GitHub Copilot (agent standard) : utilisez le assistant Copilot standard, sans l’agent de modernisation, pour guider la mise à niveau de manière interactive.
• Assistant de mise à niveau: Un outil de migration dédié avec prise en charge de VB.

Si vous utilisez l’agent Copilot standard ou effectuez la mise à niveau manuellement, suivez les étapes ci-dessous :

1. Si le projet cible une version non prise en charge de .NET Framework, reciblez-le pour .NET Framework 4.8 en premier. Visual Studio vous invite à le faire lorsque vous ouvrez la solution, ou vous pouvez la modifier dans les propriétés du projet.

2. Mettez à jour les packages NuGet obsolètes vers leurs dernières versions compatibles.

3. Créez un projet Windows Forms en VB à partir d’un modèle Visual Studio ou dotnet new winforms -lang vb. Le modèle produit un fichier de projet au format SDK et des paramètres qui diffèrent de ceux de .NET Framework.

4. Copiez vos .vb fichiers sources de l’ancien dossier de projet vers le nouveau dossier du projet.

5. Copiez tous les fichiers qui ne sont pas du code dont le projet dépend, tels que les fichiers app.config, .settings, les images, les icônes et les autres ressources intégrées.

6. Ouvrez l’ancien fichier projet (ou packages.config) et notez chaque référence de package NuGet. Ajoutez ces mêmes packages au nouveau projet à l’aide du Gestionnaire de package NuGet ou dotnet add package <name>.

7. Si le projet fait référence à d’autres projets dans la solution, ajoutez à nouveau ces références dans le nouveau projet.

8. Essayer de compiler la solution. Ne corrigez pas encore les erreurs : la sortie de build fournit Copilot une liste concrète de problèmes à partir de laquelle travailler.

9. Validez l’état actuel dans le contrôle de code source afin que vous ayez une ligne de base propre avant que Copilot apporte des modifications.

10. Ouvrez gitHub Copilot Chat et demandez-lui de résoudre les problèmes restants. Par exemple:

    Ce projet Visual Basic Windows Forms a été migré de .NET Framework 4.8 vers .NET 10. Le fichier projet et les fichiers sources sont en place, mais la solution ne se compile pas. Passez en revue les erreurs de build et corrigez les incompatibilités d’API, les références manquantes et tous les problèmes de migration de configuration.

11. Passez en revue les modifications que Copilot propose, puis recompilez et testez le projet.

Lancer la mise à niveau

La solution Matching Game contient l’application MatchingGame et la bibliothèque de classes MatchingGame.Logic. L’agent détermine le graphique de projet par lui-même, donc démarrez la mise à niveau au niveau de la solution.

1. Dans Explorateur de solutions, cliquez avec le bouton droit sur la solution, puis sélectionnez Moderniser.

   La fenêtre Copilot Chat GitHub s’ouvre et démarre une conversation avec l’agent de modernisation.

2. Sélectionnez un modèle avec des capacités de raisonnement et de codage fortes.

3. Indiquez à l’agent ce que vous voulez faire. Par exemple:

   Mettez à niveau tout vers .NET 10.

   L’agent signale l’état actuel du codebase et ce qu’il prévoit de faire :

   • Framework cible : indique que l’agent met à niveau les projets vers .NET 10.
   • Mode de flux : valeur par défaut automatique. Pour les applications complexes, demandez à l’agent de passer en mode guidé .
   • Contrôle de code source : indique que l’agent crée une branche de travail.

   L’agent écrit son travail dans .github/upgrades/scenarios/dotnet-version-upgrade/ dans votre référentiel. Si ce dossier existe déjà à partir d’une tentative antérieure, l’agent demande s’il faut continuer ou démarrer à nouveau.

4. Indiquez à l’agent start de commencer le processus de mise à niveau.

Passer en revue l’évaluation

Dans la phase d’évaluation, l’agent examine la structure, les dépendances et les modèles de code du projet pour identifier les besoins de modification. Il écrit les résultats vers assessment.md dans .github/upgrades/scenarios/dotnet-version-upgrade/.

Lorsque Copilot a terminé l’évaluation, examinez le résultat de la conversation. Il commence généralement par quelque chose de similaire à ce qui suit :

Assessment Complete

I've analyzed the solution and created a full assessment — see .github/upgrades/scenarios/dotnet-version-upgrade/assessment.md.

Solution summary:
• Target: net48 → net10.0
• Projects: 2
• MatchingGame.Logic (Class Library)
• MatchingGame (Windows Forms)
• Issues: 883 (673 mandatory, 210 potential)
• Affected Technologies: Windows Forms (666), GDI+ / System.Drawing (208), Legacy Configuration System (2)

Key concerns:
• Both projects are legacy-format .csproj files — need conversion to SDK-style
• MatchingGame.csproj has API incompatibilities (binary + source) and an incompatible NuGet package
• WinForms remains supported on .NET 10 (Windows-only TFM)
• No reported security vulnerabilities

Répartition de l’évaluation

Copilot ouvre le .github/upgrades/scenarios/dotnet-version-upgrade/assessment.md fichier dans l’éditeur Visual Studio. Faites défiler jusqu’à la MatchingGame\MatchingGame.csproj section pour afficher une table des problèmes :

Technologie	Problèmes	Pourcentage	Chemin de migration
Système de configuration hérité	2	0.2%	Système de configuration XML hérité (app.config/web.config) qui a été remplacé par un modèle de configuration plus flexible dans .NET Core. L’ancien système était rigide et basé sur XML. Migrez vers Microsoft. Extensions.Configuration avec des variables JSON/environnement ; utilisez le package NuGet System.ConfigurationManager comme pont intermédiaire si nécessaire.
GDI+ / System.Drawing	208	23.7%	API System.Drawing pour les graphiques 2D, l’imagerie et l’impression disponibles via le package NuGet System.Drawing.Common. Remarque : Non recommandé pour les environnements serveur en raison de dépendances à Windows ; envisagez des alternatives multiplateformes telles que SkiaSharp ou ImageSharp pour tout nouveau code.
Windows Forms	621	76.0%	Windows Forms API pour la création d’applications de bureau Windows avec l’interface utilisateur traditionnelle basée sur les formulaires qui sont disponibles dans .NET sur Windows. Activer la prise en charge de Windows Forms : Option 1 (recommandée) : Ciblez net10.0-windows ; Option 2 : Ajoutez <UseWindowsForms>true</UseWindowsForms> ; Option 3 (héritée) : Utilisez le SDK Microsoft.NET.Sdk.WindowsDesktop.

La plupart de ces problèmes ne sont pas des problèmes réels. Examinez la colonne « Chemin de migration » pour la ligne GDI+ qui répertorie 208 problèmes. L'évaluation signale ces API, car elles sont disponibles dans .NET Framework, mais pas dans .NET. La colonne explique le correctif : ajoutez le System.Drawing.Common package NuGet pour restaurer les API.

La ligne Windows Forms répertorie 621 problèmes d’API pour la même raison. Windows Forms API ne sont pas disponibles dans .NET par défaut, mais vous les restaurez en ciblant un framework Windows spécifique comme net10.0-windows et en définissant <UseWindowsForms>true</UseWindowsForms> dans le fichier projet. L’option 3 suggère une option incorrecte. Les versions antérieures de .NET nécessitaient un projet de Windows Forms pour cibler spécifiquement le Microsoft.NET.Sdk.WindowsDesktop SDK, mais il est désormais automatiquement référencé quand <UseWindowsForms>true</UseWindowsForms> il est défini.

Passer en revue les options de mise à niveau

Après l’évaluation, l’agent présente les décisions de stratégie de mise à niveau et les enregistre dans upgrade-options.md.github/upgrades/scenarios/dotnet-version-upgrade/. Dans l’exemple du jeu d’association, l’agent sélectionne les options suivantes :

L’agent signale également les risques qui nécessitent votre attention. Pour l’exemple de jeu d’association, l’agent signale les packages MetroFramework, car ils sont uniquement disponibles pour .NET Framework. Le résultat probable consiste à supprimer MetroFramework et à revenir aux contrôles de Windows Forms standard, ce qui modifie le style visuel de l’application.

Passez en revue les options proposées et indiquez à l’agent ce que vous souhaitez modifier. Par exemple, indiquez à l’agent d’activer les types référence nullable ou de mettre en pause et de discuter d’abord des remplacements MetroFramework. Lorsque vous avez terminé, répondez confirm pour confirmer les sélections et passer à la planification.

Passer en revue le plan

Dans l’étape de planification, l’agent convertit l’évaluation et vos options confirmées en spécification détaillée. Il écrit le résultat dans plan.md et crée un fichier scenario-instructions.md qui stocke les préférences, les décisions et les instructions personnalisées pour la mise à niveau.

Le plan couvre des éléments tels que l’ordre de mise à niveau entre les projets, l’identifiant du framework cible pour chaque projet (net10.0-windows pour les projets Windows Forms), les chemins de mise à jour des packages et les mesures d’atténuation des risques liés aux changements incompatibles relevés lors de l’évaluation.

Pour passer en revue et personnaliser le plan :

1. Ouvrir plan.md dans .github/upgrades/scenarios/dotnet-version-upgrade/.
2. Passez en revue les stratégies de mise à niveau et les mises à jour des dépendances.
3. Modifiez le plan pour ajuster les étapes ou ajouter du contexte en fonction des besoins.
4. Indiquez à l’agent de passer à l’étape d’exécution.

Exécuter la mise à niveau

Dans l’étape d’exécution, l’agent interrompt le plan en tâches séquentielles concrètes avec des critères de validation. L’agent écrit la liste des tâches dans .github/upgrades/scenarios/dotnet-version-upgrade/tasks.md ce fichier et effectue le suivi de la progression globale dans ce fichier. Pour chaque tâche, l’agent crée un dossier sous .github/upgrades/scenarios/dotnet-version-upgrade/tasks/ lequel contient un fichier Markdown décrivant la tâche et un fichier Markdown qui signale la progression de la tâche.

Pour l’exemple Matching Game, la liste des tâches inclut généralement la mise à niveau de MatchingGame.Logic, puis de MatchingGame, la restauration des packages, la génération de la solution et la validation des changements.

Pour exécuter la mise à niveau :

1. Indiquez à l’agent de démarrer la mise à niveau.
2. Suivez la progression en consultant tasks.md à mesure que l’agent met à jour l’état des tâches. Ouvrez les dossiers par tâche sous tasks/ pour la description de la tâche et un rapport de progression détaillé.
3. Si l’agent rencontre un problème qu’il ne peut pas résoudre, fournissez l’aide demandée. Par exemple, l’agent peut vous demander de choisir entre deux API de remplacement ou de confirmer s’il faut conserver un package déconseillé.
4. En fonction de vos réponses, l’agent adapte sa stratégie aux tâches restantes et continue.

L’agent valide les modifications en fonction de la stratégie Git que vous avez configurée lors de la pré-initialisation : par tâche, par groupe de tâches ou à la fin.

Remarques relatives aux projets Visual Basic

Les projets Windows Forms Visual Basic dans .NET Framework utilisent souvent System.Configuration comme fichiers de paramètres et My comme extensions, tels que My.Computer et My.User. Les My extensions ont été supprimées dans .NET. L’agent signale ces modèles pendant l’évaluation et propose des correctifs pendant l’exécution, mais vous devrez peut-être confirmer les modifications individuelles pendant une exécution guidée.

Si l'agent migre le projet, mais qu'il ne compile pas, vérifiez que le fichier projet cible Windows et référence Windows Forms. L’élément <PropertyGroup> doit ressembler à l’extrait de code suivant :

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net10.0-windows</TargetFramework>
    <UseWindowsForms>true</UseWindowsForms>
    <OutputType>WinExe</OutputType>
    <MyType>WindowsForms</MyType>

    <!-- Other settings removed for brevity. -->
  </PropertyGroup>
</Project>

Vérifier la mise à niveau

Une fois la mise à niveau terminée, l’agent recommande les étapes suivantes dans la réponse de conversation. Invitez l’agent à générer un rapport de modification complet avec « Générer un rapport de modification ».

Examinez le statut final de la tâche dans tasks.md et confirmez que chaque étape est terminée.

Pour vérifier la mise à niveau :

1. Générez la solution et résolvez toutes les erreurs de compilation.

2. Exécutez l’application et vérifiez que les formulaires se chargent et se comportent comme prévu.

   La police par défaut dans Windows Forms a changé entre .NET Framework et .NET, il faut donc vérifier les formulaires et les contrôles personnalisés afin de repérer d’éventuelles différences de disposition.

3. Exécutez tous les tests unitaires dans la solution et corrigez les échecs.

4. Vérifiez que les packages NuGet mis à jour sont compatibles avec votre application.

5. Testez soigneusement l’application pour vérifier que la mise à niveau a réussi.

L’exemple de jeu correspondant Windows Forms est désormais mis à niveau vers .NET 10.

Expérience post-mise à niveau

Si vous avez porté l’application de .NET Framework vers .NET, passez en revue Moderniser après la mise à niveau vers .NET à partir de .NET Framework pour obtenir des idées sur l’adoption de modèles plus récents, tels que appsettings.json la configuration, l’injection de dépendances ou les services cloud. L'adoption de ces modèles est distincte de la mise à niveau vers .NET et n'est pas nécessaire pour terminer la mise à niveau.

Contenu connexe

• Vue d’ensemble de la mise à niveau des applications Windows Forms
• Meilleures pratiques pour la modernisation de GitHub Copilot
• Portage de .NET Framework vers .NET
• Moderniser après une mise à niveau de .NET Framework vers .NET
• Changements cassants lors du portage de code