it-swarm-pt.tech

Os benefícios corporativos do uso de arquivos MSI

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?

58
Frode Lillerud

Apenas alguns benefícios:

  • Pode ser anunciado (para que a instalação sob demanda possa ocorrer).
  • 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 mais informações sobre como manipular instalações MSI, digite msiexec na caixa de diálogo Executar.

43
Matt Hanson

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" - Do tipo).


Eu trabalhei no desenvolvimento como gerente de lançamento, engenheiro de compilaçã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) conceituais e recursos do mundo real do MSI. Os mais problemas comuns de design encontrados nos arquivos MSI são apresentados como ma resposta separada abaixo. Não fingir estar 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 isso 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 "implantação cheira" das tecnologias instaladoras herdadas. Uma coleção inteira de designs de arquitetura de instalação incorretos que causaram repetidos problemas de implantação.

O MSI geral fornece uma estrutura abrangente e padronizada para o instalador, que inclui também a desinstalação e recursos e opções integrados para execução silenciosa com 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 a implantação corporativa, além de confiáveis gerenciamento de pacote remoto via Active Directory ou ferramentas de administração remota dedicadas, como 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 "A implantação cheira"

O MSI desencoraja ativamente a implantação herdada cheira 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) eles às vezes desatualizados e substituem arquivos compartilhados e versionados com pouca preocupação com o dll-hell que resultou
  • 2) freqüentemente havia não uma rotina de desinstalação adequada fornecida com o instalador ou ela não foi concluída de maneira adequada e confiável - principalmente se executada silenciosamente. Esse é um problema muito grande para o gerenciamento corporativo de SOE
  • )instalação silenciosa raramente era suportado 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 imprevisível, não confiável e parâmetros de linha de comando fora do padrão para o executável da instalação
  • 6) Após a linha de comando fora do padrão e a falta de padrões, era 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 com direitos administrativos temporários (use "executar como" se isso fosse suficiente ou faça o login como administrador, instale e efetue logout - às vezes, essa geração completa de logon e perfil é necessária para a instalação)
  • 8) o setup.exe o instalador geralmente não retorna um código de erro adequado ou código de sucesso e, às vezes, sai imediatamente e chuta outro processo que concluiria a instalação, dificultando a determinação se a instalação foi concluída - principalmente por meio de um arquivo em lotes
  • 9) a maioria dos arquivos setup.exe permitia a extração de arquivos, mas não de maneira confiável e previsível - você geralmente gastava muito tempo encontrando as opções corretas para fazê-lo
  • 10)log era geralmente ruim e bastante casual em algumas ferramentas. Depurar com arquivos de log raramente produziu clareza, mas ajudou um pouco
  • 11) houve sem transparência no que o instalador estava fazendo e nenhuma ou reversão não confiável para desfazer alterações após uma falha na instalação
  • 12) houve nenhuma maneira padrão do setor de implementando componentes de tempo de execução compartilhados se eram componentes do sistema operacional, componentes de terceiros ou seus próprios

A lista continua com muitas outras falhas cruciais e reconhecidas falhas de implantação. 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" onde 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.

Reembalagem de aplicativos é um trabalho especializado 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 executado 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)ninstall está sempre disponível para todos os pacotes, a menos que esteja ativamente desativado
  • 2) é o mesmo para log, que é ótimo e padronizado, embora detalhado (ferramentas como WiLogUtl.exe podem ser usadas para analisar os arquivos de log)
  • ) o que um arquivo MSI faz é (semi-) transparente ou "inspecionável" na maior parte. A exceção são as ações personalizadas consulte seção de transparência abaixo)
  • 4) a personalização da configuração é feita de maneira padronizada (--- (transforma)
  • 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 através de ferramentas de gerenciamento ou o uso do msiexec.exe funciona bem
  • 7) existe suporte completo rollback para instalações com falha. Se você instalar manualmente na caixa, existem algumas qualificações 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) as atualizações são tipos padronizados, embora complexas e frequentemente sujeitas a erros para empacotadores inexperientes
  • 10) o extração de arquivos do msi é um recurso interno (verifique o artigo vinculado para uma boa visão geral rápida)
  • 11) a linha de comando do Windows Installer, msiexec.exe, possui um controle refinado de como a sequência de instalação deve ser executada e todas as opções funcionam com todos arquivos MSI em conformidade com os padrões (defina o nível do log, execute silenciosamente/interativamente/semi-silenciosamente, defina os parâmetros de instalação, aplique transformações etc ...).
  • 12)mesclar módulos é o mecanismo MSI para entregar arquivos compartilhados com vários pacotes MSI. É um módulo consumível ou pacote configurável 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 Windows Installer 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 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 sobrescrever 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 por si só.

No mundo real eu encontrei aspectos menos bem-sucedidos para incluir patching (muito complexo), MSI-GUI (recursos simples, bastante complexo, carece de flexibilidade), resiliência (pode causar difícil de depurar repetindo problemas 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 do instalador aberto)

Um arquivo MSI é essencialmente um banco de dados 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. Este é o tipo de arquivo usado em documentos do Microsoft Office e gera um formato padrão que pode ser revisado e inspecionado - um grande problema para grandes corporações.

Com exceção das ações personalizadas compiladas, um arquivo MSI é um 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 é ações personalizadas compiladas - que são caixa preta. Requisitos do logotipo do Windows exigem que as 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ário = setup capture. 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)

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 (.mst file) (um fragmento do banco de dados ou uma transação de alteração se você gostar). 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á um exemplo 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

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! também 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 "direitos elevados" princípios, que permite que um usuário restrito inicie a instalação de um produto que requer direitos de administrador para instalação. 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 fazer as coisas funcionarem 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 um número de regras internas de consistência (referido 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 se deve à 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 instalação do administrador 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 as operações de aplicação de patches e atualização, 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 visão geral da reversão rápida .

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 ) corrigindo 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 que é 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 entregar um patch. Um patch pode ficar enorme rapidamente se atingir várias versões do produto.

Log (de fato 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 blog de Rob Mensching para uma boa maneira manual de ler um arquivo de log MSI (basicamente você procura por "valor" 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 conta 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 se destina como 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. À medida que 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 enorme dor de cabeça para desenvolvedores MSI experientes ver 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 MSI integrados, mais e mais funcionalidades personalizadas estão agora disponíveis através de uma nova estrutura, como Wix - a maneira XML de compilar arquivos MSI, para que haja cada vez menos necessidade de customizações complexas lógica de ação para a maioria das operações.

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 ...

[~ ~ ~] wix [~ # ~] vai além com suporte para recursos muito avançados como extensões de servidor SQL, IIS instalações configuração, 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. 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: essas embutidas e soluções prontas são feitas pelos melhores especialistas em implantação disponíveis e eles são testados por milhares, dezenas de milhares ou talvez até milhões de usuários (para itens incorporados no próprio MSI). Você realmente acha que pode fazer melhor suas próprias ações personalizadas? O uso de uma ação personalizada deve ser um evento raro e deve ser absolutamente necessário obter algo único 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 caro. 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 é nada menos que extremamente envolvido. Algum tempo pesquisando quais opções prontas estão disponíveis, provavelmente você economizará semanas de trabalho em 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 início 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 recursos muito complicados representação =, sequenciamento, condicionamento e complexidade do tempo de execução.

Sua instalação não deve configurar o aplicativo, deve prepará-lo 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 instalação, deve oferecer a codificação da sequência de inicialização do aplicativo em vez de escrever ações personalizadas de instalaçã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, que é mais fácil obter ajuda da equipe de controle de qualidade para testar (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 é o fato de que erros são cumulativos (você está gerenciando um processo de entrega, não apenas uma recompilação rápida), erros são muito difíceis de depurar (não acesso aos sistemas em que os erros ocorrem) e os estados do sistema de destino diferem em quase todos os aspectos 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 formas 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 isto 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.

N.B: Veja em outro lugar no encadeamento um rápido resumo dos problemas comuns de design com arquivos MSI - é muito incompleto, mas vale a pena ler. 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:

Tópicos especiais de instruções:

Tópicos conceituais/Melhores práticas:

75
Stein Åsmul

Essa resposta é muito um trabalho em andamento e um esboço aproximado. 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

Devo também advertir que muitos arquivos MSI contêm erros, às vezes sérios, 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 a serem instaladas, por exemplo, um recurso de dicionário). Existem várias regras de práticas recomendadas 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 é executada 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, há 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 formato de script ou compilado. As 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).

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

  • erros de criação de componente (não seguindo as práticas recomendadas). Isso pode causar problemas de correção e atualizações com sintomas misteriosos, como arquivos e configurações ausentes 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.
  • problemas de atualização relacionados aos dados do usuário sendo substituídos ou redefinidos. Veja mais detalhes abaixo.
  • planejamento incorreto de ações customizadas fora da "seção transacionada" das seqüências de instalação ou ações customizadas 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 (pense na consolidação da transação do banco de dados) é executada entre as ações padrão InstallInitialize e InstallFinalize na sequência principal de instalação e é executado 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.
  • desenhos errados que causam ciclos repetitivos de auto-reparo ocorrem sem motivo óbvio. Aqui está outro artigo sobre este assunto, em installsite.org
  • ações personalizadas 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 tanto detalhado e demorado): Desinstalar no 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. Novamente, consulte o link no ponto anterior para obter uma descrição mais detalhada dos níveis da interface do usuário.
  • a instalação contém arquivos que não devem ser implantados no local em que estão sendo instalados. Geralmente, os arquivos do sistema devem ser instalados lado a lado na pasta Assembly do winsxs.
  • velocidade de instalação lenta é outro "problema" que muitos relatam com o MSI. Aqui estão algumas dicas sobre o assunto . O Windows Installer geral apresenta um pouco de sobrecarga devido aos pesados ​​requisitos de registro no registro do que está sendo instalado.
  • substituindo 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, é tratado como uma "transação de alteração", no caso anterior). operação de substituição de arquivo, que geralmente está incorreta, a menos que o arquivo INI ofereça formatação fora do padrão ou seções de comentários grandes que você deseja implantar com o arquivo) (comum para certas ferramentas de desenvolvedor).
  • as regras complexas para substituição de arquivos podem fazer com que os arquivos sejam substituídos acidentalmente ou nem 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 levemente 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 eles 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. Verifique este artigo: Auto-registro considerado prejudicial .
  • uma variação no problema de substituição de arquivo ocorre quando uma atualização importante (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.
  • 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 usando auto-recuperação ou 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 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 é rigorosamente 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 na Internet durante a instalação 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 à configuração de proxy ausente nos 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 através da instalação .
  • Installshield usado para instalar um tempo de execução para seu idioma InstallScript . Essa instalaçã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 tenho certeza qual, uma ou outra - provavelmente área restrita) de maneira confiável. Porém, as configurações mais antigas do Installshield podem exibir esse problema de implantação. Existe um site de suporte herdado do Installshield para problemas como estes: http://consumer.installshield.com/common.asp
  • Várias configurações podem exibir um 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 de idioma - toda uma área de conhecimento por si só (traduza texto em imagens, traduza o próprio software, traduza material de marketing, lide com solicitações de suporte internacional, adaptação às configurações de idioma no SO, 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 obter 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 da maneira que for necessária. No entanto, é bastante comum para INI arquivos a serem instalados como um arquivo em vez de como valores segmentados. Isso pode fazer com que o arquivo INI seja substituído durante a reinstalação, em vez de ser atualizado. Um MSI muito comum problema.
  • 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 Prática recomendada do Windows Installer de [~ # ~] msdn [~ # ~] .

25
Stein Åsmul

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.

5
Wayne Koorts

Além disso, consulte código-fonte aberto Windows Installer XML ", 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 MSI e MSM pacotes de instalação ". Isso é usado pela MS para preparar vários de seus principais pacotes de software.

2
Ian Kelling

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.

0
pQd