Comment : Modifiez un système de projet afin que les projets sont chargées dans plusieurs versions de Visual Studio
Dans Visual Studio 2012, vous pouvez empêcher un projet créé dans votre système de projet personnalisé du chargement dans une version antérieure de Visual Studio, ou vous pouvez lui permettre de s'identifient vers une version ultérieure au cas où il faudrait appeler la réparation, la conversion, ou la désapprobation.
Notes
Dans ce contexte, le terme réparation signifie modifier le projet afin qu'il puisse charger automatiquement dans la version de Visual Studio dans laquelle il a été créé ou dans la version ultérieure.La conversion, ou la mise à niveau, signifie modifier un projet afin qu'il puisse plus ne charger dans la version dans lequel il a été créé.
Marquant un projet comme incompatible
Vous pouvez marquer un projet comme incompatible avec des versions antérieures de Visual Studio. Par exemple, supposons que vous créez dans Visual Studio 2012 un projet qui utilise une fonctionnalité du .NET Framework 5. Dans la mesure où ce projet ne peut pas être généré dans Visual Studio 2010 SP1, vous pouvez le marquer comme incompatible avec Visual Studio 2010 SP1 afin que cette version n'essaie pas de la charger.
Le composant qui ajoute des fonctionnalités incompatible est chargé de marquer le projet comme incompatible. Le composant doit avoir accès à l'interface d' IVsHierarchy qui représente les projets d'intérêt.
Pour marquer un projet comme incompatible
Lorsque Visual Studio identifie le projet et incompatible, il affiche une boîte de dialogue demandant l'autorisation de marquer tous les projets donné qu'incompatibles. Si vous acceptez de marquer les projets comme incompatibles, AskForUserConsentToBreakAssetCompat retourne S_OK au composant ; sinon, il retourne OLE_E_PROMPTSAVECANCELLED.
Avertissement
Dans la plupart des scénarios courants, le tableau d' IVsHierarchy contient uniquement un élément.
Si AskForUserConsentToBreakAssetCompat retourne S_OK, le composant apporte ou accepte des modifications qui arrêtent la compatibilité.
Important
Vous devez implémenter la propriété d' VSHPROPID_MinimumDesignTimeCompatVersion pour marquer un projet aussi cohérente ou incompatible.Par exemple, si le système de projet utilise un fichier projet MSBuild, ajoutez au fichier projet une propriété de génération d' <MinimumVisualStudioVersion> ayant une valeur égale à la valeur de la propriété correspondante d' VSHPROPID_MinimumDesignTimeCompatVersion .
Déterminer si un projet est incompatible
Les projets qui sont incompatibles avec la version actuelle de Visual Studio doivent être conservées dans le chargement. En outre, un projet qui est incompatible ne peut pas être mis à niveau ou réparé. Par conséquent, un projet doit être examiné pour vérifier la compatibilité deux fois : d'abord, lorsqu'il est considéré comme pour la mise à niveau ou la réparation, et ensuite, avant qu'elle ne soit chargée.
Pour activer la détection de l'incompatibilité de projet, vous devez appliquer l' UpgradeProject_CheckOnly et les méthodes d' CreateProject . Si un projet est incompatible, UpgradeProject_CheckOnly doit retourner un code de réussite VS_S_INCOMPATIBLEPROJECT et CreateProject doit retourner un code d'erreur VS_E_INCOMPATIBLEPROJECT.
Notes
Vous pouvez mettre en cache le résultat du contrôle de compatibilité par la méthode d' UpgradeProject_CheckOnly afin qu'il puisse également être utilisée par l'appel suivant à CreateProject.
Par exemple, si les méthodes d' UpgradeProject_CheckOnly et d' CreateProject écrites pour un système de projet de Visual Studio 2010 SP1 examinent un fichier projet et une recherche que la propriété de génération d' <MinimumVisualStudioVersion> est « 11,0 », Visual Studio 2010 SP1 ne chargeait pas le projet. En outre, navigateur de solution l'indiquerait que le projet est « incompatible » et ne chargeait pas.
Mise à niveau ou réparation un projet
Visual Studio 2010 SP1 peut convertir la plupart des projets créés dans une version antérieure de Visual Studio. Non seulement peut Visual Studio 2012 ce faire, elle peut également modifier certains types de projets créés dans une version antérieure afin qu'ils puissent charger dans l'un ou l'autre version.
Avant qu'un projet chargé, Visual Studio appelle la méthode d' UpgradeProject_CheckOnly pour voir si le projet peut être mis à niveau. Si le projet peut être mis à niveau, la méthode d' UpgradeProject_CheckOnly définit une balise qui provoque la mise à niveau un appel ultérieur à la méthode d' UpgradeProject le projet. Étant donné que les projets incompatibles ne peuvent pas être mis à niveau, UpgradeProject_CheckOnly doit d'abord vérifier la compatibilité de projet, comme décrit dans la section première.
Dans Visual Studio 2012, vous pouvez implémenter UpgradeProject_CheckOnly pour déterminer si un projet peut être réparé avant qu'il soit chargé. Si le projet peut être réparé, UpgradeProject_CheckOnly doit retourner un code de réussite VS_S_PROJECTREPAIRONLYUPGRADEREQUIRED. Les spécifications possibles de mise à niveau sont énumérées dans VSPUVF_REPAIRFLAGS, et inclut les possibilités suivantes :
SPUVF_PROJECT_NOREPAIR: Ne requiert pas de réparation.
VSPUVF_PROJECT_SAFEREPAIR: Rend le projet compatible avec Visual Studio 2010 sans problèmes que vous pouvez rencontrer la rencontre avec les versions antérieures du produit.
VSPUVF_PROJECT_UNSAFEREPAIR: Rend le projet compatible avec Visual Studio 2010 mais avec un risque des problèmes que vous pouvez rencontrer rencontrés avec les versions antérieures du produit. Par exemple, le projet ne serait pas compatible s'il dépend ait des versions différentes du Kit de développement logiciel entre Visual Studio 2012 et Visual Studio 2010.
VSPUVF_PROJECT_ONEWAYUPGRADE: rend le projet incompatible avec Visual Studio 2010.
VSPUVF_PROJECT_INCOMPATIBLE: Indique que Visual Studio 2012 ne prend pas en charge ce projet.
VSPUVF_PROJECT_DEPRECATED: indique que ce projet n'est plus pris en charge.
Si un système de projet est assaisonné (par exemple, un système de projet Visual Basic ou c# a le Web, l'Office (VSTO), le Silverlight, et d'autres types de projets générés sur arrêter), ces versions de projet peuvent implémenter la fonction UpgradeProjectFlavor_CheckOnly de l'interface d' IVsProjectFlavorUpgradeViaFactory2 . Pour ce faire de fonction, l'appel précédemment doit correspondre indiqué par implémentation d' IVsProjectUpgradeViaFactory4. UpgradeProject_CheckOnly -le. (Notez que cela soit déjà implémenté dans Visual Basic ou c# sur le système de projet.) L'effet de cette fonction permet aux versions de projet pour déterminer également les exigences de mise à niveau d'un projet, en plus de ce que le système de projet de base a déterminé. La boîte de dialogue de compatibilité montre le plus graves les deux spécifications.
Pour les implémentations managées, ces deux interfaces sont disponibles dans l'assembly d' [Microsoft.VisualStudio.Shell.Interop.11.0.dll] .
Si les projets d'une solution doivent être mis à niveau ou convertis, Visual Studio 2012 les listes dans une boîte de dialogue, avec tous les projets incompatibles. Si vous choisissez d'apporter des modifications proposées, la méthode d' UpgradeProject est appelée, et les mises à niveau et sont dépannés. La méthode d' UpgradeProject détermine si les modifications qu'elle effectue empêcheraient le projet du chargement dans une version antérieure de Visual Studio et, si tel est le cas, marquez le projet comme incompatible. Par exemple, vous pouvez créer un projet dans Visual Studio 2010 SP1 puis ouvrir ce projet dans Visual Studio 2012. Si une mise à niveau ou une réparation est possible, la boîte de dialogue est demandé votre autorisation d'effectuer les modifications. Si vous acceptez, les projets sont modifiés puis chargés. Si vous fermez la solution puis rouvrez la dans Visual Studio 2010 SP1, les projets mis à jour sont considérés comme incompatibles, et les projets réparés chargent correctement.