Quais são as vantagens de usar arquivos .msi sobre arquivos setup.exe regulares?

Tenho a impressão de que a implantação é mais fácil em máquinas em que os usuários têm poucas permissões, mas não tenho certeza sobre os detalhes.

Quais recursos o msiexec.exe possui para facilitar a implantação do que usar os cenários setup.exe?

Alguma dica ou truque ao implantar aplicativos .msi?

Apenas alguns benefícios:

• Pode ser anunciado (para que a instalação sob demanda possa ocorrer).
• Assim como o anúncio, os recursos podem ser instalados assim que o usuário tenta usá-los.
• O gerenciamento de estado é mantido para que o Windows Installer forneça uma maneira de permitir que os administradores vejam se um aplicativo está instalado em uma máquina.
• Capacidade de reverter se uma instalação falhar.

Penso que quando estou implantando software em um ambiente corporativo: a implantação de software via MSI é quase agradável. Por outro lado, quase sempre me sinto com medo de implantar software quando está em outro contêiner.

Para obter informações adicionais sobre como manipular instalações MSI, digite msiexecna caixa de diálogo Executar.

ATUALIZAÇÃO, julho de 2018 : Um resumo extremamente compactado das informações abaixo está disponível no stackoverflow: Os principais benefícios do MSI ( "executive summary"- das sortes).

Trabalhei no desenvolvimento como gerente de lançamento , engenheiro de construção , desenvolvedor de instalação e como empacotador de aplicativos e engenheiro de implantação em grandes corporações.

Esta é uma revisão dos melhores (e piores) recursos conceituais e do mundo real do MSI. Os problemas de design mais comuns encontrados nos arquivos MSI são apresentados como uma resposta separada abaixo . Não pretendendo ser completo - na verdade, apenas um "despejo cerebral" confuso - planejado como "aquilo que não pode ser encontrado nos livros" (provavelmente por um bom motivo).

Também quero sugerir este artigo do MSDN como uma boa leitura: Windows Installer: Benefícios e implementação para administradores de sistema .

Estandardização:

Em uma palavra, o MSI trata de padronização e de lidar com " cheiros de implantação " de tecnologias instaladoras herdadas. Uma coleção inteira de designs de arquitetura de instalação incorretos que causaram repetidos problemas de implantação.

Em geral, o MSI fornece uma estrutura abrangente e padronizada para o instalador, que também inclui os recursos e opções de desinstalação e embutidos para execução silenciosa com a GUI padronizada, que pode ser acionada remotamente .

Somente esses recursos constituem uma grande melhoria em relação às tecnologias de instalação anteriores, que tratavam a desinstalação e a execução silenciosa aleatoriamente - talvez os recursos mais importantes para implantação corporativa, juntamente com o gerenciamento remoto confiável de pacotes via Active Directory ou ferramentas de administração remota dedicadas, como o Microsoft SCCM (anteriormente SMS), IBM Tivoli , CA Unicenter e similares.

Alguém duplicou uma versão anterior desta resposta . Talvez uma leitura mais rápida?

Instaladores herdados "Cheiros de implantação"

O MSI desencoraja ativamente os odores de implantação herdados por design. Esses tópicos são discutidos nas seções posteriores abaixo, mas como uma lista rápida, os problemas mais reconhecíveis com instaladores herdados e com a tecnologia de implantação mais antiga foram:

• 1) às vezes, desclassificavam e sobrescreviam arquivos compartilhados e com versão com pouca preocupação com a dll-hell que resultou
• 2) geralmente não havia uma rotina de desinstalação adequada fornecida com o instalador ou ela não era concluída de maneira adequada e confiável - principalmente se executada silenciosamente. Esse é um problema muito grande para o gerenciamento corporativo de SOE
• 3) a instalação silenciosa raramente era suportada corretamente. A confiabilidade era baixa e muitas vezes era necessário registrar uma execução da instalação com as seleções de diálogo e isso não lidava bem com condições inesperadas, como caixas de diálogo de erro ou de aviso que não foram registradas na execução original.
• 4) o instalador não registrou o que foi instalado e, portanto, não havia uma maneira automática de verificar os arquivos no disco para verificar se ainda eram as versões que foram instaladas originalmente pelo instalador.
• 5) eles apresentavam parâmetros de linha de comando imprevisíveis, não confiáveis ​​e fora do padrão para o executável da instalação
• 6) seguindo a linha de comando fora do padrão e a falta de padrões, foi difícil personalizar os instaladores com valores específicos necessários para a implantação corporativa de maneira confiável e previsível
• 7) usuários normais não podiam executar essas instalações, e muitas vezes era necessário mexer nos direitos de administrador temporários (use "executar como" se isso fosse suficiente ou faça login como administrador, instale e faça logout) - essa geração completa de login e perfil às vezes era necessário para a instalação ser concluída)
• 8) o instalador do setup.exe geralmente não retornava um código de erro ou código de sucesso adequado e, às vezes, saía imediatamente e iniciava outro processo que terminaria a instalação, dificultando a determinação se a instalação foi concluída - especialmente por meio de um lote Arquivo
• 9) a maioria dos arquivos setup.exe permite a extração de arquivos, mas não de maneira confiável e previsível - você geralmente gasta muito tempo encontrando as opções corretas para fazer isso
• 10) o registro era geralmente ruim e bastante casual em algumas ferramentas. Depurar com arquivos de log raramente produziu clareza, mas ajudou um pouco
• 11) não havia transparência no que o instalador estava fazendo e nenhuma reversão não confiável para desfazer alterações após uma falha na instalação
• 12) não havia uma maneira padrão do setor de implantar componentes de tempo de execução compartilhados , fossem eles componentes do sistema operacional, componentes de terceiros ou o seu próprio

A lista continua com muitas outras falhas de implantação cruciais e reconhecidas . Obviamente, foi no mundo da implantação corporativa que esses problemas surgiram com mais freqüência e resultou no negócio de " reembalagem de aplicativos ", em que um instalador herdado é capturado com tecnologias de varredura de disco e registro para criar um arquivo MSI compatível com os padrões para implantação confiável.

A reembalagem de aplicativos é uma tarefa especializada e, geralmente, resulta em arquivos MSI de excelente qualidade, se executados corretamente por pessoas conhecedoras, mas não é possível reembalar todos os aplicativos devido à lógica de registro complexa que deve ser executada interativamente para que certos aplicativos funcionem.

Benefícios MSI - Resumo Breve

Em linguagem simples, os benefícios realmente importantes do MSI são (em nenhuma ordem específica):

• 1) a desinstalação está sempre disponível para todos os pacotes, a menos que esteja desativado
• 2) é o mesmo para o log , que é ótimo e padronizado, embora detalhado (ferramentas como WiLogUtl.exe podem ser usadas para analisar os arquivos de log)
• 3) o que um arquivo MSI faz é (semi-) transparente ou "inspecionável" na maior parte. A exceção são ações personalizadas - (consulte a seção de transparência abaixo)
• 4) a personalização da configuração é feita de maneira padronizada ( transformações )
• 5) não há necessidade de mexer com direitos administrativos temporários, pois a instalação é elevada por meio de anúncio do Active Directory, política de grupo ou administração remota. Algumas qualificações aqui. Veja também esta captura de tela no editor de objetos de diretiva de grupo.
• 6) instalação / desinstalação silenciosa via ferramentas de gerenciamento ou o uso do msiexec.exe funciona bem
• 7) existe suporte completo à reversão para instalações com falha. Se você instalar manualmente na caixa, existem algumas qualificações que você precisa conhecer.
• 8) o arquivo MSI se presta a inspeção e validação para consistência e validade lógica, uma vez que estão em conformidade com um esquema de banco de dados ( consulte o exemplo de validação )
• 9) atualizações são tipos padronizados, embora complexas e frequentemente sujeitas a erros para empacotadores inexperientes
• 10) a extração de arquivos do msi é um recurso interno (consulte o artigo vinculado para uma boa visão geral rápida)
• 11) a linha de comando do Windows Installer, msiexec.exe , possui um controle muito refinado de como a sequência de instalação deve ser executada e todas as opções funcionam com todos os arquivos MSI compatíveis com os padrões (defina o nível do log, execute silenciosamente / interativamente / semi-silenciosamente) , defina parâmetros de instalação, aplique transformações etc ...).
• 12) módulos de mesclagem é o mecanismo MSI para entregar arquivos compartilhados com vários pacotes MSI. É um módulo consumível ou pacote de lógica de instalação mesclável com qualquer pacote MSI no momento da compilação. O Wix ampliou e melhorou esse conceito com o uso de arquivos de inclusão do Wix - um conceito que, na minha opinião, é superior aos módulos de mesclagem - especialmente para seus próprios arquivos (ou seja, não arquivos do sistema operacional)
• 13) o mecanismo do instalador do Windows possui um mecanismo para impedir a substituição de arquivos com versão ou modificados na instalação. Isso é controlado por uma lógica de substituição de arquivos bastante complexa . Embora eficiente e boa, a lógica pode acabar sendo um problema por si só, já que muitos desenvolvedores enfrentam o problema de não serem capazes de substituir seus arquivos de configuração modificados durante a atualização. A solução para esses problemas geralmente são pequenas alterações no design do aplicativo para evitar padrões comuns de implantação - embora essa seja uma grande discussão.

No mundo real , encontrei aspectos menos bem-sucedidos que incluem patches (muito complexos), MSI-GUI (recursos simples, bastante complexos, falta flexibilidade), resiliência (pode causar problemas de depuração repetidos e difíceis de auto-reparo ) e a complexidade geral de lidar com a tecnologia para iniciantes (às vezes, alta complexidade das operações básicas - por exemplo, atualizações, GUI e muitos detalhes de interação causam resultados inesperados, etc ...). A velocidade do processo de instalação também diminuiu consideravelmente devido ao aumento da sobrecarga do MSI. Veja algumas dicas para melhorar a velocidade de instalação do MSI .

O restante do texto trata de alguns desses aspectos do MSI em mais detalhes.

Transparência (formato de instalador aberto)

Um arquivo MSI é essencialmente um banco de dados despojado do SQL Server armazenado como um arquivo de armazenamento estruturado COM - essencialmente um sistema de arquivos em um arquivo ou uma coleção de fluxos de dados. Esse é o tipo de arquivo usado nos documentos do Microsoft Office e produz um formato padrão que pode ser revisado e inspecionado - um grande problema para as grandes corporações.

Com exceção das ações personalizadas compiladas, um arquivo MSI é uma caixa branca . Se a configuração mudar algo louco, como as configurações de rede em todo o sistema, você poderá vê-lo usando as ferramentas apropriadas . A exceção notável são as ações personalizadas compiladas - que são uma caixa preta . Os requisitos do logotipo do Windows exigem que ações personalizadas sejam anotadas para explicar o que estão fazendo, mas isso geralmente é ignorado pelos desenvolvedores da instalação. Espero que o advento do Wix melhore isso.

Para determinar o que essas ações personalizadas compiladas realmente fazem no sentido técnico, é necessária uma captura de instalação . Isso quase nunca é feito na minha experiência. É mais comum entrar em contato com o fornecedor para obter informações, se o software precisar de aprovação para implantação corporativa, e pode ser o próprio aplicativo que impede seu uso, e não apenas a configuração.

Personalização (transformações)

Um MSI pode ser personalizado por meio de transformações para atender às necessidades e padrões de uma organização, enquanto ainda permite interoperabilidade com as atualizações do instalador do fornecedor. Você não altera o instalador, cria sua customização em um arquivo específico da organização, separado, chamado transform (arquivo .mst) (um fragmento do banco de dados ou uma transação de alteração, se desejar). Você é livre para desativar ações personalizadas e, em geral, alterar, substituir ou desativar qualquer coisa no instalador, e pode até adicionar coisas novas, incluindo arquivos. Às vezes, os arquivos de transformação também são usados ​​para localizar um arquivo MSI em diferentes idiomas. Várias transformações podem ser aplicadas a um único MSI, aqui está uma amostra com caminhos truncados :

msiexec.exe /I "My.msi" /QN /L*V "C:\My.log" TRANSFORMS="C:\1031.mst;C:\My.mst"

Explicação Rápida dos Parâmetros:

/QN = run completely silently
/L*V "C:\My.log"= verbose logging
TRANSFORMS="C:\1031.mst;C:\My.mst" = Apply transforms 1031.mst and My.mst.

Gerenciamento e relatórios

O Windows Installer mantém um banco de dados abrangente de todos os itens que um produto instalou no registro ( HKEY_CLASSES_ROOT \ Installer - nunca altere nada aqui diretamente! Isso também vale para especialistas).

Você pode determinar com segurança se um produto está instalado, quais recursos foram instalados e quais versões de arquivo foram instaladas. Além disso, você pode obter uma lista de todos os patches que foram aplicados ao produto base, se houver. Você pode acessar esse banco de dados via APIs que suportam Win32, COM ou .NET usando uma variedade de ferramentas de script, configuração e administração, como Microsoft SCCM , IBM Tivoli , CA Unicenter, etc.

Segurança (direitos elevados temporários)

O MSI também abrange os princípios de "direitos elevados", que permitem a um usuário restrito acionar a instalação de um produto que requer direitos de administrador para instalar. Isso faz parte do " recurso de anúncio ", que permite que um administrador disponibilize instaladores para os usuários sem realmente instalá-los em todas as estações de trabalho. O instalador em si deve ser criado corretamente em várias contas principais para que esse conceito de direitos elevados funcione corretamente. Os usuários podem acionar a instalação do produto eles mesmos ou a instalação pode ser controlada por um sistema de implementação dedicado, como SCCM, Tivoli, Unicenter (empresas maiores normalmente). Não há necessidade de mexer com direitos administrativos temporários para que as coisas funcionem o que geralmente acontece com os instaladores legados.

O banco de dados de instalação abrangente também garante que você tenha uma visão geral completa dos patches instalados e, portanto, a possibilidade de detectar vulnerabilidades de segurança por meio de ferramentas de automação e administração.

Validação

Os arquivos MSI podem ser verificados com as regras de validação para garantir que estejam em conformidade com várias regras internas de consistência (conhecidas como ICE) As empresas podem criar suas próprias verificações de ICE para impor regras e requisitos corporativos especiais. Isso ajuda muito com o controle de qualidade. A razão pela qual a validação é possível é devido à natureza de auto-referência dos bancos de dados relacionais e ao esquema do banco de dados associado. O banco de dados deve ser internamente consistente e compatível com seu próprio esquema com relação a chaves estrangeiras, tipos de dados, largura de campo, versão do esquema, etc. A validação também vai além disso e é capaz de detectar falhas e erros lógicos genuínos no pacote , não apenas falhas de formatação e tipo. Por exemplo, ele pode detectar arquivos ou tipos de arquivos que estão sendo implantados em destinos de destino incorretos.

Resiliência (Auto-reparo)

O recurso de instalação administrativa do instalador do Windows fornece uma maneira padrão de extrair os arquivos de origem de um MSI ( aqui estão algumas informações adicionais sobre este tópico ). Esses arquivos de origem podem ser colocados em um compartilhamento e estar disponíveis para todas as estações de trabalho para instalação. Isso garante que as operações de reparo, desinstalação e modificação sejam concluídas sem solicitar a mídia de instalação em CD ou similar. Isso é particularmente importante para operações de aplicação de patches e atualizações, que podem exigir acesso aos arquivos de origem das versões antigas em circunstâncias especiais.

Também há problemas comuns com esse recurso de resiliência. A maioria dos administradores experimentou máquinas com ciclos de auto-reparo cíclico que parecem nunca parar. Siga o link para obter uma longa lista de causas desse problema. E, novamente, aqui está uma versão mais curta que pode ser mais fácil de ler.

Reversão

A instalação de um arquivo MSI normalmente aciona a criação de um ponto de restauração . Além disso, todos os arquivos e itens de registro substituídos ou substituídos durante a instalação serão salvos e restaurados se a instalação falhar na conclusão, exceto as alterações feitas nas ações personalizadas.

Ações personalizadas devem implementar seu próprio suporte à reversão para conformidade com o logotipo do Windows. Isso geralmente é ignorado, mas envolve a criação de uma segunda ação customizada para desfazer as alterações feitas pela ação customizada principal.

A reversão garante que a estação de trabalho permaneça em um estado estável, mesmo que a instalação falhe. O script de reversão real é armazenado em uma pasta oculta diretamente na unidade do sistema - geralmente C: \ Config.MSI , e contém arquivos com as extensões .RBS e .RBF - arquivos de script de reversão . Como você pode esperar, os arquivos MSI mal projetados podem violar os recursos internos do Windows aqui, consulte minha outra postagem neste tópico para obter mais detalhes.

Existem maneiras de desativar a reversão e acelerar a instalação. Geralmente não é recomendado, mas aqui estão detalhes sobre a propriedade MSIFASTINSTALL e DISABLEROLLBACK . Esse é um recurso complicado, mas aqui está uma rápida visão geral da reversão .

Patches e atualizações

Embora altamente complexo, o patch no instalador do Windows é totalmente gerenciado e registrado no sistema, para que um estado de segurança do sistema possa ser determinado verificando o que foi instalado. As atualizações são padronizadas para algumas variantes básicas, e isso permite que as atualizações sejam executadas com um maior grau de certeza, desde que você seja capaz de lidar com a complexidade envolvida. Os sistemas de implantação poderão relatar quais atualizações falharam e por quê.

Em uma visão subjetiva, o patch funciona bem para 2 usos básicos : 1 ) pequenos hotfixes para produtos entregues e 2 ) patching um produto instalado para corrigir sua sequência de desinstalação defeituosa que impede a desinstalação limpa de um produto.

Um patch é apenas um mecanismo de entrega para uma atualização que já está funcionando . Como tal, é apenas um contêiner mais complicado e propenso a erros do que a própria configuração original. A regra número um de um patch é que ele deve ser menor que o MSI original ou não há motivo óbvio para fornecer um patch. Um patch pode ficar enorme rapidamente se atingir várias versões do produto.

Log (detalhado)

O Windows Installer fornece um recurso de log padronizado que é muito superior às encarnações anteriores, embora quase excessivamente detalhado. Os arquivos de log podem ser decifrados usando analisadores de log e níveis de log personalizados podem ser usados ​​para eliminar a geração de arquivos de log muito grandes com informações desnecessárias. Para fins de depuração, o registro detalhado é extremamente útil. Consulte o blog de Rob Mensching para obter uma boa maneira manual de ler um arquivo de log MSI (basicamente você pesquisa " valor 3 " no arquivo de log). Aqui está uma linha de comando de exemplo que executa o log detalhado:

msiexec.exe /I "C:\Installer.msi" /QN /L*V "C:\msilog.log"

Este artigo de Robert Macdonald, da Equipe do Windows Installer, é altamente recomendado como uma visão prática do log do MSI: Como interpretar os logs do Windows Installer .

Conclusão

Nem tudo é bom no Windows Installer . Sua complexidade pode ser desconcertante às vezes, mas para grandes empresas, os arquivos MSI são muito superiores a qualquer outra forma de implantação quando você leva em consideração a lista de benefícios acima.

Novo paradigma do instalador (a enorme instrução SQL)

Para entender o novo " paradigma ", é importante entender que o MSI é uma descrição declarativa do que vai acontecer no sistema de destino, em vez de uma sequência fixa de eventos. Suponho que você possa pensar nisso como uma enorme declaração SQL . Por exemplo, você declara itens que deseja adicionar ou modificar em um arquivo INI. Conforme a instalação é executada, as alterações são rastreadas e a reversão está disponível para que as alterações possam ser revertidas se a instalação falhar. Isso realmente funciona como " automagic " e é confiável quando feito corretamente.

Ações personalizadas (os suspeitos do costume)

É uma grande dor de cabeça para desenvolvedores MSI experientes ver as pessoas confiarem em ações personalizadas complexas e não confiáveis ​​para funcionalidade que é melhor implementada com recursos MSI integrados. Uma parcela significativa de todos os erros MSI e problemas de reversão é causada por ações personalizadas incorretas e a maioria dos outros erros é causada pelo uso incorreto do design MSI (consulte a resposta em separado para obter a lista de erros MSI comuns).

Além dos recursos integrados do MSI, agora mais e mais funcionalidades personalizadas estão disponíveis através de uma nova estrutura, como o Wix - a maneira XML de compilar arquivos MSI, para que haja cada vez menos necessidade de lógica de ação personalizada complexa para a maioria das operações.

O MSI oferece suporte completo para lidar com a mesclagem de configurações de arquivo ini, fontes, variáveis ​​de ambiente, chaves do registro, informações COM, atalhos, extensões de arquivo, condições de inicialização, instalação do GAC, ODBC, etc.

O WIX vai além com o suporte a recursos muito avançados , como extensões de servidor SQL, instalações e configurações do IIS, contadores de desempenho, verificação do DirectX e outras tarefas relacionadas a jogos, geração nativa de imagens .NET, COM +, drivers, regras de firewall, extensões do PowerShell, fechamento de aplicativos, gerenciamento de usuários, grupos, compartilhamentos e muito mais. Um pouco envolvido para lidar, mas muito mais confiável do que suas próprias ações personalizadas.

Evite ações personalizadas a todo custo, se possível

Para tentar colocá-lo em perspectiva: estes built-in e soluções prontas são feitos pelos melhores especialistas de implantação disponíveis , e eles são testados por milhares, dezenas de milhares ou talvez milhões de usuários (para o material embutido no MSI próprio). Você realmente acha que pode fazer melhor fazendo suas próprias ações personalizadas? O uso de uma ação customizada deve ser um evento raro e deve ser absolutamente necessário obter algo exclusivo para o produto que você instala . E você deve escrever também o suporte adequado à reversão, o que é bastante envolvido.

Escrever uma ação personalizada quase sempre é um erro , mas há casos genuínos em que você também precisa da flexibilidade. Como sempre, é importante escolher bem suas batalhas. Pode ser uma tarefa divertida a princípio, mas você provavelmente enfrentará muitos problemas inesperados e perderá muito tempo. Quero dizer isso muito a sério. Eu mesmo escrevi um conjunto de ações personalizadas em C ++ para uso corporativo (para eliminar ações personalizadas em VBScript propensas a erros) - não é uma brincadeira, e embora a codificação possa não ser a mais difícil do mundo, a depuração e teste e A conexão com um arquivo MSI real não deixa de ser extremamente envolvida. Algum tempo pesquisando quais opções prontas estão disponíveis, provavelmente você economizará semanas de trabalho de desenvolvimento e renderá uma confiabilidade de implantação muito maior.

Use a sequência de inicialização do aplicativo

Um ponto muito importante é que muita configuração de aplicativo deve ocorrer no lançamento do aplicativo quando você tem um contexto de tempo de execução previsível e uma boa manipulação de erros disponível, e não na configuração que é executada apenas uma vez e apresenta representação , sequência , condicionamento e tempo de execução muito complicados complexidade .

Sua instalação não deve configurar o aplicativo, ele deve preparar o aplicativo para configuração no primeiro lançamento . Especificamente, sua instalação deve gravar todas as configurações que exijam direitos elevados - gravar no HKLM, registrar serviços, instalar em caminhos por máquina e qualquer coisa que um aplicativo não possa gravar sozinho com direitos de usuário regulares.

Se você é um desenvolvedor de configuração, deve oferecer a codificação da sequência de inicialização do aplicativo, em vez de escrever ações personalizadas de configuração . Se nada mais, para evitar parecer que você está tentando "passar a bola" para outra pessoa. Nesta sequência de inicialização, você pode escrever um código muito mais confiável e testável, o que é mais fácil de obter ajuda da equipe de controle de qualidade para teste (geralmente eles não entendem o teste de implantação nem o de aplicativos).

Complexidade da instalação

O núcleo da complexidade da instalação se concentra no fato de que os erros são cumulativos (você está gerenciando um processo de entrega, não apenas uma recompilação rápida), os erros são muito difíceis de depurar (sem acesso aos sistemas onde os erros ocorrem) e o sistema de destino estados diferem em quase todos os modos imagináveis . Consulte esta resposta para uma discussão mais aprofundada sobre essa complexidade e como os sistemas de destino podem ser cautelosos de várias maneiras chocantes: Windows Installer e a criação do WiX e The Complexity of Deployment (veja na parte inferior).

WiX (a melhor solução MSI para alguns propósitos)

Leia esta introdução rápida do WiX para obter uma descrição da nova maneira baseada em XML de compilar arquivos MSI. Os arquivos de origem baseados em texto fornecem um controle de origem muito melhor do que antes. Este é um kit de ferramentas de código aberto gratuito, altamente recomendado .

Nota : Veja em outra parte do thread um rápido resumo dos problemas comuns de design com arquivos MSI - é muito incompleto, mas vale a pena ler. Eu não queria acrescentar isso a essa resposta, pois ela não é 100% relacionada, mas, para uso no mundo real, é um tópico crucial.

Algumas informações principais do MSI para sys-admins:

(perdoe a vergonhosa "promoção" - é para fácil acesso e recuperação)

Aqui estão apenas alguns links para tópicos que podem ser úteis para os administradores de sistema em seus esforços para controlar a implantação em suas redes:

• Como posso eliminar os enormes arquivos MSI em cache no C: \ Windows \ Installer? (alto uso de disco pelo MSI)
• Como acelerar as instalações MSI (apenas algumas opções)
• Como extrair arquivos do setup.exe (vale a pena ler para qualquer administrador, provavelmente notícias antigas)
• Diferentes maneiras de desinstalar um MSI (referência de desinstalação, popular - alto número de visualizações)
• Como ignorar o msiexec.exe ao lidar com pacotes MSI (automação e script MSI)
• Por que o MSI exige que o arquivo .msi original continue com a desinstalação? (pergunta comum)
• Por que existem vários processos msiexec.exe na lista de processos durante a instalação? O que eles estão fazendo?

Tópicos especiais de instruções:

• Forçando uma atualização de um arquivo modificado durante sua instalação inicial (pergunta comum)
• Existe alguma maneira de obter msiexec para ecoar em stdout em vez de fazer logon em um arquivo (tópico avançado, usando GUI externa para MSI, mais conteúdo para desenvolvedores)
• Quero instalar um MSI duas vezes (instância se transforma ou virtualiza - sério :-)).
• Como atualizar todos os perfis de usuário usando o ActiveSetup (um pouco perigoso, mas útil)
• Erros comuns nos pacotes MSI (mais para desenvolvedores, mas também para administradores de sistema)
• Como depurar o reparo automático cíclico (tópico importante)

Tópicos conceituais / Melhores práticas:

• Qual é o benefício e o real objetivo da instalação do programa? (noções básicas de implantação)
• Finalidade das instalações administrativas (operação principal do MSI para administradores de sistema)
• Por que você não deve usar o MSI para ajustes no registro (leitura recomendada)
• Qual produto de instalação usar? (Pontos fortes e fracos de diferentes ferramentas)
• Por que o auto-registro é considerado prejudicial no MSI

Essa resposta é muito um trabalho em andamento e um esboço. Adições, perguntas e atualizações são bem-vindos. Esta lista não é de forma alguma exaustiva. Adicione um comentário com informações sobre pacotes problemáticos.

Problemas típicos e falhas de design vistos em pacotes MSI

Também devo avisar que muitos arquivos MSI contêm erros, às vezes graves, mas os empacotadores de aplicativos treinados poderão detectar isso e, na maioria dos casos, eliminar o problema. Estou adicionando isso como uma resposta separada, pois responde essencialmente a uma pergunta diferente, mas acho que é relevante no mesmo tópico.

Os detalhes técnicos envolvidos no MSI são muito complicados . No nível básico, trata-se de decompor seus arquivos e configurações do registro em componentes (instalação atômica) e recursos (partes de aplicativos selecionáveis ​​pelo usuário para instalar, por exemplo, um recurso de dicionário). Existem várias regras de boas práticas para dividir os componentes, e os erros nos arquivos MSI aqui são abundantes. Esses erros geralmente são tratados pela padronização do uso de "grandes atualizações".

A instalação real é realizada em várias seqüências de instalação, algumas com direitos elevados . Todas essas coisas são definidas nas tabelas do banco de dados, e é aqui que o MSI é extremamente complicado de entender e lidar. Espalhados pelas seqüências de instalação, são ações padrão e personalizadas. As ações padrão são projetadas pela Microsoft e precisam ocorrer (às vezes a sequência pode ser modificada). Ações personalizadas estão disponíveis para os fornecedores executarem uma lógica personalizada não coberta pelo próprio MSI. Eles podem estar em script ou em formato compilado. Ações personalizadas podem ser imediatas (executadas de uma só vez, não devem alterar o sistema, mas geralmente alteram) ou diferidas (gravadas em um script de execução que é então executado como uma transação e, portanto, suporta reversão).

Os erros típicos em um MSI são (em nenhuma ordem específica - e apresentados como uma verdadeira bagunça):

• erros de criação de componentes (não seguindo as práticas recomendadas). Isso pode causar problemas para correção e atualizações com sintomas misteriosos, como falta de arquivos e configurações ou patches que ocorrem com erros sem sentido. Para simplificar demais, deve-se usar um arquivo por componente, a menos que o número de arquivos seja enorme.
• atualizar problemas relacionados aos dados do usuário que estão sendo substituídos ou redefinidos. Veja mais detalhes abaixo.
• agendamento incorreto de ações personalizadas fora da "seção transacionada" das sequências de instalação ou ações personalizadas do tipo errado são colocadas incorretamente. Isso geralmente faz com que as ações falhem (sem direitos elevados) quando executadas remotamente por meio de sistemas de implantação e a reversão é efetivamente prejudicada porque apenas as ações transacionadas são revertidas. A transação do Windows Installer (think commit da transação do banco de dados) é executada entre as ações padrão InstallInitialize e InstallFinalize na sequência de instalação principal e é executada com direitos elevados . Todas as alterações no sistema devem ocorrer nesta transação - qualquer outra coisa é incorreta (mas infelizmente bastante comum).
• uso de ações personalizadas no modo imediato para fazer alterações no sistema fora da sequência de instalação transacionada . Isso interrompe o suporte à reversão e geralmente aciona erros de segurança, já que as ações personalizadas no modo imediato não são executadas com direitos de usuário elevados, independentemente de onde são colocadas nas sequências de instalação.
• projetos errados que causam ciclos repetitivos de autocorreção sem motivo óbvio. Aqui está outro artigo sobre esse assunto, em installsite.org
• ações customizadas que não obedecem à supressão da GUI no modo de instalação autônoma podem mostrar diálogos modais que fazem com que a implantação falhe completamente quando executada silenciosamente. Esse problema, juntamente com a diferença geral entre o modo silencioso e o modo interativo, é descrito em mais detalhes aqui (um pouco detalhado e prolongado): A desinstalação do Painel de Controle é diferente de Remover de .msi
• algumas ações personalizadas em pacotes criados incorretamente são inseridas apenas na sequência da interface do usuário . Isso faz com que eles não sejam executados no modo de instalação silenciosa. Isso é sério para a implantação corporativa, pois a instalação silenciosa é usada aqui quase que exclusivamente. Esse problema também pode afetar a desinstalação, o que significa que talvez você precise executar a desinstalação interativamente para desinstalar, para garantir que todas as ações personalizadas da limpeza sejam executadas. Mais uma vez, consulte o link no ponto anterior para obter uma descrição mais detalhada dos níveis da interface do usuário.
• a configuração contém arquivos que não devem ser implantados no local em que estão sendo instalados. Normalmente, os arquivos do sistema que devem ser instalados lado a lado na pasta de montagem winsxs.
• baixa velocidade de instalação é outro "problema" que muitos relatam com o MSI. Aqui estão algumas dicas sobre o assunto . No geral, o Windows Installer apresenta um pouco de sobrecarga devido aos pesados ​​requisitos de registro no registro do que está sendo instalado.
• substituição de informações personalizadas ou arquivos de dados compartilhados . Isso pode acontecer se um arquivo INI for instalado através da tabela File e não da tabela IniFile, por exemplo. No último caso, é tratada como uma "transação de alteração"; no caso anterior, é uma operação de substituição de arquivo, que geralmente está errada, a menos que o arquivo INI possua formatação não padrão ou seções de comentários grandes que você deseja implantar no seu arquivo (comum para certos ferramentas de desenvolvimento).
• as regras complexas para a substituição de arquivos podem fazer com que os arquivos sejam substituídos acidentalmente ou não sejam atualizados - esse é um problema clássico do MSI. Consulte este artigo para saber como você pode forçar a substituição de um arquivo que não será atualizado . As regras podem ser ligeiramente ajustadas pelas configurações personalizadas da propriedade REINSTALLMODE definida no nível da linha de comando msiexec.exe (sobrescrever versões mais antigas, sobrescrever versões iguais, sobrescrever qualquer versão etc ...) e funcionam de maneira diferente para arquivos de dados e arquivos com versão. Detalhes no SDK . Entender isso é fundamental e é um projeto frequentemente desaprovado, mesmo quando compreendido.
• o auto registro de arquivos COM durante a instalação pode disparar avisos de segurança ou causar problemas de várias maneiras. Confira este artigo: O auto-registro é considerado prejudicial .
• uma variação no problema de substituição de arquivo ocorre quando uma grande atualização (que desinstala e reinstala o produto) desinstala os arquivos modificados e reinstala as versões padrão. Nesses casos, o conteúdo parece revertido ou substituído quando, na realidade, foi desinstalado primeiro e depois reinstalado.
• os serviços executados com credenciais de usuário personalizadas podem perder suas credenciais durante os principais cenários de atualização, além de fazer com que o arquivo de configurações (aparentemente) volte ao padrão (eles foram realmente desinstalados e reinstalados). Apenas para constar: na minha opinião, os serviços executados com credenciais de usuário são uma falha de design em primeiro lugar.
• as propriedades públicas não são passadas corretamente do cliente para o processo do servidor, impedindo que ações personalizadas sejam concluídas conforme o esperado. Isso envolve a atualização da propriedade SecureCustomActionProperties.
• Alguns aplicativos não podem ser executados corretamente para outros usuários além daquele que instalou a instalação originalmente. Este é um erro grave de design, mas geralmente pode ser corrigido por empacotadores de aplicativos experientes que usam a recuperação automática ou o ActiveSetup para adicionar chaves de registro HKCU e arquivos de perfil de usuário . Esse é um assunto bastante complexo e pode exigir um pouco de arte negra para começar a funcionar. Para registro: a solução real, na minha opinião, é alterar o próprio aplicativo para poder inicializar todas as configurações por usuário com base na configuração padrão e nos modelos copiados de um local por máquina ou com base nos padrões internos do aplicativo (a partir do Código fonte).
• Alguns arquivos MSI atrapalham a segurança dos arquivos instalados , definindo direitos completos de leitura / gravação para não administradores aqui, ali e em qualquer lugar. Outras vezes, o aplicativo para de funcionar em versões mais recentes do Windows devido à falta de permissões. Os empacotadores de aplicativos enfrentam a análise das necessidades de permissão personalizadas de um aplicativo com bastante frequência. Normalmente, algumas permissões extras são necessárias no HKLM ou em algum lugar do% ProgramFiles%
• Algumas configurações do Installshield antigamente tentavam se conectar à Internet durante a instalação. Isso é horrível para cenários de implantação corporativa em que a implantação é rigidamente controlada e o instalador nunca poderá baixar novos conteúdos diretamente da Internet.
• Outro problema de rede é quando as configurações tentam mostrar uma GUI na qual as pessoas inserem dados que são validados pela Internet enquanto instalam ou apenas mostram o conteúdo ao vivo em seu site. Normalmente, são endereços de email, informações de contato, chaves de licença e outras coisas. A conexão pode falhar completamente por vários motivos, geralmente devido à falta de configuração de proxy em ambientes corporativos (não há conexão direta com a Internet, todo o tráfego da Internet é roteado através de um servidor de cache específico e cada processo precisa fornecer credenciais para passar pelo firewall) . Aqui está um artigo sobre os perigos da validação de licenças por meio da instalação .
• Installshield usado para instalar um tempo de execução para seu idioma InstallScript . Essa configuração de pré-requisito geralmente era incluída no setup.exe e era uma fonte lendária de problemas . Havia muitas versões, várias incompatibilidades e vários erros de tempo de execução costumavam ocorrer. Desde a versão 12 (ou a seguir), esse tempo de execução agora está instalado de forma confiável e está sendo compilado para nativo ou em execução em área restrita (não sei qual, um ou outro - provavelmente na área restrita) de maneira confiável. Porém, as configurações mais antigas do Installshield podem exibir esse problema de implantação. Há um site de suporte herdado do Installshield para problemas como estes: http://consumer.installshield.com/common.asp
• Várias configurações podem exibir comportamento de instalação irregular ou erros intermitentes quando executadas em máquinas configuradas para idiomas diferentes do inglês ou mesmo quando você executa versões localizadas (traduzidas) de configurações em máquinas inglesas. Isso pode ser uma falha puramente do tempo de execução, ou casos em que as caixas de diálogo localizadas apresentam texto cortado, formatação incorreta ou tradução incorreta ou muitos outros tipos de erros relacionados à localização do idioma- toda uma área de conhecimento por conta própria (traduzir texto em imagens, traduzir o software em si, traduzir material de marketing, lidar com solicitações de suporte internacional, adaptação às configurações de idioma no sistema operacional, etc ...). Alguns idiomas precisam que todo o aplicativo seja alterado para dar conta de suas peculiaridades de idioma - os problemas típicos são macros de seqüência de caracteres e configurações da página de códigos, sendo este último um problema menor com a introdução do Unicode. Veja um exemplo de captura de tela de uma ferramenta de tradução .
• Quase todas as configurações falham em vários testes de validação internos disponíveis para testar a qualidade dos pacotes MSI. Consulte este artigo para um exemplo prático de validação.
• Às vezes, as atualizações falham para um MSI devido ao fato de que apenas 3 dígitos do número da versão do MSI são realmente verificados durante as principais varreduras de atualização.
• A instalação dos arquivos INI é um recurso interno do Windows Installer. As entradas podem ser adicionadas, removidas, mescladas ou tratadas de qualquer maneira necessária. No entanto, é bastante comum que os arquivos INI sejam instalados como um arquivo e não como valores segmentados. Isso pode fazer com que o arquivo INI seja substituído durante a reinstalação, em vez de ser atualizado. Um problema MSI muito comum.
• O problema acima também é o caso dos aplicativos .NET e seus arquivos Config.xml. Nesse caso, o MSI NÃO possui uma maneira integrada de atualizar o conteúdo de maneira detalhada e você precisa codificar a atualização por meio de uma ação personalizada ou substituir o arquivo inteiro na instalação. O Wix pode ter novos recursos para isso, mas o mecanismo do Windows Installer não possui esse recurso.

Existem vários erros mais sutis e vários problemas típicos maiores que esquecerei.

Confira o artigo de práticas recomendadas do Windows Installer no MSDN .

O uso de MSI também facilita a aplicação de patches (arquivos MSP) e atualizações. Os MSI usam o conceito de códigos exclusivos de produto e atualização, o que facilita todo o processo.

Alguns sistemas de implantação (o CA Unicenter Software Delivery é um exemplo) também podem entender os MSIs de uma maneira especial, o que lhes permite integrar-se muito melhor ao sistema de implantação. Por exemplo, você pode alimentar um MSI na biblioteca de software do sistema de implantação e ele detectará automaticamente os vários recursos do produto e permitirá automaticamente ações personalizadas muito mais granulares (instalação local, verificação, reparo etc.) e registro.

A auto-reparação / reparo também é uma grande vantagem para os MSI.

Além disso, consulte o Windows Installer XML de código-fonte aberto , "um conjunto de ferramentas que cria pacotes de instalação do Windows a partir do código-fonte XML. O conjunto de ferramentas suporta um ambiente de linha de comando que os desenvolvedores podem integrar em seus processos de criação para criar pacotes de instalação MSI e MSM". Isso é usado pela MS para preparar vários de seus principais pacotes de software.

você pode fazer transformações - em teoria, você pode personalizar muito, se o programa foi empacotado adequadamente pelo fornecedor, você pode fazer uma implantação totalmente automatizada sem nenhuma interação com o usuário final - o que é muito útil quando você deseja padronizar o ambiente do Windows e ter mais do que um punhado de computadores.

para ver o que as pessoas fazem com a msis [ou implantação autônoma] visitam, por exemplo, este site e seus fóruns.