Projekt-Untertyp-Entwurf
Projekt untertypen VSPackages können Projekte auf Grundlage des Microsoft Build Engine (MSBuild) erweitern. Die Verwendung von Aggregation können Sie den Großteil des Projektsystems verwalteten Kern wiederverwenden, das in Visual Studio trotzdem das Verhalten für ein bestimmtes Szenario weiter anpassen implementiert wird.
Die folgenden Themen führen den grundlegenden Entwurf und Implementierung von untertypen Projekt einzeln aufgeführt:
Projekt-Untertyp-Entwurf.
Aggregation auf mehreren Ebenen.
Schnittstellen unterstützen.
Projekt-Untertyp-Entwurf
Die Initialisierung eines Projekts untertyps wird erreicht, indem die wichtigsten IVsHierarchy und die IVsProject-Objekten aggregiert. Diese Aggregation kann ein Projekt untertyp, um die meisten Funktionen des Projekts Basisklasse zu überschreiben oder zu erweitern. Projekt untertypen rufen die erste Möglichkeit, Eigenschaften, mit IVsHierarchymit Befehlen und IOleCommandTargetIVsUIHierarchyProjektelement und Verwaltung mithilfe IVsProject3zu behandeln. Projekt untertypen können auch erweitern:
Projektkonfiguration Objekte.
Anlagenabhängige Objekten.
konfigurationsunabhängige Suchobjekte.
automatisierungsobjekte Projekt.
Auflistungen automatisierungseigenschaften Projekt.
Weitere Informationen über die Erweiterbarkeit von Projekt untertypen, finden Sie unter Projekt-Untertypen von erweiterten Eigenschaften und Methoden.
Richtliniendateien
Die Visual Studio Umgebung stellt ein Beispiel für das Erweitern des Projektsystems Basisklasse mit einem Projekt untertyp in seiner Implementierung von Richtliniendateien. Eine Richtliniendatei kann die Strukturierung der Visual Studio Umgebung, indem Funktionen verwaltet, die das Projektmappen-Explorer-, Projekt hinzufügen Dialogfeld, Neues Element hinzufügen Dialog Box und das Dialogfeld Eigenschaften enthalten. Der Richtlinien untertyp überschreibt und erhöht diese Funktionen über IVsFilterAddProjectItemDlg, IOleCommandTarget und IVsUIHierarchy Implementierungen.
Aggregations-Mechanismus
Der Projekt untertyp-Aggregations Mechanismus für die Umgebung unterstützt mehrere Aggregationsebenen und ermöglicht so einen erweiterten von anderen Typ implementiert werden muss, Untertyp eines Projekts mit dem Typ. Für die unterstützenden Objekte eines Projekts untertyps, wie IVsProjectFlavorCfg, sind für mehrere Ebenen der Überlagerung zu ermöglichen. In Uebereinstimmung mit den Einschränkungen von COM- und müssen COM-Aggregation Regeln untertypen, Projekt- und niedrigen Projekten gemeinsam programmiert werden, um den inneren Untertyp oder das niedrige Projekt ordnungsgemäß zu ermöglichen, die Teilnahme an Methodenaufrufe zu delegieren, und Verweiszähler zu verwalten. Das heißt, muss das Projekt, aggregiert werden so programmiert werden, dass Aggregation zu unterstützen.
Die folgende Abbildung zeigt eine vereinfachte Darstellung einer Projekt untertyp aggregation auf mehreren Ebenen angegeben.
Mehrstufiger Projekt-Untertyp
.gif "Grafik zu Visual Studio-Mehrebenen-Projekttyp")
Eine Projekt untertyp aggregation auf mehreren Ebenen besteht aus drei Ebenen, ein niedriges Projekt, das von einem Projekt untertyp aggregiert wird, profitieren von aggregiertes dann einen erweiterten Projekt untertyp. Die Abbildung konzentriert sich auf einige der unterstützenden Schnittstellen, die als Teil der Visual Studio Architektur der untertyp Projekt zur Verfügung gestellt werden.
Bereitstellungs-Mechanismen
Bei vielen der Projektsystem funktionalitäten, die von einem Projekt untertyp Bereitstellung sind Mechanismen erhöht werden. Ein Projekt untertyp Mechanismen Bereitstellung beeinflussen, indem er Schnittstellen implementiert (z. B. IVsDeployableProjectCfg Konfiguration und IVsBuildableProjectCfg) abgerufen werden, indem die QueryInterface für IVsProjectCfgProvideraufruft. In einem Szenario, in dem das Projekt untertyp und erweiterte Projekt untertyp verschiedene Implementierungen von Konfigurationsinformationen hinzufügen, ruft das niedrige Projekt auf QueryInterface erweiterten IUnknowndes Projekts untertyps an. Wenn der innere Projekt untertyp die Implementierung der Konfiguration enthalten ist, die das niedrige Projekt um anfordert, delegiert der erweiterte untertyp Projekt zur Implementierung, die vom inneren Projekt untertyp bereitgestellt wird. Wie ein Mechanismus, um den Zustand einer Aggregation beizubehalten, die an andere, alle Ebenen von untertypen Projekt mit IPersistXMLFragment Build nicht implementieren, um verknüpfte XML-Daten in die Projektdateien beizubehalten. Weitere Informationen finden Sie unter Beibehalten von Daten in der MSBuild-Projektdatei. IInternalExtenderProvider wird als Mechanismus implementiert, um extender Automatisierung von Projekt untertypen abzurufen.
In der folgenden Abbildung extender konzentriert sich auf die Automatisierung, das suchobjekt Projektkonfiguration Implementierung verwendet, insbesondere die vom Projekt untertypen, um das niedrige Projektsystem zu erweitern.
Projekt-Untertyp-Automatisierungs-Extender.
.gif "Grafik zu VS-Projekttyp Automatisierungsextender")
Projektuntertypen können das niedrige Projektsystem weiter erweitern, indem sie das Automatisierungsobjektmodell erweitern. Diese werden als Teil des DTE-Automatisierungsobjekts definiert und verwendet werden, um das Projektobjekt, das ProjectItem-Objekt und das Configuration-Objekt zu erweitern. Weitere Informationen finden Sie unter Das Objektmodell unzureichenden Projekts erweitern.
Aggregation auf mehreren Ebenen
Eine Implementierung der untertyp Projekt mit einem Projekt untertyp auf der untersten Ebene umschließt, muss sich kooperativ so programmiert werden, dass sie dem inneren Projekt untertyp zuzulassen, um ordnungsgemäß zu funktionieren. Eine Liste der Programmierelement selbst enthält:
Die IPersistXMLFragment Implementierung des Projekts untertyps, der den inneren Untertyp umschließt, muss auf IPersistXMLFragment die Implementierung des inneren Projekt untertyps für LoadSave und Methoden delegieren.
Die IInternalExtenderProvider Implementierung des Wrappers, untertyps muss auf dem des inneren Projekt untertyps delegieren. Insbesondere muss die Implementierung von GetExtenderNames die Zeichenfolge aus dem Namen der inneren Projekt untertyp abrufen und dann die Zeichenfolgen verketten, die er als Extender hinzufügen möchte.
Die IVsProjectCfgProvider Implementierung eines Wrapper untertyps muss das Projekt IVsProjectFlavorCfg-Objekt des inneren Projekt untertyps instanziieren und sie als privaten Delegaten enthalten, da nur die grundlegenden Projektkonfiguration Objekt des Projekts direkt weiß, dass das Projekt Wrapper untertyp-Konfigurations Objekt vorhanden ist. Der äußere untertyp Projekt zunächst Schnittstellen Konfiguration auswählen kann, die er direkt behandeln möchte und delegiert dann den Rest auf die interne Implementierung des Projekts untertyps von get_CfgType.
Schnittstellen unterstützen
Das niedrige Projekt zu unterstützenden Aufrufe delegiert Schnittstellen, die von einem Projekt untertyp hinzugefügt werden, um verschiedene Aspekte seiner Implementierung zu erweitern. Dies schließt das Erweitern von Projektkonfiguration von Objekten und verschiedener Eigenschaftenbrowser Objekte ein. Diese Schnittstellen werden abgerufen, indem QueryInterface auf punkOuter (ein Zeiger auf IUnknown) des äußersten Projekt untertyp aggregators aufruft.
Schnittstelle |
Projekt-Untertyp |
|---|---|
Ermöglicht es dem Projekt untertyp to:
|
|
Ermöglicht es dem Projekt untertyp to:
Die oben aufgeführten Eigenschaftswerte werden von __VSHPROPID2-Enumeration bestimmt. |
|
Ermöglicht dem Projekt untertyp der Zuordnung zurück an den angegebenen IVsCfg das Objekt suchobjekt Projektkonfiguration. |
|
Ermöglicht es dem Projekt untertyp der Zuordnung zurück an IVsHierarchy oder dem VSITEMID-Objekt mit dem suchobjekt Projektkonfiguration. |
|
Ermöglicht dem Projekt untertyp willkürlich strukturierte Daten, um XML zur Projektdatei beizubehalten (.vbproj oder .csproj). Dies ist keine Daten an MSBuild sichtbar. |
|
Ermöglicht es dem Projekt untertyp to:
|