Scenari di installazione di pacchetti VSPackage
È importante progettare il programma di installazione vsPackage per una maggiore flessibilità. Ad esempio, potrebbe essere necessario rilasciare una patch di sicurezza in futuro oppure modificare una strategia aziendale che richiede un supporto completo per il controllo delle versioni side-by-side.
In Supporto di più versioni di Visual Studio è possibile leggere i vantaggi e i problemi relativi al supporto delle installazioni side-by-side di Visual Studio con installazioni condivise o side-by-side del pacchetto VSPackage. In breve, i VSPackage side-by-side offrono la massima flessibilità per supportare nuove funzionalità di Visual Studio.
Gli scenari illustrati in questo argomento non sono le uniche scelte, ma vengono presentate come procedure consigliate.
Componenti, privacy e condivisione
Rendere indipendenti i componenti
Dopo aver identificato e popolato un componente, assegnare un GUIDe distribuire il componente, non è possibile modificarne la composizione. Se si modifica la composizione di un componente, il componente risultante deve essere un nuovo componente con un nuovo GUIDoggetto . Dato questi fatti, la massima flessibilità di controllo delle versioni è offerta rendendo ogni componente indipendente, unità autonoma. Per altre informazioni sulle regole che regolano i componenti, vedere Modifica del codice del componente e Cosa accade se le regole del componente sono interrotte?.
Non combinare risorse condivise e private in un componente
Il conteggio dei riferimenti si verifica a livello di componente. Di conseguenza, la combinazione di risorse condivise e private in un unico componente rende impossibile aggiornare le risorse private, ad esempio un file eseguibile, senza sovrascrivere anche le risorse condivise. Questo scenario crea problemi di compatibilità con le versioni precedenti e impedisce la creazione di funzionalità side-by-side.
Ad esempio, i valori del Registro di sistema usati per registrare il vsPackage con Visual Studio SDK devono essere mantenuti in un componente separato da quello usato per registrare il vsPackage con Visual Studio. I file condivisi o i valori del Registro di sistema vengono inseriti in un altro componente.
Scenario 1: VSPackage condiviso
In questo scenario, un PACCHETTO VSPackage condiviso (un singolo file binario che supporta più versioni di Visual Studio viene fornito in un pacchetto di Windows Installer. La registrazione con ogni versione di Visual Studio è controllata dalle funzionalità selezionabili dall'utente. Significa anche che, quando assegnato a funzionalità separate, ogni componente può essere selezionato singolarmente per l'installazione o la disinstallazione, mettendo l'utente in controllo dell'integrazione del VSPackage in versioni diverse di Visual Studio. (Vedere Funzionalità di Windows Installer per altre informazioni sull'uso delle funzionalità nei pacchetti di Windows Installer.
Come illustrato nella figura, i componenti condivisi fanno parte della funzionalità di Feat_Common, che viene sempre installata. Rendendo visibili le funzionalità di Feat_VS2002 e Feat_VS2003, gli utenti possono scegliere in fase di installazione in quali versioni di Visual Studio vogliono integrare il pacchetto VSPackage. Gli utenti possono anche usare la modalità di manutenzione di Windows Installer per aggiungere o rimuovere funzionalità, che in questo caso aggiungono o rimuovono le informazioni di registrazione vsPackage da versioni diverse di Visual Studio.
Nota
L'impostazione della colonna Display di una funzionalità su 0 lo nasconde. Un valore di colonna di basso livello, ad esempio 1, garantisce che venga sempre installato. Per altre informazioni, vedere La proprietà INSTALLLEVEL e la tabella delle funzionalità.
Scenario 2: Aggiornamento vspackage condiviso
In questo scenario viene fornita una versione aggiornata del programma di installazione vsPackage nello scenario 1. Per motivi di discussione, l'aggiornamento aggiunge il supporto per Visual Studio, ma potrebbe anche essere una patch di sicurezza più semplice o un Service Pack di correzione di bug. Le regole di Windows Installer per l'installazione di componenti più recenti richiedono che i componenti non modificati già presenti nel sistema non vengano copiati nuovamente. In questo caso, un sistema con la versione 1.0 già presente sovrascriverà il componente aggiornato Comp_MyVSPackage.dll e consente agli utenti di aggiungere la nuova funzionalità Feat_VS2005 con il relativo componente Comp_VS2005_Reg.
Attenzione
Ogni volta che un VSPackage viene condiviso tra più versioni di Visual Studio, è essenziale che le versioni successive di VSPackage mantengano la compatibilità con le versioni precedenti di Visual Studio. Se non è possibile mantenere la compatibilità con le versioni precedenti, è necessario usare pacchetti VSPackage privati side-by-side. Per altre informazioni, vedere Supporto di più versioni di Visual Studio.
Questo scenario presenta un nuovo programma di installazione VSPackage, sfruttando il supporto di Windows Installer per gli aggiornamenti secondari. Gli utenti installano semplicemente la versione 1.1 e aggiornano la versione 1.0. Tuttavia, non è necessario avere la versione 1.0 nel sistema. Lo stesso programma di installazione installerà la versione 1.1 in un sistema senza la versione 1.0. Il vantaggio di fornire aggiornamenti secondari in questo modo è che non è necessario eseguire il lavoro di sviluppo di un programma di installazione di aggiornamento e di un programma di installazione completo del prodotto. Un programma di installazione esegue entrambi i processi. Una correzione di sicurezza o un Service Pack potrebbe invece sfruttare i vantaggi delle patch di Windows Installer. Per altre informazioni, vedere Applicazione di patch e aggiornamenti.
Scenario 3: Side-by-Side VSPackage
Questo scenario presenta due programmi di installazione VSPackage, uno per ogni versione di Visual Studio .NET 2003 e Visual Studio. Ogni programma di installazione installa un PACCHETTO VSPackage side-by-side o privato(uno appositamente compilato e installato per una versione specifica di Visual Studio). Ogni VSPackage si trova nel proprio componente. Di conseguenza, ognuno può essere distribuito singolarmente con patch o versioni di manutenzione. Poiché la DLL VSPackage è ora specifica della versione, è possibile includere le informazioni di registrazione nello stesso componente della DLL.
Ogni programma di installazione include anche codice condiviso tra i due programmi di installazione. Se il codice condiviso viene installato in un percorso comune, l'installazione di entrambi i file msi installerà il codice condiviso una sola volta. Il secondo programma di installazione incrementa semplicemente un conteggio dei riferimenti sul componente. Il conteggio dei riferimenti garantisce che, se uno dei pacchetti VSPackage viene disinstallato, il codice condiviso rimarrà per l'altro VSPackage. Se viene disinstallato anche il secondo VSPackage, il codice condiviso verrà rimosso.
Scenario 4: Aggiornamento di VSPackage side-by-side
In questo scenario il pacchetto VSPackage per Visual Studio ha subito una vulnerabilità di sicurezza ed è necessario eseguire un aggiornamento. Come nello scenario 2, è possibile creare un nuovo file msi che aggiorna un'installazione esistente per includere la correzione di sicurezza, nonché distribuire nuove installazioni con la correzione di sicurezza già disponibile.
In questo caso, il VSPackage è un VSPackage gestito installato nella Global Assembly Cache (GAC). Quando si ricompila per includere la correzione di sicurezza, è necessario modificare la parte del numero di revisione del numero di versione dell'assembly. Le informazioni di registrazione per il nuovo numero di versione dell'assembly sovrascrivono la versione precedente, causando il caricamento dell'assembly fisso da parte di Visual Studio.
Per altre informazioni sulla distribuzione di assembly side-by-side, vedere Semplificare la distribuzione e risolvere l'errore DLL con .NET Framework.