Partager via


Icône Visual StudioVisual Studio 2022 Déplacer, migrer et mettre à niveau des projets


Conseil

Pour en savoir plus sur les nouveautés, découvrir des conseils et des astuces, et télécharger des cadeaux numériques gratuits, regardez les enregistrements de l’événement de lancement de Visual Studio 2022.

Developer Community | Feuille de route de Visual Studio 2022 | Exigences système | Compatibilité | Code distribuable | Historique de publication | Termes du contrat de licence | Blogs | Derniers problèmes connus | Nouveautés de la documentation Visual Studio


Chaque nouvelle version de Visual Studio prend en charge la plupart des types de projets, de fichiers et d’autres ressources. Vous pouvez les utiliser comme vous l’avez toujours fait, à condition de ne pas dépendre de fonctionnalités plus récentes.

Nous essayons de préserver la rétrocompatibilité avec les versions précédentes, notamment Visual Studio 2019, Visual Studio 2017, Visual Studio 2015, Visual Studio 2013 et Visual Studio 2012. Mais la prise en charge de certains types de projet change avec le temps. Une version plus récente de Visual Studio peut cesser de prendre en charge certains projets, ou nécessiter la mise à jour d’un projet et lui faire perdre sa compatibilité descendante.

Notes

Pour connaître l’état actuel des problèmes de migration, reportez-vous à la Communauté des développeurs Visual Studio. Pour en savoir plus sur les fonctionnalités spécifiques à la version de Visual Studio, consultez les notes de publication.

Important

Certains types de projets nécessitent des charges de travail spécifiques. Si la charge de travail n’est pas installée, Visual Studio signale un type de projet inconnu ou non compatible. Dans ce cas, vérifiez vos options d’installation dans Visual Studio Installer et réessayez. Pour plus d’informations sur la prise en charge des projets dans Visual Studio 2022, consultez la page Ciblage et compatibilité de la plateforme.

Types de projet

La liste suivante décrit la prise en charge dans Visual Studio 2022 de projets qui ont été créés dans des versions antérieures.

Si un type de projet ou de fichier n’y est pas listé alors qu’il devrait l’être, consultez la version Visual Studio 2019 de cet article. Vous pouvez aussi utiliser le bouton Envoyer et afficher les commentaires pour>Cette page en bas de cette page pour fournir des détails sur votre projet. (Si vous utilisez le contrôle anonyme « Cette page vous a-t-elle été utile ? », nous ne pouvons pas répondre à vos commentaires.)

Type de projet Support
Projets .NET Core (.xproj) Les projets créés avec Visual Studio 2015 utilisaient des outils d’aperçu qui incluaient un fichier projet xproj.

Visual Studio 2017 : le format xproj n’est pas pris en charge, sauf pour la migration vers le format csproj. Lorsque vous ouvrez un fichier xproj, vous êtes invité à migrer le fichier au format csproj de style SDK. (Une sauvegarde du fichier xproj est effectuée). Les projets csproj de style SDK ne sont pas pris en charge dans Visual Studio 2015 et versions antérieures.

Visual Studio 2019 : dans la version 16.3 et ultérieure, vous ne pouvez pas charger ou migrer des projets xproj. Pour plus d’informations, consultez Migration de projets .NET Core au format csproj.
Application web ASP.NET Core et application web ASP.NET Core avec Application Insights activé Pour chaque utilisateur de Visual Studio, les informations sur les ressources sont stockées dans le Registre pour chaque instance utilisateur. Ces informations sont utilisées quand un utilisateur n’a pas de projet ouvert et qu’il souhaite rechercher des données Azure Application Insights. Visual Studio 2015 n’utilise pas le même emplacement du Registre que Visual Studio 2017, Visual Studio 2019, et Visual Studio 2022 ne provoque pas de conflit.

Une fois qu’un utilisateur crée une application web ASP.NET ou une application web ASP.NET Core, la ressource est stockée dans le fichier .suo. L’utilisateur peut ouvrir le projet dans Visual Studio 2015, Visual Studio 2017, Visual Studio 2019 ou Visual Studio 2022, et les informations de ressource servent dans les deux cas tant que Visual Studio prend en charge les projets et solutions utilisés dans les deux versions. Les utilisateurs doivent s’authentifier une seule fois sur chaque produit. Par exemple, si un projet est créé avec Visual Studio 2017 et ouvert dans Visual Studio 2022, l’utilisateur doit s’authentifier sur Visual Studio 2022.
C#/Visual Basic Webform ou Windows Form Vous pouvez ouvrir ce projet dans Visual Studio 2022, Visual Studio 2019, Visual Studio 2017 et Visual Studio 2015.
Test codé de l’interface utilisateur Le test codé de l’interface utilisateur qui permet d’effectuer des tests fonctionnels automatisés et pilotés par l’interface utilisateur est déprécié dans Visual Studio 2019.

Visual Studio 2019 sera la dernière version prenant en charge le test codé de l’interface utilisateur. Nous vous recommandons d’utiliser Selenium pour tester les applications web et Appium avec WinAppDriver pour tester les applications de bureau et UWP.
Projets de test unitaire de base de données (csproj, vbproj) Les anciens projets de test unitaire de données sont chargés dans Visual Studio 2019, mais ils utilisent la version de dépendances placée dans le GAC. Pour mettre à niveau le projet de test unitaire afin d’utiliser les dernières dépendances, cliquez avec le bouton droit sur le projet dans l’Explorateur de solutions, puis sélectionnez Convertir en projet de tests unitaires SQL Server.
F# Vous pouvez ouvrir dans Visual Studio 2019 des projets créés dans Visual Studio 2013, Visual Studio 2015 et Visual Studio 2017. Une différence essentielle par rapport aux modèles Visual Studio plus anciens pour les nouveaux projets est que la version de FSharp.Core est désormais toujours un package NuGet. F# est installé par défaut avec une charge de travail .NET quelconque.
InstallShield
Installation de MSI
Les projets d’installation créés dans Visual Studio 2010 peuvent être ouverts dans les versions ultérieures à l’aide de l’extension des projets d’installation Visual Studio. Consultez également l’extension WiX Toolset Visual Studio 2017. InstallShield Limited Edition n’est plus inclus dans Visual Studio. Vérifiez la disponibilité pour Visual Studio 2022 auprès de Revenera.
LightSwitch LightSwitch n’est plus pris en charge dans Visual Studio 2022, Visual Studio 2019 ou Visual Studio 2017. Les projets créés avec Visual Studio versions 2012 et antérieures et ouverts dans Visual Studio 2013 ou Visual Studio 2015 sont mis à niveau et ne peuvent être ouverts par la suite que dans Visual Studio 2013 ou Visual Studio 2015.
Test de charge Les fonctionnalités de test de charge et de performances web sont dépréciées dans Visual Studio 2019.

Visual Studio 2019 sera la dernière version à prendre en charge le test de charge. Utilisez d’autres outils de test de charge tels qu’Apache JMeter, Akamai CloudTest ou Blazemeter.
Microsoft Azure Tools pour Visual Studio Pour ouvrir ces types de projets, installez tout d’abord le kit SDK Microsoft Azure pour .NET., puis ouvrez le projet. Si nécessaire, votre projet est mis à jour.
Microsoft Test Manager Microsoft Test Manager et Feedback Client ne sont plus fournis dans Visual Studio à compter de Visual Studio 2019.

Exploitez Azure Test Plans (inclus dans Azure DevOps) pour vos besoins de tests manuels et exploratoires.
Framework du modèle ASP.NET MVC (Model-View-Controller) Prise en charge des versions MVC et de Visual Studio :
  • Visual Studio 2010 SP1 prend en charge MVC 2 et MVC 3, tandis que la prise en charge de MVC 4 est ajoutée par le biais du téléchargement d’ASP.NET 4 MVC 4 pour Visual Studio 2010 SP1.
  • Visual Studio 2012 prend en charge uniquement MVC 3 et MVC 4.
  • Visual Studio 2013 prend en charge uniquement MVC 4 et MVC 5.
  • Visual Studio 2019, Visual Studio 2017 et Visual Studio 2015 prennent en charge MVC 4 (vous pouvez ouvrir des projets existants, mais pas en créer) et MVC 5.

Mise à niveau de versions MVC :
Modélisation Si vous permettez à Visual Studio de mettre à jour le projet automatiquement, vous pouvez l’ouvrir dans Visual Studio 2015, Visual Studio 2013 ou Visual Studio 2012.

Le format du projet de modélisation n’a pas changé depuis Visual Studio 2015, et vous pouvez ouvrir et modifier le projet dans ces versions. Toutefois, il existe des différences de comportement dans Visual Studio 2017 et Visual Studio 2019 :
  • Les projets de modélisation sont désormais appelés projets « Validation de dépendance » dans les menus et les modèles.
  • Les diagrammes UML ne sont plus pris en charge dans Visual Studio 2017 et Visual Studio 2019. Les fichiers UML restent dans l’Explorateur de solutions, mais s’ouvrent en tant que fichiers XML. Utilisez Visual Studio 2015 pour afficher, créer ou modifier des diagrammes UML.
  • Dans Visual Studio 2019, la validation des dépendances architecturales n’est plus effectuée pendant la génération du projet de modélisation, mais à chaque génération d’un projet de code. Ce changement n’affecte pas le projet de modélisation, mais il nécessite des modifications dans les projets de code en cours de validation. Visual Studio 2019 peut effectuer automatiquement les modifications nécessaires dans les projets de code.
Installation de MSI (vdproj) Consultez la section InstallShield de cette page.
Office 2007 VSTO Requiert une mise à niveau définitive pour Visual Studio 2022.
Office 2010 VSTO Si le projet cible .NET Framework 4, vous pouvez l’ouvrir dans Visual Studio 2010 SP1 et les versions ultérieures. Tous les autres projets nécessitent une mise à niveau définitive.
Bibliothèque de classes portable (PCL) Les bibliothèques de classes portables (ou bibliothèques PCL) ne sont plus prises en charge. Visual Studio 2019 peut encore les ouvrir et les générer, mais il n’est pas possible de créer de nouveaux projets de bibliothèque PCL. Nous vous recommandons de migrer le code d’un projet PCL vers un projet .NET Standard.

La prise en charge des bibliothèques PCL ne sera plus incluse par défaut, mais elle sera disponible sous l’onglet « Composants individuels » de Visual Studio.
Charge de travail Python La prise en charge pour les applications Python Windows IoT Core a été supprimée dans Visual Studio 2019. Étant donné qu’il n’y a pas d’équivalent dans Visual Studio 2022, il n’existe aucun chemin de migration automatique de ces projets.

Vous pouvez continuer à utiliser Visual Studio 2017.
Outils R pour Visual Studio Outils R pour Visual Studio a été supprimé de la charge de travail Science des données dans Visual Studio 2019.

Vous pouvez continuer à utiliser Visual Studio 2017 ou d’autres solutions, comme RStudio.
Service Fabric (sfproj) Les projets d’application Service Fabric créés dans Visual Studio 2017 ou Visual Studio 2019 peuvent être ouverts dans Visual Studio 2022 sans modification.
Les projets d’application Service Fabric créés dans Visual Studio 2022 sans utiliser l’option Optimiser la disposition du projet pour le déploiement ARM peuvent être ouverts dans Visual Studio 2019 16.5 ou version ultérieure.
Les projets d’application Service Fabric créés dans Visual Studio 2022 avec l’option Optimiser la disposition du projet pour le déploiement ARM peuvent être ouverts dans Visual Studio 2019 16.10 ou version ultérieure.
SharePoint 2010 Quand un projet de solution SharePoint est ouvert avec Visual Studio 2022, il est mis à niveau vers SharePoint 2016 ou SharePoint 2019. La charge de travail « Développement .NET Desktop » doit être installée dans Visual Studio pour la mise à niveau.

Pour plus d’informations sur la mise à niveau des projets SharePoint, consultez Mettre à niveau et mettre à jour SharePoint.
SharePoint 2016 Les projets de complément SharePoint créés dans Office Developer Tools Preview 2 ne peuvent pas être ouverts dans Visual Studio 2022. Pour contourner cette limite, mettez à jour MinimumVisualStudioVersion avec la valeur 12.0 et MinimumOfficeToolsVersion avec la valeur 12.2 dans le fichier csproj vbproj.
Silverlight Les projets Silverlight ne sont pas pris en charge dans Visual Studio 2022. Pour gérer des applications Silverlight, continuez à utiliser Visual Studio 2015.
SQL - Redgate Redgate SQL Change Automation Core (anciennement ReadyRoll Core), SQL Prompt Core et SQL Search ne sont plus fournis dans le programme d’installation de Visual Studio.

Vous pouvez continuer à utiliser Visual Studio 2017 pour ces fonctionnalités. Dans Visual Studio 2019 Preview, vous pouvez mettre à niveau les produits SQL Change Automation et SQL Prompt achetés qui sont disponibles dans SQL Toolbelt de Redgate.
SQL Server Reporting Services et SQL Server Analysis Services (SSRS, SSDT, SSAS, MSAS) La prise en charge de ces types de projets est assurée par le biais de deux extensions de la galerie Visual Studio : Microsoft Analysis Services Projects et Microsoft Reporting Services Projects. La prise en charge de SSDT est également incluse dans la charge de travail Stockage et traitement des données dans Visual Studio 2019. Pour plus d’informations, voir la page Télécharger et installer SQL Server Data Tools (SSDT) pour Visual Studio.
SQL Server Integration Services (SSIS) L’extension Projets SQL Server Integration Services est en disponibilité générale pour Visual Studio 2022. Téléchargez Projets SQL Server Integration Services 2022 à partir de Visual Studio Marketplace et consultez le guide de résolution des problèmes pour obtenir des conseils de résolution des problèmes.
Extension de fenêtre de test Dans Visual Studio 2019, certaines API de fenêtre de test, qui étaient auparavant dites publiques mais qui n’ont jamais été officiellement documentées, ont été supprimées. Les API largement visibles avaient été marquées comme dépréciées dans Visual Studio 2017 pour avertir à l’avance les personnes chargées de la maintenance des extensions. À notre connaissance, peu d’extensions dépendaient de ces API. Pour obtenir plus d’informations et des mises à jour, consultez la liste complète des API dépréciées liées aux tests. Si cela affecte votre scénario, faites-le-nous savoir via la Communauté des développeurs Visual Studio.
TypeScript Le Kit de développement logiciel (SDK) TypeScript a été déprécié dans Visual Studio2022 et n’est plus installé par défaut dans une charge de travail. Les projets qui compilent TypeScript doivent installer le package NuGet Microsoft.TypeScript.MSBuild . Pour prendre en charge les projets qui ne peuvent pas être mis à niveau immédiatement, le Kit de développement logiciel (SDK) TypeScript est toujours disponible en tant que composant facultatif dans le programme d’installation de Visual Studio, ainsi que dans Visual Studio Marketplace.
Visual C++ Vous pouvez utiliser Visual Studio 2022 pour travailler sur des projets créés dans des versions antérieures de Visual Studio, jusqu’à Visual Studio 2010. À la première ouverture du projet, il est possible d’effectuer une mise à niveau vers la dernière version du compilateur et de l’ensemble d’outils, ou bien de continuer d’utiliser ceux d’origine. Si vous choisissez de rester sur les originaux, Visual Studio 2022 ne modifie pas le fichier projet et utilise l’ensemble d’outils de l’ancienne installation de Visual Studio pour générer votre projet. En conservant les options d’origine, vous pouvez toujours ouvrir le projet dans la version d’origine de Visual Studio, le cas échéant. Pour plus d’informations, consultez Utiliser le multiciblage natif dans Visual Studio pour générer d’anciens projets.
Extensibilité de Visual Studio/VSIX Un projet pour lequel le paramètre MinimumVersion est défini sur 14.0 ou moins est mis à jour pour déclarer 15.0 comme version minimale, ce qui empêche son ouverture dans les versions antérieures de Visual Studio. Pour permettre l’ouverture d’un projet dans les versions antérieures, définissez MinimumVersion sur $(VisualStudioVersion). Consultez aussi Guide pratique pour migrer les projets d’extensibilité vers Visual Studio 2017.
Visual Studio Lab Management Vous pouvez utiliser Microsoft Test Manager ou Visual Studio 2010 SP1 et versions ultérieures pour ouvrir les environnements créés dans une de ces versions. Toutefois, dans le cas de Visual Studio 2010 SP1, pour pouvoir créer des environnements, la version de Microsoft Test Manager doit correspondre à la version de Team Foundation Server. (Important : Team Foundation Server, ou TFS, s’appelle maintenant Azure DevOps Server.)
Visual Studio Tools pour Apache Cordova La prise en charge pour Apache Cordova a été supprimée dans Visual Studio 2019. Étant donné qu’il n’y a pas d’équivalent dans Visual Studio 2022, il n’existe aucun chemin de migration automatique de ces projets.

Vous pouvez utiliser les outils Cordova pour l’extension de Visual Studio Code (qui fournit la prise en charge pour la dernière version de Cordova) ou continuer à utiliser Visual Studio 2017.
Déploiement Web (wdproj) La prise en charge des projets de déploiement Web dans Visual Studio 2012 a été supprimée avec l’ajout de la prise en charge du profil de publication. Étant donné qu’il n’y a pas d’équivalent dans Visual Studio 2022, il n’existe aucun chemin de migration automatique de ces projets. Au lieu de cela, ouvrez le fichier wdproj dans un éditeur de texte et copier-coller toutes les personnalisations dans à le fichier pubxml (profil de publication), comme décrit dans StackOverflow.
Windows Communication Foundation, Windows Workflow Foundation Vous pouvez ouvrir ce projet dans Visual Studio 2022, Visual Studio 2019, Visual Studio 2017, Visual Studio 2015, Visual Studio 2013 et Visual Studio 2012.
Windows Presentation Foundation Vous pouvez ouvrir ce projet dans Visual Studio 2022, Visual Studio 2019, Visual Studio 2017, Visual Studio 2013, Visual Studio 2012 et Visual Studio 2010 SP1.
Applications Windows Phone Les projets pour Windows Phone ne sont pas pris en charge dans Visual Studio 2022.

Pour gérer les applications Windows Phone 8.x, utilisez Visual Studio 2015. Pour gérer les projets Windows Phone 7.x, utilisez Visual Studio 2012.
Applications du Windows Store Les projets Windows universels JavaScript ne sont pas pris en charge dans Visual Studio 2022. Pour conserver ces projets, utilisez Visual Studio 2017.

Les kits SDK Windows 10 antérieurs à la version Windows 10 Fall Creators Update (build 16299) ont été supprimés du programme d’installation de Visual Studio 2019. Vous pouvez télécharger manuellement les kits SDK plus anciens ou recibler vos projets pour utiliser les kits SDK plus récents.

Les projets Windows universels qui utilisent project.json ne sont pas pris en charge. Nous vous recommandons de mettre à niveau ces projets pour utiliser des références de package. Vous pouvez également ajouter une référence à Microsoft.NET.Test.Sdk version 16.0.0.0 dans le fichier project.json.

Les projets pour Windows Store 8.1 et 8.0 ne sont pas pris en charge dans Visual Studio 2022. Pour gérer ces applications, continuez à utiliser Visual Studio 2015.
Xamarin À compter de Visual Studio 2022 17.11, Xamarin n’est pas pris en charge. Les projets Xamarin doivent donc être mis à niveau vers .NET MAUI.

Migrer un projet

Même si nous essayons de maintenir la compatibilité avec les versions précédentes, il peut y avoir des modifications non compatibles avec les versions précédentes. Lorsque cela se produit, une version plus récente de Visual Studio ne charge pas le projet ou n’offre pas de chemin de migration. Vous devrez peut-être conserver ce projet dans une version précédente de Visual Studio. Pour plus d’informations sur les types de projets pris en charge dans Visual Studio 2022, consultez la page Ciblage et compatibilité de la plateforme.

Dans d’autres cas, une version plus récente de Visual Studio peut ouvrir un projet, mais elle doit mettre à jour ou faire migrer le projet, ce qui le rend incompatible avec les versions antérieures. Visual Studio utilise les critères suivants pour déterminer si une telle migration est nécessaire :

  • Compatibilité avec les versions cibles des plateformes, jusqu’à Visual Studio 2013 RTM.

  • Compatibilité des composants design-time avec les versions antérieures de Visual Studio. (À savoir : différents canaux de Visual Studio 2022, Visual Studio 2019, Visual Studio 2017, Visual Studio 2015 RTM et Update 3, Visual Studio 2013 RTM et Update 5, Visual Studio 2012 Update 4 et Visual Studio 2010 SP1.) Quand des composants design-time dépréciés sont utilisés, Visual Studio 2022 doit pouvoir s’arrêter de manière appropriée sans les altérer. Ainsi, les versions antérieures peuvent toujours ouvrir le projet.

  • Vérifier que les nouveaux composants design-time n’entraînent pas de problèmes de compatibilité avec les versions antérieures, jusqu’à Visual Studio 2013 RTM & Update 5.

L’équipe d’ingénierie propriétaire du type de projet examine ces critères, puis prend les décisions qui s’imposent si la prise en charge, la compatibilité et la migration sont concernées. Encore une fois, nous essayons de maintenir une compatibilité entre les versions de sorte que, lorsque vous créez et modifiez des projets dans une version de Visual Studio, ces projets fonctionneront également dans d’autres versions.

Parfois, la compatibilité n’est pas possible. Visual Studio ouvre l’Assistant Mise à niveau pour apporter les changements unidirectionnels nécessaires. De tels changements unidirectionnels peuvent impliquer un changement de la propriété ToolsVersion dans le fichier projet. Cela permet d’identifier précisément la version de MSBuild capable de transformer le code source du projet en artefacts exécutables et déployables, conformément à vos besoins.

Ce qui rend un projet incompatible avec les versions antérieures de Visual Studio n’est pas la version proprement dite de Visual Studio, mais plutôt la version de MSBuild, laquelle est déterminée par ToolsVersion. Si votre version de Visual Studio contient la chaîne d’outils MSBuild qui correspond à ToolsVersion dans un projet, Visual Studio peut appeler cette chaîne d’outils pour générer le projet.

Pour conserver une compatibilité avec les projets créés dans des versions précédentes, Visual Studio 2022 inclut les chaînes d’outils MSBuild nécessaires à la prise en charge de ToolsVersion 15, 14, 12 et 4. Les projets qui utilisent l’une de ces valeurs de ToolsVersion doivent entraîner la réussite de la build. (À condition, là encore, que Visual Studio 2022 prenne en charge le type de projet, comme indiqué dans Ciblage et compatibilité de la plateforme.)

Vous pouvez être tenté de mettre à jour manuellement ou de migrer un projet vers une valeur ToolsVersion plus récente. Ce type de changement est inutile. Il va générer probablement beaucoup d’erreurs et d’avertissements que vous devrez traiter pour que le projet puisse être regénéré. En outre, si Visual Studio ne prend pas en charge un élément ToolsVersion spécifique à l’avenir, le projet déclenche le processus de migration de projet lorsque vous l’ouvrez, car sa valeur ToolsVersion doit être modifiée.

Projets pré-MSBuild

Avertissement

Les projets .NET pré-MSBuild (autrement dit, les projets .NET créés avec des versions de Visual Studio antérieures à MSBuild) sont uniquement convertibles si vous les mettez à niveau avec une version de Visual Studio jusqu’à Visual Studio version 17.12. Les projets ne seront pas convertibles en utilisant la version 17.13 de Visual Studio ou une version ultérieure. Convertissez tous les projets de ce type dont vous pourriez encore avoir besoin avec Visual Studio 17.12 et stockez les résultats de la conversion. Les autres formats de projet continueront à être convertibles, et les versions antérieures de Visual Studio continueront à convertir même les fichiers projet pré-MSBuild. Cependant, il est toujours recommandé de stocker les résultats des conversions, car dans les futures versions ou mises à jour des versions précédentes de Visual Studio (y compris 2017 et 2019), des restrictions supplémentaires de la fonctionnalité de mise à niveau pourraient s’appliquer.