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 IOleCommandTargetIVsUIHierarchyprojektelementverwaltung 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.QueryInterfacepunkOuter
| Schnittstelle | Projektuntertyp |
|---|---|
| IVsProjectFlavorCfg | Ermöglicht dem Projektuntertyp Folgendes: - Bereitstellen einer Implementierung von IVsDeployableProjectCfg. - Steuern Sie den Start des Debuggers, indem Sie dem Projektuntertyp erlauben, eine eigene Implementierung von IVsDebuggableProjectCfg. - Deaktivieren Sie die Auswertung des Entwurfszeitausdrucks, indem Sie den DBGLAUNCH_DesignTimeExprEval Fall in seiner Implementierung QueryDebugLaunchentsprechend behandeln. |
| IInternalExtenderProvider | Ermöglicht dem Projektuntertyp Folgendes: – Erweitern sie das VSHPROPID_BrowseObject Projekt, um konfigurationsunabhängige Eigenschaften des Projekts hinzuzufügen oder zu entfernen. - Erweitern des Projektautomatisierungsobjekts (VSHPROPID_ExtObject) des Projekts. Die obigen Eigenschaftswerte werden aus __VSHPROPID2 der Aufzählung übernommen. |
| IVsCfgBrowseObject | Ermöglicht dem Projektuntertyp die Zuordnung zum IVsCfg Objekt aufgrund des Projektkonfigurations-Browseobjekts. |
| IVsBrowseObject | Ermöglicht dem Projektuntertyp die Zuordnung zum IVsHierarchy Objekt oder VSITEMID objekt, wenn das Projektkonfigurations-Browseobjekt verwendet wird. |
| IPersistXMLFragment | Ermöglicht dem Projektuntertyp, beliebige strukturierte XML-Daten in der Projektdatei (.vbproj oder .csproj) beizubehalten. Diese Daten sind für MSBuild nicht sichtbar. |
| IVsBuildPropertyStorage | Ermöglicht dem Projektuntertyp Folgendes: - Fügen Sie neue MSBuild-Eigenschaften hinzu, die beibehalten werden sollen. - Entfernen Sie unnötige Eigenschaften aus MSBuild. - Abfrage nach einem aktuellen Wert einer MSBuild-Eigenschaft. - Ändern sie den aktuellen Wert einer MSBuild-Eigenschaft. |