Como fazer melhor uso dos arquivos MSI

Como você deve saber, msiexec é um aplicativo de linha de comando que você pode usar para instalar um arquivo MSI. Como você deve saber, você pode executá-lo no modo silencioso ou invisível.

Se o instalador exigir que o usuário responda a perguntas específicas sobre quais partes instalar, existe alguma maneira de colocar na linha de comando msiexec uma série de opções para fazer isso?

Eu acho que deve haver algum tipo de configuração das configurações padrão do arquivo MSI para que isso aconteça. Como os arquivos MSI são feitos? Eles são desenvolvidos através de ferramentas da Microsoft? Eles podem ser abertos e editados?

Pense na interface do usuário com o MSI como opcional . Isso significa que nenhuma resposta deve ser necessária, pois o desenvolvedor tem padrões sensatos no lugar para que as coisas não sejam interrompidas.

Distribuímos nosso software no formato MSI para clientes corporativos, também fornecemos documentação sobre os fundamentos do Orca (o orca.msi é distribuído com o SDK do Windows Installer ) e como personalizar determinados campos que listamos na tabela de Property para sua instalação. . Como número de série, detalhes de registro e algumas outras configurações.

Em resposta à pergunta original sobre opções de linha de comando do msiexec, execute o MSIEXEC /? para definir propriedades na linha de comando você usaria algo como

 MSIEXEC /I test.msi SOMEPROPERTY="Some value" PROP2="something else" 

Os arquivos MSI são projetados especificamente para suportar a instalação silenciosa como um recurso interno – você pode sempre ignorar a GUI. No entanto, alguns arquivos MSI têm falhas de design que tornam a instalação incompleta no modo silencioso – o que é um grave erro de design. Esse problema é descrito aqui: Desinstalar no painel de controle é diferente de Remover de .msi .


Configurando Instalações MSI

Quando se trata de instalar um MSI silenciosamente, o que você precisa fazer é configurar a configuração a partir da linha de comando msiexec.exe ou aplicando o que é referido como uma transformação para o arquivo MSI original. Ambas as opções são descritas abaixo em seções separadas.

Se o arquivo MSI for bem projetado, você poderá definir PROPRIEDADES PÚBLICAS (elas são sempre MAIÚSCULAS) da linha de comando msiexec.exe ou usando um arquivo de transformação para modificar o MSI original. Essas operações são descritas abaixo. As propriedades públicas são mais fáceis de encontrar na ” tabela de propriedades ” do arquivo MSI. Use a ferramenta MSI de sua escolha para abrir o arquivo * .msi e navegar até a tabela de propriedades. Existem também algumas ferramentas MSI gratuitas que você pode usar para gerar transformações e visualizar (e editar) arquivos MSI: Como posso comparar o conteúdo de dois (ou mais) arquivos MSI? (links para o fundo).

Configurações MSI bem projetadas são totalmente configuráveis ​​por meio dessas propriedades públicas. Arquivos MSI mal projetados não são. Arquivos MSI mal projetados são melhores para ajustar usando arquivos de transformação (que podem fazer alterações substanciais em todo o arquivo MSI para serem aplicados no momento da instalação). A configuração de propriedades públicas só pode alterar o que é configurável por propriedades públicas, conforme projetado pelo criador da configuração. As transformações podem alterar quase tudo em todo o arquivo MSI .

Em geral, toda implantação silenciosa e corporativa é feita usando transformações para “bater arquivos MSI em forma” para o padrão corporativo. É uma ferramenta muito eficaz para implantação corporativa e é amplamente utilizada.


MSI “Recursos”

A MSI é muitas vezes contraintuitiva e um pouco complicada sob o capô. No entanto, simplificar demais um arquivo MSI contém um ou mais ” Recursos ” – e esses resources constituem coletivamente os ” bits do aplicativo ” como você o coloca. Os resources, por sua vez, consistem em ” Componentes ” – que são as unidades atômicas de instalação de todo o software – mas esse é um detalhe muito técnico – essa resposta é sobre os bits expostos pelo usuário do MSI – os resources.

Geralmente, você pode encontrar uma lista desses resources executando a configuração interativamente e navegue até a checkbox de diálogo de instalação de personalização (nem sempre presente). Os resources mostrados aqui são as partes ” configuráveis ​​pelo usuário ” do aplicativo que podem ser escolhidas para exclusão ou inclusão (algumas são obrigatórias). Você também pode encontrar esses resources abrindo um MSI com uma ferramenta capaz, como mencionado acima (você também pode ver os links na seção 2 abaixo).

As características típicas são: Núcleo ou Programa , Dicionários , Amostras , Plug-Ins , Verificador Ortográfico , SDK e Ferramentas de Desenvolvedor (para ferramentas de desenvolvimento), etc … Alguns resources são obrigatórios (devem ser instalados) – exemplos acima seriam Núcleo e Programa , outros são opcionais e não são necessários para o aplicativo ser iniciado (como os resources das ferramentas de desenvolvimento acima). É possível fazer com que o aplicativo instale resources “sob demanda” – por exemplo, corretores ortocharts quando o usuário inicia uma verificação ortográfica.

Na minha experiência, a maioria dos usuários quer que o aplicativo inteiro seja instalado. Muitos usuários ficam muito irritados se o Windows Installer aparece inesperadamente e começa a instalar os componentes do verificador ortográfico. Francamente muito compreensível. No entanto, componentes modulares raramente usados, interessantes apenas para alguns usuários, podem ser transformados em componentes opcionais – especialmente se os administradores do sistema não quiserem que o recurso esteja disponível em sua rede. Este é certamente o caso das ferramentas para desenvolvedores – elas não devem estar disponíveis para usuários comuns. Eles tendem a ser toda a corda que as pessoas precisam para se atirar no pé.


Como mencionado acima, geralmente há duas maneiras de personalizar uma instalação MSI : (1) usando linhas de comando customizadas msiexec.exe ou usando (2) arquivos de transformação .


1: linha de comando do msiexec.exe :

A maneira mais simples e leve de controlar quais resources são instalados durante uma instalação é especificar a seleção de resources usando a msiexec.exe comando msiexec.exe . Há toda uma família de propriedades usadas para configuração de resources. Mas, na maioria dos casos, é suficiente especificar ADDLOCAL :

 msiexec.exe /i myinstaller.msi ADDLOCAL="Program,Dictionaries" /qn 

A linha de comando acima especifica que os resources ” Programa ” e ” Dicionários ” devem ser instalados localmente ( nomes de resources são sensíveis a maiúsculas e minúsculas! ). Isso geralmente é suficiente, mas você também pode especificar os resources que deseja remover usando a propriedade REMOVE de maneira semelhante. Um comutador especial é ADDLOCAL=ALL que instalará todos os resources no MSI no disco local (desde que não haja lógica adicional no MSI para replace isso). Propriedade ADDLOCAL no MSDN .

Uma coisa muito comum para definir por propriedades públicas é a chave de licença para o aplicativo. A seguinte linha de comando especifica para instalar os resources ” Programa ” e ” Dicionários ” e para aplicar a chave serial “1234-1234”:

 msiexec.exe /i myinstaller.msi ADDLOCAL="Program,Dictionaries" SERIALKEY="1234-1234" /qn 

Como está implícito na descrição acima, a lista de propriedades personalizáveis ​​para cada configuração é sempre diferente . Você pode encontrar a maioria das propriedades listadas na tabela de propriedades do arquivo MSI, mas também é possível que algumas propriedades possam ser definidas e não estejam definidas na tabela de propriedades. Na maioria dos casos, isso está relacionado às propriedades que estão sendo definidas somente a partir da GUI de configuração (indica um erro de design de configuração na maioria dos casos). Todas as propriedades devem ser definidas na tabela de propriedades em um pacote adequadamente criado.

Procure documentação na página de download do fornecedor e peça o suporte deles para qualquer documento relacionado à instalação silenciosa ou à implantação em grande escala . É rápido de fazer e as respostas podem ser rápidas se tiverem modelos de resposta padrão. As empresas com controle de sua implantação sempre poderão fornecer isso . Na minha opinião, a maneira ideal é um PDF de uma página que descreve diferentes configurações de implantação. Francamente, dê-lhes algum calor, se eles não podem fornecer isso ;-).


2: transforma :

Os arquivos MSI são essencialmente bancos de dados SQL envolvidos em arquivos de armazenamento estruturados COM (sistema de arquivos dentro de um arquivo). Os arquivos de transformação são “bancos de dados parciais” construídos por meio de ferramentas de instalação, como Orca (SDK link), Installshield ou Sensato , Advanced Installer, etc … (link para descrições das diferentes ferramentas). Essas transformações podem personalizar ou replace quase todas as configurações ou campos do database em um MSI – incluindo quais “partes do aplicativo” (resources) estão instaladas. Depois de criar uma transformação, você especifica seu aplicativo para o MSI na linha de comando msiexec.exe:

 msiexec.exe /i myinstaller.msi TRANSFORMS="mytransform.mst" /qn 

O Windows Installer, em seguida, mesclará o MSI e a transformação antes de iniciar a instalação. Essa é a abordagem usada por grandes organizações que desejam ter controle total de como o MSI é instalado. TRANSFORMS propriedade no MSDN .

Como mencionado acima, esta é a opção que permite que todas as configurações em um MSI sejam modificadas. Correções substanciais podem ser aplicadas a arquivos MSI mal projetados para permitir uma implantação confiável. Isso é feito por “empacotadores de aplicativos”. Seu trabalho é ajustar todas as configurações para trabalhar dentro do padrão corporativo. Eles podem estar entre os mais experientes especialistas em MSI – eles veem um monte de coisas estranhas em arquivos MSI.

Muitas ferramentas podem ser usadas para criar uma transformação, aqui está uma descrição de tais ferramentas dentro do contexto mais técnico de comparação de arquivos MSI. Basta ir direto para a lista de ferramentas gratuitas na parte inferior: Como posso comparar o conteúdo de dois (ou mais) arquivos MSI?


Anti-padrões e benefícios corporativos do Windows Installer:

O Windows Installer tem muitas peculiaridades de design e pode ser particularmente irritante para os desenvolvedores . É certo que existem alguns problemas que fazem fronteira com anti-padrões .

Anti-padrões potenciais

  • regras de sobregravação de arquivo contra-intuitivas ( symantec )
    • regras estranhas, especialmente para arquivos sem versão
    • um recurso insano para forçar a sobregravação de todos os arquivos ( REINSTALLMODE = amus)
      • pode degradar arquivos compartilhados em todo o sistema
      • pode causar uma propriedade de versão inconsistente, já que um pacote antigo pode ser instalado após um novo e fazer downgrade de alguns dos arquivos compartilhados
      • pode fazer downgrade ou eliminação de configurações em arquivos sem versão (e configurações de registro)
      • pode causar um aumento significativo no número de reinicializações solicitadas devido a tentativas de replace desnecessariamente arquivos em uso da mesma versão.
      • Existem vários outros problemas que são bem específicos. Um dia vou escrever todos eles
  • dados do usuário de redefinição inesperada no registro após atualizações
    • Isso é extremamente problemático . Se você experimentar isso, não é você, é a tecnologia
    • Frequentemente visto com logins de credenciais de serviço e chaves seriais
    • Algumas técnicas para evitar esse problema
      • evite escrever QUALQUER chave de registro HKCU da sua configuração, escreva-as no seu aplicativo. Sua configuração agora nunca interferirá com eles – não tem conhecimento dos valores.
      • colocando dados de registro em um recurso próprio (deve evitar problemas de auto-reparo)
      • instalar dados de registro através de um componente com GUID de componente vazio (não será reescrito durante reparo ou auto-reparo)
      • defina o sinalizador de componente para nunca sobrescrever se o caminho-chave existir.
      • gravar dados do HKLM (como chaves de licença) no registro usando uma ação customizada (isso tem outros problemas, mas lhe dará controle completo de quando os dados são gravados – em qual modo de instalação)
      • Certifique-se de manter um caminho de chave de registro estável. Definir um valor de sinalizador KeyPath = 1 e nunca alterá-lo – e de forma crucial – não altere o componente GUID
      • nunca defina REINSTALLMODE para “amus” – certamente não codifique esse valor na tabela de propriedades.
      • há mais truques e regras de ouro, se eu pudesse me lembrar de todos eles no topo da minha cabeça :-).
  • mecanismo de atualização complexo
    • pequenas atualizações tem muitas limitações e restrições
    • grandes atualizações têm outros desafios (redefinir dados de registro, arquivos ausentes após a instalação, auto-reparo de arquivos COM após a instalação, etc …)
  • resources de GUI sem brilho
    • Não ciência do foguete, mas um pouco complexo
    • falta de events e resources para implementar uma GUI adequadamente suave
  • patch chocantemente complicado
    • extremamente difícil de usar de forma eficaz
    • não recomendado para uso, exceto como um “hotfix” – ou seja, atualizar alguns arquivos ou corrigir um erro de arquivo MSI específico na sequência de desinstalação da instalação instalada.
  • Implementação extremamente complicada de ações personalizadas
    • sequenciamento complexo
    • condicionamento complexo
    • representação complexa / execução parcial com direitos elevados
    • Em geral extremamente propenso a erros .
  • a implementação sem brilho de configurações por usuário
    • conceitualmente duvidosa (redirecionamentos de pasta, imprevisibilidade, impossibilidade de fazer configurações no mundo real suportam instalações por usuário e por máquina)
    • complexo para atualizar, desinstalar e corrigir. Permite que os produtos sejam instalados várias vezes para diferentes usuários E também por máquina
    • Eu tenho que admitir – em uma nota subjetiva – que eu considero a implementação atual de configuração por usuário um completo anti-padrão de implantação. Eu nunca uso e insisto para não ser forçado a isso .
  • auto-reparo inesperado
    • 1) Auto-reparo – explicado .
    • 2) Auto-reparação – encontrar soluções reais .
    • 3) Auto-reparação – como evitá-lo na sua própria embalagem .
  • a falta de resources internos para gravar em arquivos XML
  • resources ruins para instalações do IIS
    • parte do problema é o arquivo sobrescrever regras para arquivos não versionados (resultados imprevisíveis possíveis).
    • O IIS pode precisar de uma nova tecnologia de implantação para ser honesto – uma maneira de definir o processamento de arquivos sem versão de uma maneira totalmente previsível – com opções reais e sensatas. Talvez o backup automático de arquivos não versionados forçados, impondo grupos de arquivos de texto consistentes (“assemblies”) que precisam estar na versão correta, etc.
    • também vários outros problemas com a configuração complexa do IIS e pastas virtuais e sites
  • a habilitação desleixada do “código de saída de verificação ” em ações personalizadas pode causar pacotes que não podem ser atualizados ou desinstalados (sem ajustes sérios)
    • grandes atualizações podem falhar e triggersr reversão para algo insignificante
    • uma pequena atualização pode ser usada para corrigir a sequência de desinstalação ou o condicionamento defeituoso
  • tem mais alguns …
    • Na verdade, escrevi um resumo abrangente de antipadrões comumente vistos, geralmente vistos em pacotes MSI do mundo real (uso incorreto da tecnologia): Como evito falhas de design comuns na minha solução de implantação WiX / MSI?
    • Eu posso suportar todo o conteúdo, mas o formato não é ótimo – é um lixo mental confuso, mas às vezes parece ser a única maneira de fazer as coisas. Pegue, leve pelo que é.
    • O uso excessivo de ações personalizadas é outro problema do MSI. Há um núcleo de complexidade por trás disso, mas no geral o problema é que as pessoas não usam soluções pré-existentes totalmente funcionais no MSI ou via extensões como o WiX (ou ferramentas comerciais como o Installshield ou o Advanced Installer). Aqui está um resumo: Por que é uma boa ideia limitar o uso de ações personalizadas em minhas configurações de WiX / MSI?

A questão da alta complexidade da implementação de ações personalizadas (lógica de instalação personalizada) pode ser considerada inevitável e o ato de escrever uma ação personalizada deve ser poderoso e capaz uma vez necessário – e, portanto, complicado. Raramente devem ser necessárias ações personalizadas se a própria tecnologia oferecer o que é comumente usado para implantação. Em outras palavras, você deve usar resources MSI internos, em vez de ações personalizadas, se estiverem disponíveis, ou extensão de software de implantação de WiX ou de terceiros, quando disponível.

A estrutura WiX (código aberto) e as ferramentas comerciais (Installshield, Advanced Installer, etc …) implementaram resources para estender o Windows Installer para lidar com resources ausentes, como a falta de um mecanismo de atualização para arquivos XML, criação e gerenciamento de compartilhamento , criação de usuários e grupos, configuração avançada do IIS, instalações COM +, alteração de permissions de ACL, definição de regras de firewall, persistência de propriedades de instalação, etc … Deve haver cada vez menos necessidade de implementar suas próprias ações personalizadas . Sempre use os resources que já foram testados por milhares de outros usuários, se puder (até mesmo milhões de usuários – e essas extensões foram escritas pelos melhores especialistas em implantação disponíveis – você acha que pode fazê-lo melhor sozinho?).

Os benefícios corporativos do Windows Installer (muito significativo)

Requer uma mentalidade específica para abordar o Windows Installer. No entanto, ele fornece uma série de benefícios corporativos cruciais que estavam quase totalmente ausentes nas tecnologias de instalação anteriores. Os benefícios corporativos de usar arquivos MSI são a leitura recomendada. Particularmente para quem acha que o Windows Installer é mais problemático do que vale a pena.

Para resumir brevemente o artigo vinculado, os principais benefícios corporativos da MSI em relação às tecnologias de implantação anteriores são (na minha opinião):

  • o funcionamento silencioso confiável (com GUI padronizada, completamente supressível)
  • a desinstalação implicitamente disponível (um pesadelo com tecnologias de implantação mais antigas)
  • o registro detalhado (pode ser útil, embora realmente detalhado)
  • o gerenciamento remoto confiável (na verdade, o benefício total – o efeito combinado de todos os outros benefícios listados)
  • os direitos de instalação elevados (sem direitos de administrador temporários)
  • a linha de comando padronizada (um recurso altamente benéfico – sem mais opções de linha de comando ocultas)
  • a natureza semitransparente do instalador (formato aberto, exceto CAs compostas que são checkbox preta)
  • o suporte de reversão (gerenciamento de estado do computador, impedir implantações parciais, falhas e reverter alterações)
  • a instalação administrativa (essencial para o reempacotamento corporativo, extrai todos os arquivos de uma maneira padrão)
  • a abordagem de customização de pacote padrão (transforma) (basicamente permite customização completa para implementação corporativa)

Isso é apenas para escolher os mais importantes (depois de muitos anos fazendo implantação corporativa). Com toda a honestidade, esses resources fazem toda a diferença no mundo (para implantação corporativa) e realmente tornam a MSI ótima para uso, apesar de todas as suas falhas .

Os anos Twilight do Windows Installer

À medida que o Windows Installer atinge seu auge, só podemos esperar que as tecnologias de implantação do futuro preservem esses grandes benefícios de implantação corporativa e lidem com os antipadrões mencionados de uma forma que beneficie a todos e aos desenvolvedores em particular.

A implantação é uma parte crucial do desenvolvimento . Não conseguir que o seu ótimo software seja instalado com sucesso para seus possíveis usuários finais pode ser o erro mais caro a ser cometido no desenvolvimento de software em geral. Como você pode ter sucesso se o usuário nunca vê seu software totalmente funcional?

A complexidade do Windows Installer deve ser melhor tratada (reduzida) e seus benefícios cruciais devem ser preservados adequadamente em qualquer paradigma que venha a seguir.

Um razoavelmente bom: resumo do Windows Installer .

Plataformas de nuvem

Com tudo isso dito; Como a computação em geral se move para as plataformas de nuvem, o mundo da implantação provavelmente mudará de maneira considerável e imprevisível. No entanto, como diz o famoso ditado: quanto mais as coisas mudam, mais elas permanecem as mesmas. A implantação precisa lidar com toda a tecnologia legada que será usada nas empresas nas próximas décadas. Aqui está uma parte sobre por que a implantação parece se tornar mais complicada e não menos complicada – apesar de todo o marketing: Qual é o benefício e o propósito real da instalação do programa? .

Será interessante ver qual será o futuro da implantação – nos próximos anos. Talvez possamos ver uma implantação simplificada para computadores domésticos e a implantação corporativa se tornará mais complicada do que nunca? No futuro, a maior parte da implantação provavelmente será mais uma tarefa de implantação de database do que uma tarefa de implantação de arquivos e pastas. A implantação de servidores pode ser extremamente complicada a partir de agora com scripts de database, criação de usuários e grupos, configuração de compartilhamento e permissions de ACL, contadores de desempenho, atualizações de regras de firewall, consultas e atualizações de AD, COM + e configuração de fila de mensagens, instalação de serviço etc. todas as nove jardas.


Como configurar a instalação silenciosa do MSI

Uma instalação MSI pode ser configurada na linha de comando, definindo as propriedades que o instalador usa. Existem propriedades predefinidas do Windows Installer, como a propriedade ALLUSERS. Esta propriedade define se uma instalação será feita no contexto do usuário atual ou da máquina.

Informações sobre as propriedades disponíveis podem, por exemplo, ser obtidas de um log de instalação que pode ser criado usando a opção / l do msiexec

 msiexec /I mysetup.msi /l*vx log.txt 

Como criar arquivos MSI

Há muitas maneiras de criar arquivos MSI. Um arquivo MSI é basicamente um database que consiste em várias tabelas contendo todas as informações necessárias de instalação e diálogos de instalação.

A Microsoft oferece uma ferramenta simples chamada Orca, que permite editar arquivos MSI existentes e permite descobrir quais propriedades podem ser definidas para configurar uma instalação. Teoricamente também é possível criar novos arquivos MSI usando esta ferramenta, mas é um caminho muito complicado.

Se você está procurando por uma solução livre e de código aberto, eu recomendo que você dê uma olhada no conjunto de ferramentas WiX disponível no SourceForge ou no Nullsoft. Todas as informações de configuração são feitas através de arquivos XML que são convertidos em um instalador MSI. O WiX é estável (embora ainda seja marcado como beta) e pode ser usado na produção. Na verdade, ele será integrado na próxima versão do Visual Studio 2010.

É claro que também existem soluções comerciais disponíveis, sendo o InstallShield o líder de mercado (também líder de preço) e o Visual Studio provavelmente sendo a ferramenta mais difundida.