Visual Studio Implantação do Installer

Artigo
08/04/2011

Implantação do Windows Installer permite criar pacotes de instalador para ser distribuído aos usuários; o usuário executa o arquivo de instalação e as etapas através de um Assistente para instalar o aplicativo. Isso é feito adicionando um projeto de instalação à sua solução. Quando criado, o projeto cria um arquivo de instalação que você distribui para os usuários; o usuário executa o arquivo de instalação e as etapas através de um Assistente para instalar o aplicativo.

De Microsoft Windows Installer é um orientados a dados de instalação e configuração do serviço fornecido como parte do sistema operacional Windows. Windows Installer mantém um banco de dados de informações sobre todos os aplicativos instalados, incluindo arquivos, chaves do registro e componentes. Quando um aplicativo é desinstalado, o banco de dados é verificado para certificar-se de que nenhum outro aplicativo se baseiam em um arquivo, a chave do registro ou o componente antes de removê-lo. Isso impede que a remoção de um aplicativo a partir de quebrar a outro.

Observação
As Express Editions não incluem a tecnologia Windows Installer. Para obter informações sobre a tecnologia de implantação usada nas edições Express, consulte <>>Implantação e segurança do ClickOnce.

Usando as ferramentas de implantação no Visual Studio com a funcionalidade fornecida pelo Windows Installer, você pode implantar e manter seus aplicativos.

Criando um pacote de instalador

Você deve usar um pacote de instalador para implantar seu aplicativo e seus pré-requisitos. Normalmente, os aplicativos têm dependências.NET Framework, SQL Server Express, ou até mesmo um personalizado. EXE ou DLL. No entanto, é indefinido se os computadores de usuário final tem a versão específica do.NET Framework ou outras dependências que seu aplicativo depende. Por esse motivo, não é recomendável copiar seu aplicativo para o computador do usuário final.

Local de instalação

Os usuários finais podem instalar seu aplicativo da Web, CD, compartilhamento de arquivos de rede ou de outras alternativas. O local de instalação afeta o modelo de projeto que você pode usar. Por exemplo, se desejar que os usuários finais para instalar a partir da Web, você pode usar o modelo de projeto Web Setup. Para instalar a partir de um CD ou rede, use o modelo de projeto de instalação. Para obter mais informações sobre modelos de projetos de implantação, consulte Setup and Deployment Projects.

Arquivos e pastas

Você pode usar o File System Editor para controlar onde e como os arquivos de implantação são instalados. A organização do sistema de arquivos pode diferir de um computador para outro e nomes de pasta também podem ser diferentes; o File System Editor usa o conceito de pastas abstratos para garantir que os arquivos sejam instalados onde você deseja. Para obter mais informações, consulte File Installation Management in Deployment.

Pastas virtuais representam pastas de sistema do Windows. Por exemplo, o Pasta Desktop é o equivalente da área de trabalho da pasta do sistema. Windows rastreia o local das pastas do sistema, portanto, não importa onde se encontra a pasta ou o que ele é chamado, arquivos colocados a Pasta Desktop sempre acabar na pasta do sistema de Desktop. Para obter mais informações, consulte Pastas especiais e pastas Personalizar.

Você também pode criar suas próprias pastas e colocá-los em um local abaixo de qualquer pasta do sistema. Por exemplo, você pode criar uma pasta de dados do aplicativo sob o A pasta de aplicativo — independentemente de onde o A pasta de aplicativo está localizado em um computador de destino, os arquivos colocados na pasta sempre será instalada no mesmo local relativo de dados do aplicativo. Para obter mais informações, consulte How to: Adicionar e Remover pastas Arquivo System Editor.

Pastas de File System Editor pode conter arquivos, saídas de projeto e assemblies. Saídas de projeto representam os itens contidos em outro projeto na solução e podem incluir a saída de compilação principal (por exemplo, um arquivo executável), recursos localizados, informações de depuração simbólica, arquivos de conteúdo (por exemplo, páginas HTML) e os arquivos de origem do projeto. Cada uma dessas saídas é conhecida como um grupo de saída do projeto; um project output group contém a saída primária (também conhecido como a saída de chave), além de quaisquer resultados adicionais e dependências. Para obter mais informações, consulte How to: Adicionar e Remover saídas de projetos no Arquivo System Editor e How to: Adicionar Itens a um projeto de implantação.

Além disso, as condições podem ser colocadas em qualquer arquivo ou pasta usando o condição propriedade. Isso permite que você personalize a instalação dos arquivos com base nas condições que existem em um computador de destino durante a instalação. Por exemplo, você pode escolher instalar os arquivos diferentes com base na versão do sistema operacional no computador de destino. Para obter mais informações, consulte Propriedade condition.

O File System Editor também suporta a criação de atalhos, permitindo que você colocar os arquivos em uma pasta e aponte-los a partir de um atalho na área de trabalho ou em outra pasta. Para obter mais informações, consulte How to: Adicionar e Remover atalhos Arquivo System Editor.

Associações de arquivo

Quando você implanta um aplicativo, você freqüentemente deseja associar um tipo de arquivo do aplicativo. Por exemplo, se seu aplicativo cria e usa arquivos com uma extensão de .myfile, você deseja que o aplicativo seja associado ao tipo de arquivo .myfile para que quando um usuário clica duas vezes em um arquivo de .myfile, ele abrirá no seu aplicativo.

Ferramentas de implantação da Visual Studio incluem uma File Types Editor, que permite que você especificar os tipos de documento e associar extensões de arquivo. Além disso, você pode especificar os verbos ou ações para cada documento, digite e especificar os tipos MIME para os tipos de documento para uso em navegadores. Para obter mais informações, consulte File Types Management in Deployment.

Durante a instalação, as configurações que você especificar o File Types Editor são atualizados no computador de destino.

Registro

Muitas vezes, parte integrante da implantação de um aplicativo envolve a acessar o registro, definindo valores do registro ou a criação de chaves do registro. Ferramentas de implantação da Visual Studio fornecem essa funcionalidade.

O Editor do registro na Visual Studio é semelhante para o Editor do registro do Windows: ambas as ferramentas fornecem uma representação hierárquica de registro em um computador de destino. As raízes do registro padrão são representadas. Alterar valores de chaves existentes, adicionar valores de novas chaves e especificar teclas padrão. Para obter mais informações, consulte Gerenciamento de Configurações do registro na implantação.

Durante a instalação, chaves e valores especificados na Editor do registro são gravadas no registro do computador de destino.

Além disso, você pode colocar as condições em qualquer chave do registro ou valor usando o condição propriedade. Isso permite que você personalize o registro com base nas condições que existem em um computador de destino durante a instalação. Por exemplo, você talvez queira inserir um valor do registro diferente, dependendo da versão do sistema operacional no computador de destino.

A assinatura Authenticode

Você talvez queira assinar um aplicativo ou componente para que os usuários podem verificar quem o publicou e verificar o que é seguro. Recomendamos que você assinar arquivos Cab e os instaladores que são baixadas através de um navegador da Web.

Você pode usar Visual Studio as ferramentas de implantação para assinar um instalador, um módulo de mesclagem ou um arquivo Cab, usando a tecnologia do Microsoft Authenticode. Primeiro, você deve obter um certificado digital para assinar seu aplicativo ou componentes.

Para usar a assinatura Authenticode, você deve habilitar assinados manifestos de ClickOnce em seu projeto de implantação. Para obter mais informações, consulte Assinatura de Página, o criador do projeto.

Cache global de assemblies

O cache de assembly global é um cache de código fornecido pelo .NET Framework que é usado para armazenar os assemblies que precisam ser compartilhados por vários aplicativos. Para ser instalado no cache global de assemblies, o assembly deve ser fortes, que oferece um aplicativo ou componente uma identidade exclusiva que outro software pode usar para identificar e referir-se explicitamente a ele. Para obter mais informações, consulte Como: Assinar um Assembly (Visual Studio).

Para instalar um assembly no cache global de assemblies, adicione o assembly ou o grupo de saída do projeto para o assembly para o Global Assembly Cache pasta do File System Editor. Para abrir este editor na Exibir , aponte para Editore clique em arquivo sistema Editor.

O Global Assembly Cache pasta é diferente das outras pastas no File System Editor. Ele não tem propriedades que são configuráveis e não é possível criar atalhos para a pasta ou assemblies na pasta.

Selecionar pré-requisitos

Para implantar um aplicativo, você também deve implantar todos os componentes citados pelo aplicativo. Por exemplo, a maioria dos aplicativos criados com Visual Studio têm uma dependência de .NET Framework. Uma versão necessária do common language runtime deve estar presente no computador de destino antes do aplicativo está instalado. Ferramentas de implantação da Visual Studio permitem que você instale o .NET Framework e outros componentes como parte da instalação. O processo de instalação de componentes de pré-requisito também é conhecido como de inicialização.

Para mais informações, consulte: How to: Instalar pré-requisitos na implantação do Windows Installer.

Instalando com privilégios administrativos

Instalação administrativa é um recurso do Microsoft Windows Installer que permite que você instale uma imagem de origem de um aplicativo em um compartilhamento de rede. Usuários que têm acesso ao compartilhamento de rede em um grupo de trabalho, em seguida, podem instalar o aplicativo da imagem de origem.

O User Interface Editor permite que você especifique um conjunto diferente de caixas de diálogo de instalação que são exibidos quando um administrador instala o aplicativo para um compartilhamento de rede por meio da linha de comando usando o /a a opção de linha de comando (msiexec /aInstallerName). Para obter mais informações, consulte Gerenciamento de Interface de usuário na implantação.

Observação
Ao instalar um aplicativo por meio de instalação administrativa, carregando os arquivos de aplicativo (os arquivos que instalam o Windows Installer, se necessário) não são copiados para o mesmo que servidor de Bootstrapper for definida como Bootstrapper do Windows Installer. Se os arquivos do aplicativo de inicialização são necessários para instalação, você precisará copiar manualmente os arquivos de Instmsia.msi, Instmsiw.msi, Setup. exe e Setup. ini no servidor. Esses arquivos podem ser encontrados no mesmo diretório do arquivo. msi do aplicativo.

Ao instalar um aplicativo por meio de instalação administrativa, carregando os arquivos de aplicativo (os arquivos que instalam o Windows Installer, se necessário) não são copiados para o mesmo que servidor de Bootstrapper for definida como Bootstrapper do Windows Installer. Se os arquivos do aplicativo de inicialização são necessários para instalação, você precisará copiar manualmente os arquivos de Instmsia.msi, Instmsiw.msi, Setup. exe e Setup. ini no servidor. Esses arquivos podem ser encontrados no mesmo diretório do arquivo. msi do aplicativo.

Para obter mais informações, consulte a documentação do SDK do Windows Installer em A instalação administrativa (Windows Installer).

Windows e a elevação

Tecnologia Windows Installer oferece suporte à instalação de software nos sistemas operacionais Windows Vista e Windows 7. O usuário final instalar aplicativos devem receber solicitações somente para cada instalação do componente que exija elevação, mesmo quando o computador do usuário é executado sob o controle de conta de usuário (UAC).

Elevação do aplicativo

Normalmente, o Setup. exe (também conhecido como o bootstrapper) não executa privilegiada; ele é executado no nível de permissão do usuário atual. Portanto, a instalação não solicitar elevação quando a instalação do final do aplicativo é iniciado. No entanto, observe que um arquivo. msi geralmente solicita que o usuário, enquanto o Setup. exe não.

No manifesto UAC incorporado de bootstrapper, o requestedExecutionLevel nó Especifica que a instalação é executado como usuário atual (asInvoker):

No entanto, você pode elevar a instalação do aplicativo se for necessário. Por exemplo, modificando as configurações do Internet Information Services (IIS) em um Web Setup project requer privilégios administrativos, como instalar assemblies no cache global de assemblies. O prompt de elevação ocorre após as instalações de pré-requisito, mas antes da instalação do aplicativo.

Para elevar as permissões para uma instalação, abra o arquivo de projeto (.vdproj). No arquivo de projeto MsiBootstrapper seção, defina a RequiresElevation propriedade para True. Esta propriedade não é disponibilizada por meio do ambiente de desenvolvimento integrado (IDE) do Visual Studio. Portanto, você deve usar o arquivo de projeto. Para obter mais informações, consulte Propriedade de RequiresElevation.

Elevação assistido do administrador

Windows Installer oferece suporte a elevação assistido de administrador no Windows Vista e Windows 7. Nesse cenário, o usuário será solicitado a fornecer credenciais de administrador e o administrador digita a senha do usuário. Para oferecer suporte a esse cenário, os conjuntos de bootstrapper de AdminUser propriedade para True quando o computador está executando no Windows Vista ou uma versão posterior do Windows.

Observação
Se você estiver executando o Windows Vista em um computador que não utilizam o UAC e você não for um administrador, AdminUser ainda será definido como True. Portanto, os instaladores. exe (como SQLExpress32.exe) devem ser escritos para detectar as permissões apropriadas e gerar um código de saída específico no caso de permissão insuficiente. Você deve criar o Setup. exe para capturar o código de saída e exibir uma mensagem informando que um administrador é necessário.

Se você estiver executando o Windows Vista em um computador que não utilizam o UAC e você não for um administrador, AdminUser ainda será definido como True. Portanto, os instaladores. exe (como SQLExpress32.exe) devem ser escritos para detectar as permissões apropriadas e gerar um código de saída específico no caso de permissão insuficiente. Você deve criar o Setup. exe para capturar o código de saída e exibir uma mensagem informando que um administrador é necessário.

Elevação de pré-requisito

Windows Vista e Windows 7 eleva a instalação do componente de pré-requisito quando for necessário. O bootstrapper próprio não executa nenhuma elevação de privilégio; Quando o Windows Vista ou o Windows 7 é executado no UAC, ele emite um prompt para cada componente de pré-requisito que deve ser elevado, a menos que ele já está instalado. Se uma elevação de pacote falhar, o bootstrapper falhará e envia uma mensagem de erro apropriado.

Elevação de ação personalizada

Ações personalizadas que você cria no Editor Custom Actions execução privilegiadas. Ações personalizadas não devem acessar dados específicos do usuário, como, por exemplo, o registro ou o sistema de arquivos, porque a ação personalizada não será executado na conta de usuário chamada.

Por padrão, as ações personalizadas executadas com privilégios elevados porque a configuração padrão de NoImpersonate é de propriedade True no Editor de ações personalizadas. Alterar NoImpersonate para False forçaria a ação personalizada para representar o usuário chamar, quem poderá ter reduzido permissões.

Diferenças entre versões de Visual Studio

Observe também que haverá diferenças entre a maneira que Visual Studio 2005 e Visual Studio 2008 projetos de instalação serão executado em UAC.

Windows Vista ou o Windows 7 interna detecção do instalador solicitará o consentimento quando você executa no UAC. Um bootstrapper (Setup. exe) criado com Visual Studio 2005 sempre solicite consentimento, independentemente do que está instalando. Como Setup. exe e todos os seus processos executados com um token de administrador no Windows Vista e Windows 7, a instalação do aplicativo final será instalada com privilégios elevados. Se um usuário executa o Setup. exe com elevação assistido do administrador, o aplicativo será instalado sob o elevado perfil do usuário (não o perfil do administrador).

Em Visual Studio 2008 e 2010 Visual Studio, o Setup. exe não solicita elevação quando ele é iniciado. Para evitar que o prompt de elevação, o manifesto incorporado do bootstrapper Especifica que Setup. exe executado com uma execução solicitado nível de asInvoker. Isso fornece a vantagem da instalação do aplicativo final, não sendo executada privilegiada, embora ainda permitindo que a instalação dos componentes de pré-requisito elevado conforme necessário. As chamadas de bootstrapper ShellExecute para iniciar os pré-requisitos. Windows Vista ou o Windows 7 recebe essa chamada, realiza a detecção de instalação e emite um aviso antes da instalação para o usuário.

A desvantagem dessa alteração é que um prompt é emitido para cada componente de pré-requisito que tem de ser instalados, além do próprio aplicativo. No entanto, se todos os pré-requisitos já estiverem no computador, a instalação não pode causar avisos. Além disso, você não deve ter verificações externas que exigem elevação. Verificações externas funcionará, mas o usuário recebe diversos avisos de elevação para cada seleção externo, além da prompts para o instalador.

Consulte também

Compartilhar via