Conception de sous-types de projets
Les sous-types de projet permettent aux VSPackages d’étendre les projets en fonction du moteur de build Microsoft (MSBuild). L’utilisation de l’agrégation vous permet de réutiliser la majeure partie du système de projet managé principal implémenté dans Visual Studio, tout en personnalisant le comportement d’un scénario particulier.
Les rubriques suivantes détaillent la conception et l’implémentation de base des sous-types de projet :
Conception de sous-type de projet.
Agrégation à plusieurs niveaux.
Interfaces de prise en charge.
Conception de sous-type de projet
L’initialisation d’un sous-type de projet est obtenue en agrégeant les principaux IVsHierarchy et IVsProject les objets. Cette agrégation permet à un sous-type de projet de remplacer ou d’améliorer la plupart des fonctionnalités du projet de base. Les sous-types de projet obtiennent la première chance de gérer les propriétés à l’aide IVsHierarchydes commandes à l’aide IOleCommandTarget de et IVsUIHierarchyde la gestion des éléments de projet à l’aide IVsProject3de . Les sous-types de projet peuvent également étendre :
Objets de configuration de projet.
Objets dépendants de la configuration.
Objets de navigation indépendants de la configuration.
Objets d’automatisation de projet.
Collections de propriétés d’automatisation de projet.
Pour plus d’informations sur l’extensibilité par sous-types de projet, consultez Propriétés et méthodes étendues par sous-types de projet.
Fichiers de stratégie
L’environnement Visual Studio fournit un exemple d’extension du système de projet de base avec un sous-type de projet dans son implémentation de fichiers de stratégie. Un fichier de stratégie permet la mise en forme de l’environnement Visual Studio en gérant les fonctionnalités qui incluent les Explorateur de solutions, la boîte de dialogue Ajouter un projet, la boîte de dialogue Ajouter un nouvel élément et la boîte de dialogue Propriétés. Le sous-type de stratégie remplace et améliore ces fonctionnalités par le biais IVsFilterAddProjectItemDlgIOleCommandTarget des implémentations et IVsUIHierarchy des implémentations.
Mécanisme d’agrégation
Le mécanisme d’agrégation de sous-type de projet de l’environnement prend en charge plusieurs niveaux d’agrégation, ce qui permet à un sous-type avancé d’être implémenté en modifiant davantage un projet aromatisé. En outre, les objets de prise en charge d’un sous-type de projet, tels que IVsProjectFlavorCfg, sont conçus pour permettre plusieurs niveaux de superposition. Conformément aux contraintes des règles d’agrégation COM et COM, les sous-types de projet et les projets de base doivent être programmés de manière coopérative pour permettre au sous-type interne ou au projet de base de participer correctement à la délégation des appels de méthode et à la gestion des nombres de références. Autrement dit, le projet sur le point d’être agrégé doit être programmé pour prendre en charge l’agrégation.
L’illustration suivante montre une représentation schématique d’une sous-agrégation de sous-types de projet multiniveaux.
Une sous-agrégation de sous-type de projet à plusieurs niveaux se compose de trois niveaux, d’un projet de base, qui est agrégé par un sous-type de projet, puis agrégé par un sous-type de projet avancé. La figure se concentre sur certaines des interfaces de prise en charge fournies dans le cadre de l’architecture de sous-type de projet Visual Studio.
Mécanismes de déploiement
Parmi de nombreuses fonctionnalités du système de projet de base améliorées par un sous-type de projet, sont des mécanismes de déploiement. Un sous-type de projet influence les mécanismes de déploiement en implémentant des interfaces de configuration (telles que IVsDeployableProjectCfg et IVsBuildableProjectCfg) récupérées en appelant QueryInterface sur IVsProjectCfgProvider. Dans un scénario où le sous-type de projet et le sous-type de projet avancé ajoutent différentes implémentations de configuration, le projet de base appelle QueryInterface le sous-type de projet avancé.IUnknown Si le sous-type de projet interne contient l’implémentation de configuration que le projet de base demande, le sous-type de projet avancé délègue à l’implémentation fournie par le sous-type de projet interne. En tant que mécanisme de persistance de l’état d’un niveau d’agrégation à un autre, tous les niveaux de sous-types de projet implémentent IPersistXMLFragment pour conserver les données XML non liées à la génération dans les fichiers projet. Pour plus d’informations, consultez Conserver les données dans le fichier projet MSBuild. IInternalExtenderProvider est implémenté en tant que mécanisme pour récupérer les extendeurs d’automatisation à partir des sous-types de projet.
L’illustration suivante se concentre sur l’implémentation de l’extendeur Automation, l’objet parcourir la configuration du projet en particulier, utilisé par les sous-types de projet pour étendre le système de projet de base.
Les sous-types de projet peuvent étendre davantage le système de projet de base en étendant le modèle objet Automation. Ceux-ci sont définis dans le cadre de l’objet d’automatisation DTE et sont utilisés pour étendre l’objet Project, l’objet ProjectItem et l’objet Configuration . Pour plus d’informations, consultez Extension du modèle objet du projet de base.
Agrégation à plusieurs niveaux
Une implémentation de sous-type de projet qui encapsule un sous-type de projet de niveau inférieur doit être programmée de manière coopérative pour permettre au sous-type de projet interne de fonctionner correctement. Voici une liste des responsabilités de programmation :
L’implémentation IPersistXMLFragment du sous-type de projet qui encapsule le sous-type interne doit déléguer à l’implémentation IPersistXMLFragment du sous-type de projet interne pour les deux Load méthodes et Save les méthodes.
L’implémentation IInternalExtenderProvider du sous-type de projet wrapper doit déléguer à celle de son sous-type de projet interne. En particulier, l’implémentation de GetExtenderNames doit obtenir la chaîne de noms du sous-type de projet interne, puis concaténer les chaînes qu’il souhaite ajouter en tant qu’extendeurs.
L’implémentation IVsProjectCfgProvider d’un sous-type de projet wrapper doit instancier l’objet IVsProjectFlavorCfg de son sous-type de projet interne et le conserver en tant que délégué privé, car seul l’objet de configuration du projet de base sait directement que l’objet de configuration du sous-type de projet wrapper existe. Le sous-type de projet externe peut initialement choisir des interfaces de configuration qu’il souhaite gérer directement, puis déléguer le reste à l’implémentation du sous-type de projet interne de get_CfgType.
Interfaces de prise en charge
Le projet de base délègue les appels aux interfaces de prise en charge ajoutées par un sous-type de projet pour étendre différents aspects de son implémentation. Cela inclut l’extension des objets de configuration de projet et divers objets de navigateur de propriétés. Ces interfaces sont récupérées en appelant QueryInterface punkOuter (un pointeur vers le IUnknown) de l’agrégateur de sous-type de projet le plus externe.
| Interface | Sous-type de projet |
|---|---|
| IVsProjectFlavorCfg | Autorise le sous-type de projet à : - Fournir une implémentation de IVsDeployableProjectCfg. - Contrôlez le lancement du débogueur en autorisant le sous-type de projet à fournir sa propre implémentation de IVsDebuggableProjectCfg. - Désactivez l’évaluation de l’expression au moment du design en gérant correctement le DBGLAUNCH_DesignTimeExprEval cas dans son implémentation de QueryDebugLaunch. |
| IInternalExtenderProvider | Autorise le sous-type de projet à : - Étendez le VSHPROPID_BrowseObject projet pour ajouter ou supprimer des propriétés indépendantes de la configuration du projet. - Étendre l’objet d’automatisation du projet (VSHPROPID_ExtObject) du projet. Les valeurs de propriété ci-dessus sont extraites de l’énumération __VSHPROPID2 . |
| IVsCfgBrowseObject | Permet au sous-type de projet de revenir à l’objet en fonction de l’objet IVsCfg de navigation de configuration du projet. |
| IVsBrowseObject | Permet au sous-type de projet de revenir à l’objet ou à VSITEMID l’objetIVsHierarchy, en fonction de l’objet parcourir la configuration du projet. |
| IPersistXMLFragment | Permet au sous-type de projet de conserver des données structurées XML arbitraires dans le fichier projet (.vbproj ou .csproj). Ces données ne sont pas visibles par MSBuild. |
| IVsBuildPropertyStorage | Autorise le sous-type de projet à : - Ajoutez de nouvelles propriétés MSBuild à rendre persistantes. - Supprimez les propriétés inutiles de MSBuild. - Rechercher une valeur actuelle d’une propriété MSBuild. - Modifiez la valeur actuelle d’une propriété MSBuild. |