Mudar a minha GUID componente no Wix?

Question

Quando devo mudar ou não mudar o meu GUID componente na WIX? As informações Microsoft SDK é confuso .

Glytzhkof edit : Para esclarecer, a pergunta lida com quando um GUID componente deve ser alterado para um componente MSI. Um componente pode mudar com aspectos tais como: caminho mudou de destino, adição ou remoção de arquivos de / para o mesmo componente, além de dados de registro etc ... Isso causa problemas com relação à assim chamada referência componente, ou seja, a melhores práticas para a criação de componentes no MSI.

Answer 1

O conceito geral da MSI é que há um 1: 1 mapeamento entre GUID componente (identificador único) e um caminho absoluto (Local de instalação / key path). O caminho completo, incluindo o nome do arquivo se qualquer. Veja update abaixo para um novo recurso Wix para lidar auto-magicamente com isso.

Eu uso um pouco regras simples para lidar com as regras de componentes excessivamente complexos e sem sentido:

• Use sempre um componente separado por arquivo (mesmo para os não-binários). Isso evita todos os tipos de problemas. Há poucas exceções:
  • Multi-arquivo NET assembléias devem ser todos em um componente já que eles devem sempre ser instalados / desinstalados como uma unidade única.
  • Alguns tipos outro, arquivo geral vêm em "pares" - eles pertencem um ao outro. Muitas vezes estes são de conteúdo e índice arquivos. Como exemplo, considere arquivos de ajuda da Microsoft:
    arquivos
    • .HLP e .cnt pertencem juntos.
    arquivos
    • CHM e .chi pertencem juntos.
  • Há provavelmente vários desses tipos de arquivos que devem estar juntos e devem, portanto, ser colocados no mesmo componente para que eles instalar / desinstalar juntos - eu suspeito que certos arquivos de certificado para ser candidatos. É difícil chegar a uma lista definitiva. Basta perguntar a si mesmo "fazer esses arquivos sempre Belong Together" - para que eles sempre aparecem em pares sempre que há uma nova versão? Se sim, então instalá-los através do mesmo componente. Defina o arquivo de controle de versão, se houver, como arquivo de chave.
  • Eu quero adicionar arquivos motorista como um exemplo de um monte de arquivos sempre que pertencem juntos: SampleDriver.cat , SampleDriver.inf , SampleDriver.sys , SampleDriver.cer . Eles devem todo o jogo como uma "unidade" para implantação.
• Lembre-se que depois de ter atribuído um GUID para um componente, ele é definido em pedra para caminho da chave desse componente (caminho absoluto). Se você mover o arquivo para um novo local ou renomear o arquivo, dar-lhe um novo GUID componente (uma vez que o caminho absoluto é diferente é efetivamente uma nova identidade).
• Em GUIDs de componente de resumo estão vinculados a um local de instalação absoluta, e não para um arquivo específico. O GUID não segue o arquivo de volta se ele se move . As contagens de referência GUID uma localização absoluta, não o arquivo em si.
• Não adicionar ou remover arquivos de um componente existente. Todos os tipos de problemas de atualização e patches resultar. É por isso que eu como um arquivo por componente como uma regra geral.
• Não há muito mais a referenciação componente, mas eu vou deixar por isso mesmo para uma "visão geral".

Algumas amostras:

• Você renomear o arquivo C: \ Program Files \ MyCompany \ MyApp \ MyFile.exe para C: \ Program Files \ MyCompany \ MyApp \ MyFile_NEW.exe . O que isso significa para a criação de componentes? Este é um novo caminho de instalação absoluta, de modo a gerar um novo GUID para o componente de hospedagem, ou adicionar um novo componente e apagar o antigo (que tem o mesmo efeito).
• O seu MSI atualizados oferece uma nova versão do MyFile.exe. A localização é a mesma de antes, isto significa que o GUID componente não deve mudar. É o mesmo arquivo (identidade), apenas em uma versão diferente.

---

Atualizar : WIX tem agora um novo auto-gerar GUID componente recurso que calcula um GUID , enquanto as estadias caminho de destino da mesma. Eu não tentei isso para ser honesto, mas muitos parecem usá-lo sem problemas, e Rob Mensching (Wix autor) afirma que é seguro para uso normal . Como um conceito que eu recomendo este, uma vez que apresenta alguns auto-mágicos e escudos você de alguma complexidade.

Observe também que você pode deixar de fora um monte de fonte atributos de seu arquivo xml Wix e dependem de padrões Wix em vez de valores de codificação de disco rígido.

Answer 2

Você nunca mudar o Componente / @ Guid. Você também nunca alterar o conjunto de Recursos (File, RegistryKey, Atalho, TypeLib, etc.) no componente. Quando você tem um novo recurso, é necessário criar um novo componente com um novo @Guid. A parte realmente complicada é que o novo componente pode ter nenhuma sobreposição (acho que o caminho do arquivo ou caminho chave do Registro, ou typelib, etc.) com o velho componente.

Estas são basicamente as regras Component, confira: http: //robmensching.com/blog/posts/2003/10/18/Component-Rules-101 .

Answer 3

Tenha um olhar para o WiX Tutorial, os arquivos dentro, para uma explicação detalhada sobre as regras de componentes. Basicamente, ele diz que você nunca mudar o GUID de um componente, uma vez que os meios orphaning o antigo componente e criar um novo componente.