Visual Studio 2019 Déplacer, migrer et mettre à niveau des projets
Communauté de développeurs | Configuration requise | Compatibilité | Code distribuable | Historique des versions | Termes du contrat de licence | Blogs
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.
Conseil
Si vous recherchez des informations spécifiques à notre prochaine version, consultez la version Visual Studio 2022 de cette page.
Nous essayons de préserver la rétrocompatibilité avec les versions précédentes, notamment 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 2019, consultez la page Ciblage et compatibilité de la plateforme.
Types de projet
La liste suivante décrit la prise en charge dans Visual Studio 2019 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 2017 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, et Visual Studio 2019 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 ou Visual Studio 2019, 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 2019, l’utilisateur doit s’authentifier sur Visual Studio 2019. |
| C#/Visual Basic Webform ou Windows Form | Vous pouvez ouvrir le projet dans 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 2019 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és dans Visual Studio 2019 et versions ultérieures. 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 :
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 :
|
| Installation de MSI (vdproj) | Consultez la section InstallShield de cette page. |
| Office 2007 VSTO | Requiert une mise à niveau définitive pour Visual Studio 2019. |
| 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 2019, 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 peuvent être ouverts dans Visual Studio 2015, Visual Studio 2017 ou Visual Studio 2019, sauf si le projet d’application Service Fabric référence un projet de service ASP.NET Core. Les projets Service Fabric de Visual Studio 2015 qui sont ouverts dans Visual Studio 2017 ou Visual Studio 2019 sont migrés de façon unidirectionnelle du format xproj au format csproj. Consultez « Projets .NET Core (xproj) » plus haut dans cette table. |
| SharePoint 2010 | Quand un projet de solution SharePoint est ouvert avec Visual Studio 2019, il est mis à niveau vers SharePoint 2013 ou SharePoint 2016. La charge de travail « Développement .NET Desktop » doit être installée dans Visual Studio 2019 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 2019. 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 2019. 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) | La prise en charge de Visual Studio 2019 est disponible. Pour plus d’informations, consultez la page Télécharger et installer SQL Server Data Tools (SSDT) pour Visual Studio, le blog de l’équipe SQL Server Integration Services (SSIS) et la page Projets SQL Server Integration Services dans la Place de marché. |
| 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. |
| Visual C++ | Vous pouvez utiliser Visual Studio 2019 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 2019 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 2019, 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 2019, 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 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 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 2019. 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 2019. 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 2019. Pour gérer ces applications, continuez à utiliser Visual Studio 2015. |
| Xamarin | L’extension Xamarin Live Player pour Visual Studio et Visual Studio pour Mac a été supprimée. Cela supprime l’écran de jumelage et toute intégration. À la place, utilisez le générateur d’aperçu Xamarin.Forms intégré. L’émulateur Visual Studio pour Android a été supprimé de Visual Studio Installer. À la place, utilisez la nouvelle prise en charge Hyper-V dans l’émulateur Google Android. |
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. (Voir Ciblage et compatibilité de plateforme pour connaître les types de projets pris en charge dans Visual Studio 2019). 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.
Parfois, la 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. (Notamment différents canaux de 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 ; Visual Studio 2010 SP1.) Quand des composants design-time dépréciés sont utilisés, Visual Studio 2019 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 2019 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 2019 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.
Étapes suivantes
Pour plus d’informations, consultez les articles suivants :