Uma custom action é uma ação feita geralmente em código a parte do XML do WiX, seja ele em C++, C# e o que der para gerar uma DLL. O uso de uma custom action pode ser para realizar verificações customizadas no qual o instalador não teria capacidade de realizar forma nativa.
Primeira e segunda fase de instalação
O ideal é fazer a custom actions na primeira fase da instalação, este seria entendido desde o começo da instalação até o ponto antes de clicar em instalar. Quando a instalação começa a ser realizada (cópia de arquivos, instalação de serviços e controladores de dispositivos), já estamos na segunda fase da instalação. Neste ponto algumas propriedades já não estão mais disponíveis para uso.
Custom Action Data
Apesar de não ser recomendado, na segunda fase da instalação é que entra a questão do Custom Action Data. Como as propriedades não estão disponíveis, como ter acesso a elas?
Um exemplo: Rodar um processo e fazer uma verificação durante a segunda fase com base nos dados coletados em uma interface (na primeira fase).
A declaração do código seria algo parecido com o trecho:
É necessário a declaração de duas custom actions, uma que define a propriedade a ser acessada e a outra faz a chamada do processo e a verificação.
Pode se reparar que apesar delas estarem juntas, uma ação é executada na primeira fase e a outra somente na segunda.
Dentro da custom action CriarProcessoMaroto, como conseguir acessar o dado passado pela DadosDoProcessoMaroto?
Acessando os valores na DLL
Se estiver tudo bem, a custom action CriarProcessoMaroto terá acesso a uma propriedade chamada CustomActionData, onde estará o conteúdo da propriedade VALORESIMPORTANTES, vale ressaltar que isto é só uma cópia, não uma referência.
Na DLL onde está o CriarProcessoMaroto pode se acessar a CustomActionData com a função MsiGetProperty:
UINT er = MsiGetProperty(hInstall, "CustomActionData", szValueBuf, NULL);
Finalmente será possível utilizar o valor para fazer o instalador funcionar.
A verificação através do log do instalador consegue esclarecer se o que foi feito está funcionando de forma adequada. As duas custom actions deverão ser chamadas, cada uma em sua fase, mas quando a custom action CriarProcessoMaroto for chamada, aparecerá a propriedade CustomActionData como parâmetro.
Quem não sabe, a Microsoft anda nessa onda de código aberto com alguns projetos como o Wix (gerador de instaladores com formato Windows Installer).
Wix
O projeto foi inicialmente feito pensando no Office. Hoje suporta qualquer customização.
O Windows Installer contém uma biblioteca de instalação e gerenciamento de componentes para controlar os arquivos instalados. O Wix entra na jogada para fazer a interface com esta biblioteca através de declarações XML.
Requerimento
Ter um Windows, já que da forma apresentada ainda não é possível gerar o MSI pelo Linux. Quem sabe no futuro.
Antes de começar, para conseguir trabalhar de forma razovel com os pacotes do Windows Installer, o mínimo requerido em sistemas operacionais é o Windows XP (com Service Pack 3), em termos de quantidade de usuários ativos com este sistema é misterioso (um exemplo interessante de requerimento mínimo em sistema operacional é o Android, eles tem um gráfico representando usuários com o sistema deles). Voltando ao Windows, um dia foi o NT, outra o 2000 e agora é a vez do XP.
Não quer dizer que um instalador simples não irá funcionar no Windows 2000, o requerimento serve para delimitar o que será usado de funcionalidade no MSI. Este limite do Windows XP permite trabalhar com o sistema de patches do Windows Installer, chamados MSP. Consiste basicamente em um delta binário da versão antiga para a nova, economizando uns bons megas para serem baixados. Ainda existe conexão ruim neste mundo.
Como fazer?
O tutorial do site da Firegiant é detalhada, para conseguir gerar um pequeno instalador e fazer algumas brincadeiras (instalar serviços e criar pastas no Arquivos de Programas) bem explicativo seguindo o passo a passo, ensina inclusive a geração de patches.
Estruturas e nomes estranhos
Com o XML, além das declarações e atributos, também é usado GUID para cada componente (o componente é o arquivo que ser instalado). Também é usado GUID no identificador do produto e no identificador de atualização.
Os componentes podem ser agrupados e também organizados por funcionalidade (feature).
Podemos ter vários arquivos wxs, wxi, wxl para gerar um instalador.
O TARGETDIR é o local onde estão os arquivos para montar o instalador, toma como ponto de partida o local do projeto que seria o SourceDir (isto é fixo).
Caso queira criar uma pasta vazia, crie um componente vazio com a declaração de CreateFolder.
Se for instalar os arquivos em uma estrutura fora do padrão dos programas do Windows, ser necessário o uso do GUID para cada componente de forma estática. Caso use as estruturas padres (Arquivos de Programas, AppData, etc.) pode se usar o gerador automático. O Wix tem o Heat.exe que auxilia na coleta de componentes e gera os arquivos wxs automaticamente.
Versionamento
Além dos patches, apesar de existir a forma tradicional de atualizar os arquivos pelo minor, os próprios desenvolvedores sugerem o uso do MajorVersion, não que seja obrigatório incrementar os projetos pelo Major (1.0.0.0 para 2.0.0.0), mas sim atualizar o sistema como se o pacote antigo fosse um instalador totalmente diferente, assim o sistema detecta a versão nova, desinstala a antiga e instala a nova.
Isto implica em ter um identificador de produto diferente para cada instalador gerado, porém o identificador de atualização sempre manter o mesmo. Para gerar automaticamente o GUID do identificador do produto somente insira um asterisco no campo Id.
Sem telas?
Uma vez com estas partes definidas é possível tambm utilizar um modelo para as telas de instalação, simples de serem chamadas (caso não tenha customizações em mente).
A ideia é que se o instalador funciona silenciosamente bem, com a interface gráfica funcionar da mesma forma, afinal de contas deve ser somente uma interface.
Propriedades e peculiaridades
Se o instalador necessita de alguma informação na forma silenciosa, ela pode ser passada via linha de comando pela Property.
Inserir muitas CustomAction (ações customizadas por DLL ou chamada de executável / script) que modifiquem muito o sistema não é bom, pelo fato do sistema perder a capacidade de reverter estas ações automaticamente, conhecido como rollback.