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?
Respostas:
Apenas alguns benefícios:
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 .
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?
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:
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.
Em linguagem simples, os benefícios realmente importantes do MSI são (em nenhuma ordem específica):
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.
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.
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.
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.
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.
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.
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.
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 .
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.
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 .
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.
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.
É 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.
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.
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).
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).
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.
(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:
Tópicos especiais de instruções:
Tópicos conceituais / Melhores práticas:
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.
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):
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.