NGen (Native Image Generator)

O Native Image Generator (Ngen.exe) é uma ferramenta que melhora o desempenho de aplicativos gerenciados. NGen. exe cria nativas imagens, que são arquivos contendo compilado código de máquina de processador específico e instala no cache de imagem nativa no computador local. O runtime pode usar imagens nativas do cache em vez de usar o compilador just-in-time (JIT) para compilar o assembly original.

Altera para NGen. exe na .NET Framework versão 4:

• NGen. exe agora compila assemblies com confiança total e a diretiva de CAS (segurança) de acesso de código não é avaliada.

• As imagens nativas que são geradas com NGen. exe não podem ser carregadas em aplicativos que são executados em confiança parcial.

Altera para NGen. exe na.NET Framework versão 2.0:

• A instalação de um assembly também inclui suas dependências, simplificando a sintaxe do NGen. exe.

• Imagens nativas agora podem ser compartilhadas entre domínios de aplicativo.

• Uma nova ação, update, recria imagens que foram invalidadas.

• Ações podem ser adiadas para execução por um serviço que usa o tempo ocioso do computador para gerar e imagens de instalação.

• Algumas causas de invalidação de imagem foram eliminadas.

Para obter informações adicionais sobre como usar o NGen. exe e o serviço de imagem nativa, consulte Serviço de imagem nativa.

O Native Image Generator é instalado automaticamente com o Visual Studio. Para iniciar a ferramenta, use o Prompt de comando Visual Studio. No prompt de comando, digite o seguinte:

ngen action [options]
ngen /? | /help

Ações

A tabela a seguir mostra a sintaxe de cada action. Para obter descrições das partes individuais de um action, consulte a argumentos, Os níveis de prioridade, cenários, e Config tabelas. O Opções tabela descreve o options e opções de Ajuda.

Argumentos

Níveis de prioridade

Cenários

Config

Opções

Comentários

Para executar NGen. exe, você deve ter privilégios administrativos.

Cuidado
Não execute NGen. exe em assemblies que não são totalmente confiáveis.Começando com o .NET Framework versão 4, NGen. exe compila assemblies com confiança total e diretiva de CAS (segurança) de acesso de código não é avaliada.

Começando com o .NET Framework 4, as imagens nativas que são geradas com NGen. exe não podem ser carregadas em aplicativos que são executados em confiança parcial. Em vez disso, o compilador just-in-time (JIT) é invocado.

NGen. exe gera imagens nativas para o assembly especificado e todas as suas dependências. Dependências são determinadas a partir de referências no manifesto do assembly. A única situação em que você precisa instalar uma dependência separadamente é quando o aplicativo carrega-lo usando a reflexão, por exemplo, chamando o Assembly.Load método.

Importante
Não use o Assembly.LoadFrom método com imagens nativas.Uma imagem carregada com este método não pode ser usada por outros assemblies no contexto de execução.

NGen. exe mantém uma contagem de dependências. Por exemplo, suponha que MyAssembly.exe e YourAssembly.exe estão instalados no cache de imagem nativa, e ambas têm referências a OurDependency.dll. Se MyAssembly.exe é desinstalado, OurDependency.dll não for desinstalado. Só é removido quando YourAssembly.exe também é desinstalado.

Se você estiver gerando uma imagem nativa para um assembly no cache global de assemblies, especifique seu nome de exibição. Consulte Assembly.FullName.

As imagens nativas que gera do NGen. exe podem ser compartilhadas entre domínios de aplicativo. Isso significa que você pode usar o NGen. exe em cenários de aplicativos que exigem conjuntos de módulos podem ser compartilhadas entre domínios de aplicativo. Para especificar a neutralidade do domínio:

• Aplicar o LoaderOptimizationAttribute atributo para seu aplicativo.

• Definir o AppDomainSetup.LoaderOptimization propriedade quando você criar informações de configuração para um novo domínio de aplicativo.

Sempre use o código de domínio neutro ao carregar o mesmo assembly em vários domínios de aplicativo. Se uma imagem nativa é carregada em um domínio de aplicativo não seja compartilhada após ter sido carregado em um domínio compartilhado, ele não pode ser usado.

A geração de imagens para diferentes cenários

Após ter gerado uma imagem nativa para um assembly, o runtime tenta automaticamente localizar e usar esta imagem nativa sempre que ele executa o assembly. Várias imagens podem ser geradas, dependendo dos cenários de uso.

Por exemplo, se você executar um assembly em uma depuração ou cenário de criação de perfil, o runtime procura uma imagem nativa que foi gerada com o /Debug ou /Profile Opções. Se não é possível localizar uma imagem nativa correspondente, o tempo de execução reverte para compilação padrão do JIT. A única maneira depurar imagens nativas é criar uma imagem nativa com o /Debug opção.

O uninstall ação também reconhece cenários, portanto, você pode desinstalar todos os cenários ou somente selecionado cenários.

Determinar quando usar imagens nativas

Imagens nativas podem fornecer melhorias de desempenho em duas áreas: memória aprimorada use e reduziu o tempo de inicialização.

Melhor utilização de memória

Imagens nativas podem melhorar significativamente o uso de memória quando o código é compartilhado entre processos. Imagens nativas são arquivos do Windows PE, portanto, uma única cópia de um arquivo. dll pode ser compartilhada por vários processos; Por outro lado, o código nativo produzido pelo compilador JIT é armazenado na memória particular e não pode ser compartilhado.

Os aplicativos são executados em serviços de terminal também podem se beneficiar das páginas de código compartilhado.

Além disso, não carregar o compilador JIT salva uma quantidade fixa de memória para cada instância do aplicativo.

Inicialização mais rápida do aplicativo

Pré-compilar assemblies com NGen. exe pode melhorar o tempo de inicialização para alguns aplicativos. Em geral, os ganhos podem ser feitos quando aplicativos compartilham os conjuntos de componentes porque após o primeiro aplicativo foi iniciado os componentes compartilhados já estão carregados para aplicativos subseqüentes. Inicialização a frio, no qual todos os assemblies em um aplicativo devem ser carregados a partir do disco rígido, não se beneficiar o máximo de imagens nativas porque o tempo de acesso de disco rígido predominates.

Ligação de disco rígida pode afetar o tempo de inicialização, porque todas as imagens que são difíceis de vinculado para o aplicativo assembly principal deve ser carregada ao mesmo tempo.

Importância de endereços de Base do Assembly

Como as imagens nativas são arquivos do Windows PE, eles são sujeitos aos mesmos problemas rebasing como outros arquivos executáveis. O custo de desempenho de realocação é ainda mais pronunciado se a vinculação de disco rígida é empregada.

Para definir o endereço base para uma imagem nativa, use a opção apropriada do seu compilador para definir o endereço base para o assembly. NGen. exe usa esse endereço de base para a imagem nativa.

Você pode usar uma ferramenta como, por exemplo, dumpbin.exe para exibir o endereço base preferido de uma imagem nativa.

Resumo das considerações de uso

As seguintes considerações gerais e as considerações do aplicativo podem ajudar você decidir se deve empreender o esforço de avaliar as imagens nativas para seu aplicativo:

• Imagens nativas carregam mais rápido do que o MSIL, pois elas eliminam a necessidade de muitas atividades de inicialização, como, por exemplo, verificação de segurança de tipos e de compilação JIT.

• Imagens nativas exigem um conjunto de trabalho menor inicial porque não é necessário para o compilador JIT.

• Imagens nativas permitem o compartilhamento entre processos de código.

• Imagens nativas exigem mais espaço em disco rígido que os assemblies MSIL e podem exigir um tempo considerável para gerar.

• Imagens nativas devem ser mantidas.

  • Imagens precisarão ser regenerado quando o assembly original ou uma de suas dependências é atendida.

  • Um único assembly pode precisar de várias imagens nativas para uso em aplicativos diferentes ou em cenários diferentes. Por exemplo, as informações de configuração em dois aplicativos podem resultar em decisões de ligação diferente para o mesmo assembly dependente.

  • Imagens nativas devem ser geradas por um administrador; Isto é, de uma conta do Windows em que os administradores de grupo.

Com essas considerações gerais sobre a natureza do seu aplicativo deve ser considerada ao determinar se imagens nativas podem fornecer um benefício de desempenho:

• Se seu aplicativo é executado em um ambiente que usa muitos componentes compartilhados, imagens nativas, permitem que os componentes a ser compartilhada por vários processos.

• Se o seu aplicativo usa vários domínios de aplicativo, o imagens nativas permitem que as páginas de código a ser compartilhada entre domínios.

  Observação

  No.Imagens do NET Framework versões 1.0 e 1.1, nativo não podem ser compartilhadas entre domínios de aplicativo.Isso não acontece na versão 2.0 ou posterior.

• Se seu aplicativo será executado em um servidor de Terminal, imagens nativas permitem compartilhamento de páginas de código.

• Aplicativos grandes geralmente beneficiar compilação para imagens nativas. Pequenos aplicativos geralmente não se beneficiar.

• Para aplicativos de execução demorada, compilação JIT de tempo de execução executa um pouco melhor do que as imagens nativas. (Ligação de disco rígida pode atenuar essa diferença de desempenho em algum grau).

Ligação de disco rígido

Ligação de disco rígida aumenta o throughput e reduz o tamanho do conjunto de trabalho para imagens nativas. A desvantagem de vinculação de disco rígida é que todas as imagens que são difíceis de acoplado a um assembly devem ser carregadas quando o assembly foi carregado. Isso pode aumentar significativamente o tempo de inicialização para um aplicativo grande.

Ligação de disco rígida é apropriada para as dependências que são carregadas em cenários de desempenho crítico de todos os seus aplicativos. Como ocorre com qualquer aspecto do uso de imagem nativa, medidas de desempenho de cuidado são a única maneira de determinar se ligação rígida melhora o desempenho do aplicativo.

O DependencyAttribute e DefaultDependencyAttribute atributos permitem que você forneça dicas de ligação de disco rígido para NGen. exe.

Especificando uma dica de ligação para uma dependência.

Aplicar o DependencyAttribute a um assembly para indicar a probabilidade de que uma dependência especificada será carregada. LoadHint.Alwaysindica que a vinculação de disco rígida é apropriada, Default indica que o padrão para a dependência deve ser usado, e Sometimes indica que a vinculação de disco rígida não é apropriada.

O código a seguir mostra os atributos de um assembly que possui dois dependências. A dependência de primeira (Assembly1) é um candidato adequado para vinculação de disco rígido, e não o segundo (Assembly2).

Imports System.Runtime.CompilerServices
<Assembly:DependencyAttribute("Assembly1", LoadHint.Always)>
<Assembly:DependencyAttribute("Assembly2", LoadHint.Sometimes)>

using System.Runtime.CompilerServices;
[assembly:DependencyAttribute("Assembly1", LoadHint.Always)]
[assembly:DependencyAttribute("Assembly2", LoadHint.Sometimes)]

using namespace System::Runtime::CompilerServices;
[assembly:DependencyAttribute("Assembly1", LoadHint.Always)];
[assembly:DependencyAttribute("Assembly2", LoadHint.Sometimes)];

O nome do assembly não inclui a extensão de nome de arquivo. Nomes de exibição podem ser usados.

Especificando um padrão de dica de ligação para um Assembly

Dicas de ligação padrão só são necessários para assemblies que serão usados com freqüência e imediatamente por qualquer aplicativo que tem uma dependência. Aplicar o DefaultDependencyAttribute com LoadHint.Always para esses assemblies para especificar que a vinculação de disco rígida deve ser usada.

A Microsoft usa o DefaultDependencyAttribute para especificar a vinculação de disco rígida é o padrão para um número muito pequeno de assemblies na.NET Framework, tais como mscorlib. dll.

Solução de problemas

Para confirmar que as imagens nativas estão sendo usadas pelo seu aplicativo, você pode usar o Fuslogvw.exe (Assembly Binding Log Viewer). Selecione Imagens nativas na Categorias de Log caixa na janela do Visualizador de log de ligação. Fuslogvw.exe fornece informações sobre por que uma imagem nativa foi rejeitada.

Você pode usar o jitCompilationStart MDA gerenciado do Assistente de depuração (MDA) para determinar quando o compilador JIT é iniciado compilar uma função.

Processamento adiado

Geração de imagens nativas para um aplicativo muito grande pode levar um tempo considerável. Da mesma forma, as alterações em um componente compartilhado ou alterações nas configurações do computador podem exigir muitas imagens nativas para ser atualizado. O install e update Ações têm um /queue opção que filas a operação de execução retardada pelo serviço de imagem nativa. Além disso, o NGen. exe tem queue e executeQueuedItems ações que oferecem algum controle sobre o serviço. Para obter mais informações, consulte Serviço de imagem nativa.

Imagens nativas e compilação JIT

Se o NGen. exe encontrar quaisquer métodos em um assembly que não pode gerar, ele exclui da imagem nativa. Quando o tempo de execução executa este assembly, ele será revertido para a compilação JIT para os métodos que não foram incluídos na imagem nativa.

Além disso, as imagens nativas não são usadas se o assembly tiver sido atualizado, ou se a imagem foi invalidada por qualquer motivo.

Imagens inválidas

Quando você usa o NGen. exe para criar uma imagem nativa de um assembly, a saída depende as opções de linha de comando que você especificar e determinadas configurações no seu computador. Essas configurações incluem o seguinte:

• A versão do.NET Framework.

• A versão do sistema operacional, se a alteração for da família Windows 9x para a família de Windows NT.

• A identidade exata do assembly (recompilação muda de identidade).

• A identidade exata de todos os assemblies que o assembly referências (identidade de alterações de recompilação).

• Fatores de segurança.

NGen. exe registra essas informações quando ele gera uma imagem nativa. Quando você executa um assembly, o runtime procura a imagem nativa gerada com opções e configurações que correspondam ao ambiente atual do computador. O tempo de execução reverte para compilação JIT de um assembly, se ele não localizar uma imagem nativa correspondente. As seguintes alterações no ambiente e configurações de um computador causam imagens nativas para se tornar inválida:

• A versão do.NET Framework.

  Se você aplicar uma atualização para o.NET Framework, todas as imagens nativas que você criou usando o NGen. exe fique inválidas. Por essa razão, todas as atualizações da.NET Framework execute o Ngen Update comando, para garantir que todas as imagens nativas são geradas novamente. A.NET Framework cria automaticamente novas imagens nativas para o.NET Framework, bibliotecas que ele instala.

• A versão do sistema operacional, se a alteração for da família Windows 9x para a família de Windows NT.

  Se, por exemplo, se a versão do sistema operacional em execução em um computador mudar do Windows 98, Windows XP, todas as imagens nativas armazenadas no cache de imagem nativa tornam inválidas. No entanto, se o sistema operacional for alterada do Windows 2000 para o Windows XP, as imagens não são invalidadas.

• A identidade exata do assembly.

  Se você recompilar um assembly, a imagem nativa correspondente do assembly se torna inválida.

• A identidade exata de qualquer assemblies faz referência o assembly.

  Se você atualizar um assembly gerenciado, todas as imagens nativas que direta ou indiretamente dependem do assembly se tornar inválidas e precisam ser regeneradas. Isso inclui referências comuns e dependências de disco rígido é ligado. Sempre que uma atualização de software é aplicada, o programa de instalação deve ser executado uma Ngen Update comando para garantir que todas as imagens nativas de dependentes são regeneradas.

• Fatores de segurança.

  A alteração de diretiva de segurança de máquina para restringir as permissões concedidas anteriormente a um assembly pode causar uma imagem nativa compilada anteriormente para esse assembly se tornem inválidos.

  Para obter informações detalhadas sobre como o common language runtime administra code access security e como usar as permissões, consulte Segurança de Acesso de código.

Exemplos

O comando a seguir gera uma imagem nativa para ClientApp.exe, localizado no diretório atual e instala a imagem no cache de imagem nativa. Se existir um arquivo de configuração para o assembly, o NGen. exe usa a ele. Além disso, as imagens nativas são geradas para arquivos de qualquer arquivo. dll ClientApp.exe referências.

ngen install ClientApp.exe

Uma imagem instalada com o NGen. exe também é chamada de uma raiz. Uma raiz pode ser um aplicativo ou um componente compartilhado.

O comando a seguir gera uma imagem nativa para MyAssembly.exe com o caminho de especificado.

ngen install c:\myfiles\MyAssembly.exe

Quando a localização de módulos (assemblies) e suas dependências, NGen. exe usa a mesma lógica probing usada pelo common language runtime. Por padrão, o diretório que contém ClientApp.exe é usado como o diretório base do aplicativo, e todos os assembly probing começa nesse diretório. Você pode substituir esse comportamento usando o /AppBase opção.

Um assembly pode ter uma dependência sem uma referência, por exemplo, se ele carrega um arquivo. dll usando o Assembly.Load método. Você pode criar uma imagem nativa para um arquivo. dll usando informações de configuração para o assembly do aplicativo, com o /ExeConfig opção. O comando a seguir gera uma imagem nativa para MyLib.dll, usando as informações de configuração do MyApp.exe.

ngen install c:\myfiles\MyLib.dll /ExeConfig:c:\myapps\MyApp.exe

Assemblies instalados dessa forma não são removidos quando o aplicativo for removido.

Para desinstalar uma dependência, use as mesmas opções de linha de comando que foram usadas para instalá-lo. O comando a seguir desinstala o MyLib.dll do exemplo anterior.

ngen uninstall c:\myfiles\MyLib.dll /ExeConfig:c:\myapps\MyApp.exe

Para criar uma imagem nativa para um assembly no cache global de assemblies, use o nome de exibição do assembly. Por exemplo:

ngen install "ClientApp, Version=1.0.0.0, Culture=neutral, 
  PublicKeyToken=3c7ba247adcd2081, processorArchitecture=MSIL"

NGen. exe gera um conjunto separado de imagens para cada cenário de que instalação. Por exemplo, os comandos a seguir instala um conjunto completo de imagens nativas para operação normal, o outro completa definida para depuração e um terceiro para criação de perfil:

ngen install MyApp.exe
ngen install MyApp.exe /debug
ngen install MyApp.exe /profile

Exibindo o Cache de imagem nativa

Depois de imagens nativas são instaladas no cache, elas podem ser exibidas usando o NGen. exe. O comando a seguir exibe todas as imagens nativas no cache de imagem nativa.

ngen display

O display ação lista todos os assemblies de raiz primeiro, seguido de uma lista de todas as imagens nativas no computador.

Use o nome simples de um assembly para exibir informações somente para o assembly. O comando a seguir exibe todas as imagens nativas no cache de imagem nativa que corresponde ao nome parcial MyAssembly, suas dependências e todas as raízes que têm uma dependência no MyAssembly:

ngen display MyAssembly

Saber quais raízes dependem de um assembly de componente compartilhado é útil para avaliar o impacto de um update ação após o componente compartilhado é atualizado.

Se você especificar a extensão de arquivo do assembly, você deve especificar o caminho ou executar NGen. exe do diretório contendo o assembly:

ngen display c:\myApps\MyAssembly.exe

O comando a seguir exibe todas as imagens nativas no cache de imagem nativa com o nome MyAssembly e a versão 1.0.0.0.

ngen display "myAssembly, version=1.0.0.0"

Atualizando imagens

Imagens geralmente são atualizadas depois de um componente compartilhado foi atualizado. Para atualizar todas as imagens nativas que foram alterados ou cujas dependências foram alteradas, use o update ação com sem argumentos.

ngen update

Atualizar todas as imagens pode ser um processo demorado. Você pode enfileirar as atualizações para execução pelo serviço de imagem nativa usando o /queue opção. Para obter mais informações sobre o /queue as prioridades de opção e a instalação, consulte Serviço de imagem nativa.

ngen update /queue

Desinstalando imagens

NGen. exe mantém uma lista de dependências, de modo que os componentes compartilhados são removidos somente quando todos os assemblies que dependem delas foram removidos. Além disso, um componente compartilhado não é removido se ele tiver sido instalado como uma raiz.

O comando a seguir desinstala todos os cenários para a raiz ClientApp.exe:

ngen uninstall ClientApp

O uninstall ação pode ser usada para remover cenários específicos. O comando a seguir desinstala todos os cenários de depuração para ClientApp.exe:

ngen uninstall ClientApp /debug

O comando a seguir desinstala todos os cenários de uma versão específica de ClientApp.exe:

ngen uninstall "ClientApp, Version=1.0.0.0"

Os seguintes comandos desinstalar todos os cenários para "ClientApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3c7ba247adcd2081, processorArchitecture=MSIL", ou apenas o cenário de depuração do assembly:

ngen uninstall "ClientApp, Version=1.0.0.0, Culture=neutral, 
  PublicKeyToken=3c7ba247adcd2081, processorArchitecture=MSIL"
ngen uninstall "ClientApp, Version=1.0.0.0, Culture=neutral, 
  PublicKeyToken=3c7ba247adcd2081, processorArchitecture=MSIL" /debug

Como ocorre com o install ação, fornecer uma extensão requer tanto executando NGen. exe a partir do diretório contendo o assembly ou especificando um caminho completo

Para obter exemplos relacionados ao serviço de imagem nativa, consulte Serviço de imagem nativa.

Consulte também

Referência

Prompt de comando Visual Studio

Conceitos

Serviço de imagem nativa

Processo de Execução Gerenciada

Como o Runtime Localiza Assemblies

Outros recursos

Ferramentas.NET Framework

Histórico de alterações