VSPackage-Setupszenarien
Es ist wichtig, Ihr VSPackage-Installationsprogramm für Flexibilität zu entwerfen. Beispielsweise müssen Sie in Zukunft möglicherweise einen Sicherheitspatch freigeben, oder Sie können eine Geschäftsstrategie ändern, die eine umfassende Parallelversionsunterstützung erfordert.
Wenn Sie mehrere Versionen von Visual Studio unterstützen, können Sie sich über die Vorteile und Probleme der Unterstützung von parallelen Installationen von Visual Studio mit gemeinsam genutzten oder parallelen Installationen Ihrer VSPackage informieren. Kurz gesagt bieten VSPackages die größte Flexibilität, um neue Features von Visual Studio zu unterstützen.
Die in diesem Thema behandelten Szenarien sind nicht Ihre einzigen Optionen, sondern sie werden als vorgeschlagene bewährte Methoden vorgestellt.
Komponenten, Datenschutz und Freigabe
Machen Sie Ihre Komponenten unabhängig
Sobald Sie eine Komponente identifizieren und auffüllen, eine GUIDKomponente zuweisen und die Komponente bereitstellen, können Sie die Zusammensetzung nicht mehr ändern. Wenn Sie die Komposition einer Komponente ändern, muss es sich bei der resultierenden Komponente um eine neue Komponente mit einer neuen GUIDKomponente handelt. Angesichts dieser Tatsachen wird die größte Flexibilität bei der Versionsverwaltung durch unabhängige, eigenständige Komponenten ermöglicht. Weitere Informationen zu Regeln für Komponenten finden Sie unter Ändern des Komponentencodes und Was geschieht, wenn die Komponentenregeln fehlerhaft sind.
Gemeinsame und private Ressourcen in einer Komponente nicht kombinieren
Die Verweiszählung erfolgt auf Komponentenebene. Das Mischen von freigegebenen und privaten Ressourcen in einer Komponente macht es daher unmöglich, private Ressourcen wie eine ausführbare Datei zu aktualisieren, ohne auch freigegebene Ressourcen zu überschreiben. Dieses Szenario erstellt Abwärtskompatibilitätsprobleme und schränkt Sie daran ein, parallele Funktionen zu erstellen.
Registrierungswerte, die zum Registrieren Von VSPackage beim Visual Studio SDK verwendet werden, sollten z. B. getrennt von einer Komponente gespeichert werden, die zum Registrieren Ihres VSPackage bei Visual Studio verwendet wird. Freigegebene Dateien oder Registrierungswerte werden in eine weitere Komponente verschoben.
Szenario 1: Freigegebenes VSPackage
In diesem Szenario wird ein freigegebenes VSPackage (eine einzelne Binärdatei, die mehrere Versionen von Visual Studio unterstützt, in einem Windows Installer-Paket ausgeliefert. Die Registrierung bei jeder Version von Visual Studio wird durch vom Benutzer ausgewählte Features gesteuert. Dies bedeutet auch, dass jede Komponente, wenn sie separaten Features zugewiesen wird, einzeln für die Installation oder Deinstallation ausgewählt werden kann und der Benutzer die Kontrolle über die Integration des VSPackage in verschiedene Versionen von Visual Studio hat. (Siehe Windows Installer-Features für weitere Informationen zur Verwendung von Features in Windows Installer-Paketen.)
Wie in der Abbildung gezeigt, werden freigegebene Komponenten Teil des features Feat_Common, das immer installiert ist. Indem die Feat_VS2002 und Feat_VS2003 Features sichtbar werden, können Benutzer zur Installationszeit auswählen, in welche Versionen von Visual Studio das VSPackage integriert werden soll. Benutzer können auch den Windows Installer Standard Modus verwenden, um Features hinzuzufügen oder zu entfernen. In diesem Fall werden die VSPackage-Registrierungsinformationen aus verschiedenen Versionen von Visual Studio hinzugefügt oder entfernt.
Hinweis
Wenn Sie die Anzeigespalte eines Features auf "0" festlegen, wird sie ausgeblendet. Ein Spaltenwert auf niedriger Ebene, z. B. 1, stellt sicher, dass er immer installiert wird. Weitere Informationen finden Sie unter INSTALLLEVEL-Eigenschaft und Featuretabelle.
Szenario 2: Freigegebenes VSPackage-Update
In diesem Szenario wird eine aktualisierte Version des VSPackage-Installers in Szenario 1 ausgeliefert. Aus Gründen der Diskussion fügt das Update Unterstützung für Visual Studio hinzu, kann aber auch ein einfacherer Sicherheitspatch oder ein Bug-Fix Service Pack sein. Die Regeln von Windows Installer für die Installation neuerer Komponenten erfordern, dass unveränderte Komponenten, die bereits auf dem System vorhanden sind, nicht erneut kopiert werden. In diesem Fall überschreibt ein System mit version 1.0 bereits vorhanden die aktualisierte Komponente Comp_MyVSPackage.dll und ermöglicht es Benutzern, das neue Feature Feat_VS2005 mit der Komponente Comp_VS2005_Reg hinzuzufügen.
Achtung
Wenn ein VSPackage von mehreren Versionen von Visual Studio gemeinsam genutzt wird, ist es wichtig, dass nachfolgende Versionen von VSPackage Standard Abwärtskompatibilität mit früheren Versionen von Visual Studio beibehalten. Wenn Sie die Abwärtskompatibilität nicht Standard können, müssen Sie private VSPackages nebeneinander verwenden. Weitere Informationen finden Sie unter Unterstützen mehrerer Versionen von Visual Studio.
In diesem Szenario wird ein neues VSPackage-Installationsprogramm präsentiert, das die Unterstützung von Windows Installer für kleinere Upgrades nutzt. Benutzer installieren einfach Version 1.1 und aktualisieren Version 1.0. Es ist jedoch nicht erforderlich, Version 1.0 auf dem System zu verwenden. Dasselbe Installationsprogramm installiert Version 1.1 auf einem System ohne Version 1.0. Der Vorteil, kleinere Upgrades auf diese Weise bereitzustellen, besteht darin, dass es nicht notwendig ist, die Arbeit der Entwicklung eines Upgradeinstallationsprogramms und eines Vollproduktinstallationsprogramms zu durchlaufen. Ein Installationsprogramm führt beide Aufträge aus. Ein Sicherheitspatch oder Service Pack kann stattdessen Windows Installer-Patches nutzen. Weitere Informationen finden Sie unter Patching und Upgrades.
Szenario 3: Paralleles VSPackage
Dieses Szenario enthält zwei VSPackage-Installationsprogramme – eine für jede Version von Visual Studio .NET 2003 und Visual Studio. Jedes Installationsprogramm installiert eine parallele oder private VSPackage (eine, die speziell für eine bestimmte Version von Visual Studio erstellt und installiert ist). Jedes VSPackage befindet sich in einer eigenen Komponente. Folglich kann jeder einzeln mit Patches oder Standard tenance-Versionen gewartet werden. Da die VSPackage-DLL jetzt versionsspezifisch ist, ist es sicher, ihre Registrierungsinformationen in dieselbe Komponente wie die DLL einzuschließen.
Jedes Installationsprogramm enthält auch Code, der zwischen den beiden Installationsprogrammen geteilt wird. Wenn der freigegebene Code an einem gemeinsamen Speicherort installiert ist, wird beim Installieren beider MSI-Dateien der freigegebene Code nur einmal installiert. Das zweite Installationsprogramm erhöht lediglich eine Referenzanzahl für die Komponente. Die Referenzanzahl stellt sicher, dass der freigegebene Code für das andere VSPackage-Objekt erneut Standard wird, wenn einer der VSPackages deinstalliert wird. Wenn auch das zweite VSPackage deinstalliert wird, wird der freigegebene Code entfernt.
Szenario 4: Paralleles VSPackage Update
In diesem Szenario litt Ihr VSPackage für Visual Studio unter einer Sicherheitslücke, und Sie müssen ein Update ausstellen. Wie in Szenario 2 können Sie eine neue MSI-Datei erstellen, die eine vorhandene Installation aktualisiert, um den Sicherheitsfix einzuschließen, sowie neue Installationen mit dem bereits vorhandenen Sicherheitsfix bereitzustellen.
In diesem Fall ist vsPackage ein verwaltetes VSPackage, das im globalen Assemblycache (GAC) installiert ist. Wenn Sie ihn neu erstellen, um den Sicherheitsfix einzuschließen, müssen Sie den Revisionsnummerteil der Assemblyversionsnummer ändern. Die Registrierungsinformationen für die neue Assemblyversionsnummer überschreiben die vorherige Version, wodurch Visual Studio die feste Assembly lädt.
Weitere Informationen zur Bereitstellung von parallelen Assemblys finden Sie unter Vereinfachen der Bereitstellung und Lösung von DLL Hell mit .NET Framework.