Entwurf von Projektuntertypen

Mit Projektuntertypen können VSPackages Projekte basierend auf dem Microsoft-Build-Engine (MSBuild) erweitern. Mithilfe der Aggregation können Sie den Großteil des in Visual Studio implementierten kernverwalteten Projektsystems wiederverwenden und dennoch das Verhalten für ein bestimmtes Szenario anpassen.

In den folgenden Themen werden das grundlegende Design und die Implementierung von Projektuntertypen beschrieben:

• Projektuntertypentwurf.

• Aggregation auf mehreren Ebenen.

• Unterstützende Schnittstellen.

Projektuntertypentwurf

Die Initialisierung eines Projektuntertyps wird durch Aggregieren der Standard IVsHierarchy und IVsProject Objekte erreicht. Diese Aggregation ermöglicht es einem Projektuntertyp, die meisten Funktionen des Basisprojekts außer Kraft zu setzen oder zu verbessern. Project-Untertypen erhalten die erste Möglichkeit, Eigenschaften mithilfe IVsHierarchyvon Befehlen, Befehlen und IOleCommandTarget IVsUIHierarchyprojektelementverwaltung mithilfe von IVsProject3. Projektuntertypen können auch erweitert werden:

• Project-Konfigurationsobjekte.

• Konfigurationsabhängige Objekte.

• Konfigurationsunabhängige Browseobjekte.

• Projektautomatisierungsobjekte.

• Auflistungen von Project-Automatisierungseigenschaften.

Weitere Informationen zur Erweiterbarkeit nach Projektuntertypen finden Sie unter "Eigenschaften und Methoden erweitert durch Project-Untertypen".

Richtliniendateien

Die Visual Studio-Umgebung bietet ein Beispiel zum Erweitern des Basisprojektsystems mit einem Projektuntertyp in der Implementierung von Richtliniendateien. Eine Richtliniendatei ermöglicht die Gestaltung der Visual Studio-Umgebung, indem Features verwaltet werden, die das Projektmappen-Explorer, das Dialogfeld "Projekt hinzufügen", das Dialogfeld "Neues Element hinzufügen" und das Dialogfeld "Eigenschaften" enthalten. Der Richtlinienuntertyp setzt diese Features außer Kraft und verbessert diese Features durch IVsFilterAddProjectItemDlg, IOleCommandTarget und IVsUIHierarchy Implementierungen.

Aggregationsmechanismus

Der Projektuntertypaggregationsmechanismus der Umgebung unterstützt mehrere Aggregationsebenen, sodass ein erweiterter Untertyp durch weiteres Aromatisieren eines aromatisierten Projekts implementiert werden kann. Außerdem sind die unterstützenden Objekte eines Projektuntertyps, z IVsProjectFlavorCfg. B. , so konzipiert, dass mehrere Ebenen der Schichtung zulässig sind. Im Einklang mit den Einschränkungen von COM- und COM-Aggregationsregeln müssen Projektuntertypen und Basisprojekte kooperativ programmiert werden, damit der innere Untertyp oder das Basisprojekt ordnungsgemäß an der Delegierung von Methodenaufrufen und der Verwaltung von Verweisanzahlen beteiligt werden kann. Das heißt, das Projekt, das aggregiert werden soll, muss zur Unterstützung der Aggregation programmiert werden.

Die folgende Abbildung zeigt eine schematische Darstellung einer Untertypaggregation mit mehreren Ebenen.

Eine Untertypaggregation mit mehreren Ebenen besteht aus drei Ebenen, einem Basisprojekt, das von einem Projektuntertyp aggregiert und dann von einem erweiterten Projektuntertyp aggregiert wird. Die Abbildung konzentriert sich auf einige der unterstützenden Schnittstellen, die als Teil der Visual Studio-Projektuntertyparchitektur bereitgestellt werden.

Bereitstellungsmechanismen

Unter vielen der Basisprojektsystemfunktionen, die durch einen Projektuntertyp verbessert werden, sind Bereitstellungsmechanismen. Ein Projektuntertyp wirkt sich auf Bereitstellungsmechanismen aus, indem Konfigurationsschnittstellen (z IVsDeployableProjectCfg . B. und IVsBuildableProjectCfg) implementiert werden, die durch Aufrufen von QueryInterface abgerufen IVsProjectCfgProviderwerden. In einem Szenario, in dem sowohl der Projektuntertyp als auch der erweiterte Projektuntertyp unterschiedliche Konfigurationsimplementierungen hinzufügen, ruft QueryInterface das Basisprojekt die erweiterten Projektuntertypen IUnknownauf. Wenn der innere Projektuntertyp die Konfigurationsimplementierung enthält, nach der das Basisprojekt gefragt wird, delegiert der erweiterte Projektuntertyp an die Vom inneren Projektuntertyp bereitgestellte Implementierung. Als Mechanismus zum Beibehalten des Zustands von einer Aggregationsebene zu einer anderen implementieren IPersistXMLFragment alle Projektuntertypen, um nicht buildbezogene XML-Daten in den Projektdateien beizubehalten. Weitere Informationen finden Sie unter Speichern von Daten in der MSBuild-Projektdatei. IInternalExtenderProvider wird als Mechanismus zum Abrufen von Automatisierungs-Extendern aus den Projektuntertypen implementiert.

Die folgende Abbildung konzentriert sich auf die Automatisierungs-Extenderimplementierung, das Projektkonfigurations-Browseobjekt insbesondere, das von Projektuntertypen zum Erweitern des Basisprojektsystems verwendet wird.

Projektuntertypen können das Basisprojektsystem weiter erweitern, indem das Automatisierungsobjektmodell erweitert wird. Diese werden als Teil des DTE-Automatisierungsobjekts definiert und zum Erweitern des Project-Objekts, des ProjectItem Objekts und des Configuration Objekts verwendet. Weitere Informationen finden Sie unter Erweitern des Objektmodells des Basisprojekts.

Aggregation auf mehreren Ebenen

Eine Projektuntertypimplementierung, die einen unteren Projektuntertyp umschließt, muss kooperativ programmiert werden, damit der innere Projektuntertyp ordnungsgemäß funktioniert. Eine Liste der Programmieraufgaben umfasst:

• Die IPersistXMLFragment Implementierung des Projektuntertyps, der den inneren Untertyp umschließt, muss für beide Load Methoden Save an die IPersistXMLFragment Implementierung des inneren Projektuntertyps delegiert werden.

• Die IInternalExtenderProvider Implementierung des Wrapperprojektuntertyps muss an den des inneren Projektuntertyps delegieren. Insbesondere muss die Implementierung GetExtenderNames der Zeichenfolge von Namen aus dem inneren Projektuntertyp abrufen und dann die Zeichenfolgen verketten, die sie als Extender hinzufügen möchten.

• Die IVsProjectCfgProvider Implementierung eines Wrapperprojektuntertyps muss das IVsProjectFlavorCfg Objekt seines inneren Projektuntertyps instanziieren und als privater Delegat speichern, da nur das Projektkonfigurationsobjekt des Basisprojekts direkt weiß, dass das Subtypkonfigurationsobjekt des Wrappers für das Projekt vorhanden ist. Der äußere Projektuntertyp kann zunächst Konfigurationsschnittstellen auswählen, die er direkt verarbeiten möchte, und delegieren dann den Rest an die Implementierung des inneren Projektuntertyps.get_CfgType

Unterstützende Schnittstellen

Das Basisprojekt delegiert Aufrufe an unterstützende Schnittstellen, die von einem Projektuntertyp hinzugefügt werden, um verschiedene Aspekte der Implementierung zu erweitern. Dazu gehört das Erweitern von Projektkonfigurationsobjekten und verschiedenen Eigenschaftenbrowserobjekten. Diese Schnittstellen werden abgerufen, indem sie (einen Zeiger auf das IUnknown) des äußersten Projektuntertyp-Aggregators aufruft.QueryInterface punkOuter

Weitere Informationen

• __VSPROPID
• __VSPROPID2