Cenários de instalação do VSPackage
É importante projetar seu instalador VSPackage para flexibilidade. Por exemplo, talvez seja necessário lançar um patch de segurança no futuro ou alterar uma estratégia de negócios que exija suporte completo de controle de versão lado a lado.
Em Dando suporte a várias versões do Visual Studio, você pode ler sobre as vantagens e problemas de oferecer suporte a instalações lado a lado do Visual Studio com instalações compartilhadas ou lado a lado do seu VSPackage. Em suma, os VSPackages lado a lado oferecem a você a maior flexibilidade para oferecer suporte a novos recursos do Visual Studio.
Os cenários discutidos neste tópico não são suas únicas opções, mas são apresentados como práticas recomendadas sugeridas.
Componentes, privacidade e compartilhamento
Torne seus componentes independentes
Depois de identificar e preencher um componente, atribuir um GUIDe implantar o componente, não será possível alterar sua composição. Se você alterar a composição de um componente, o componente resultante deverá ser um novo componente com um novo GUID. Diante desses fatos, a maior flexibilidade de controle de versão é proporcionada ao tornar cada componente independente e unidade autossuficiente. Para obter mais informações sobre regras que regem componentes, consulte Alterando o código do componente e O que acontece se as regras do componente forem quebradas?.
Não misture recursos compartilhados e privados em um componente
A contagem de referência ocorre no nível do componente. Consequentemente, a mistura de recursos compartilhados e privados em um componente torna impossível atualizar recursos privados, como um arquivo executável, sem também substituir recursos compartilhados. Esse cenário cria problemas de compatibilidade com versões anteriores e restringe a criação de recursos lado a lado.
Por exemplo, os valores do Registro usados para registrar seu VSPackage com o SDK do Visual Studio devem ser mantidos em um componente separado de um usado para registrar seu VSPackage com o Visual Studio. Arquivos compartilhados ou valores do Registro vão em outro componente.
Cenário 1: VSPackage compartilhado
Nesse cenário, um VSPackage compartilhado (um único binário que oferece suporte a várias versões do Visual Studio é fornecido em um pacote do Windows Installer. O registro com cada versão do Visual Studio é controlado por recursos selecionáveis pelo usuário. Isso também significa que, quando atribuído a recursos separados, cada componente pode ser selecionado individualmente para instalação ou desinstalação, colocando o usuário no controle da integração do VSPackage em diferentes versões do Visual Studio. (Veja Recursos do Windows Installer para obter mais informações sobre como usar recursos em pacotes do Windows Installer.)
Como mostrado na ilustração, os componentes compartilhados fazem parte do recurso Feat_Common, que é sempre instalado. Tornando os recursos Feat_VS2002 e Feat_VS2003 visíveis, os usuários podem escolher em tempo de instalação em quais versões do Visual Studio eles desejam que o VSPackage se integre. Os usuários também podem usar o modo de manutenção do Windows Installer para adicionar ou remover recursos, o que, nesse caso, adiciona ou remove as informações de registro do VSPackage de diferentes versões do Visual Studio.
Observação
Definir a coluna Display de um recurso como 0 o oculta. Um valor de coluna de nível baixo, como 1, garante que ele sempre será instalado. Para obter mais informações, consulte Propriedade INSTALLLEVEL e Tabela de recursos.
Cenário 2: Atualização compartilhada do VSPackage
Nesse cenário, uma versão atualizada do instalador VSPackage no cenário 1 é enviada. Para fins de discussão, a atualização adiciona suporte para Visual Studio, mas também pode ser um patch de segurança mais simples ou service pack de correção de bugs. As regras do Windows Installer para instalar componentes mais recentes exigem que os componentes inalterados que já estão no sistema não sejam recopiados. Nesse caso, um sistema com a versão 1.0 já presente substituirá o componente atualizado Comp_MyVSPackage.dll e permitirá que os usuários optem por adicionar o novo recurso Feat_VS2005 com seu componente Comp_VS2005_Reg.
Cuidado
Sempre que um VSPackage é compartilhado entre várias versões do Visual Studio, é essencial que as versões subsequentes do VSPackage mantenham a compatibilidade com versões anteriores do Visual Studio. Onde não for possível manter a compatibilidade com versões anteriores, você deverá usar VSPackages privados lado a lado. Para obter mais informações, consulte Dando suporte a várias versões do Visual Studio.
Este cenário apresenta um novo instalador VSPackage, aproveitando o suporte do Windows Installer para atualizações secundárias. Os usuários simplesmente instalam a versão 1.1 e ela atualiza a versão 1.0. No entanto, não é necessário ter a versão 1.0 no sistema. O mesmo instalador instalará a versão 1.1 em um sistema sem a versão 1.0. A vantagem de fornecer pequenas atualizações dessa maneira é que não é necessário passar pelo trabalho de desenvolver um instalador de atualização e um instalador de produto completo. Um instalador faz os dois trabalhos. Uma correção de segurança ou service pack pode, em vez disso, tirar proveito dos patches do Windows Installer. Para obter mais informações, consulte Patch e atualizações.
Cenário 3: VSPackage lado a lado
Este cenário apresenta dois instaladores VSPackage — um para cada versão do Visual Studio .NET 2003 e Visual Studio. Cada instalador instala um VSPackage lado a lado, ou privado, (um que é especificamente criado e instalado para uma versão específica do Visual Studio). Cada VSPackage está em seu próprio componente. Consequentemente, cada um pode ser atendido individualmente com patches ou versões de manutenção. Como a DLL VSPackage agora é específica da versão, é seguro incluir suas informações de registro no mesmo componente que a DLL.
Cada instalador também inclui código que é compartilhado entre os dois instaladores. Se o código compartilhado for instalado em um local comum, a instalação de ambos os arquivos .msi instalará o código compartilhado apenas uma vez. O segundo instalador apenas incrementa uma contagem de referência no componente. A contagem de referência garante que, se um dos VSPackages for desinstalado, o código compartilhado permanecerá para o outro VSPackage. Se o segundo VSPackage também for desinstalado, o código compartilhado será removido.
Cenário 4: Atualização do VSPackage lado a lado
Nesse cenário, seu VSPackage para Visual Studio sofreu de uma vulnerabilidade de segurança e você precisa emitir uma atualização. Como no cenário 2, você pode criar um novo arquivo de .msi que atualiza uma instalação existente para incluir a correção de segurança, bem como implantar novas instalações com a correção de segurança já em vigor.
Nesse caso, o VSPackage é um VSPackage gerenciado instalado no cache de assembly global (GAC). Ao recriá-lo para incluir a correção de segurança, você deve alterar a parte do número de revisão do número da versão do assembly. As informações de registro para o novo número de versão do assembly substitui a versão anterior, fazendo com que o Visual Studio carregue o assembly fixo.
Para obter mais informações sobre a implantação de assemblies lado a lado, consulte Simplificando a implantação e resolvendo o inferno de DLL com o .NET Framework.