/clr (compilação do Common Language Runtime)

Artigo
06/09/2015

Habilita aplicativos e componentes usar os recursos do Common Language Runtime (CLR).

/clr[:options]

Arguments

options
Um ou mais dos seguintes opções, separados por vírgulas.
- /clr
  Cria metadados para o aplicativo. Os metadados podem ser consumidos por outros aplicativos de CLR, e permitem que o aplicativo consumir tipos e dados nos metadados de outros componentes do CLR.
  
  Para obter mais informações, consulte
  
  Assemblies mistos (nativos e gerenciados) e
  
  Como migrar para /clr.
- /clr:pure
  Gerencie uma linguagem intermediária da Microsoft (MSIL) somente o arquivo de saída que não tem nenhum código executável nativo. No entanto, pode conter os tipos nativos compilados a MSIL.
  
  Para obter mais informações, consulte Código puro e verificável (C++/CLI).
- /clr:safe
  Gerencie um MSIL-only (nenhum código executável nativo), arquivo de saída verificável. /clr:safe habilita diagnóstico de verificação (Ferramenta PEVerify (Peverify.exe)).
  
  Para obter mais informações, consulte Writing Verifiably Type-Safe Code.
- /clr:oldSyntax
  Habilita extensões gerenciadas para a sintaxe C++, que é a sintaxe original de Visual C++ para a programação de CLR.
  
  As extensões gerenciadas para a sintaxe C++ são preteridas. Use /clr:oldSyntax apenas se você estiver mantendo um aplicativo que usa extensões gerenciadas para C++. Se você estiver desenvolvendo um novo aplicativo, use a sintaxe atualizado. Para obter mais informações, consulte Recursos de idioma para o direcionamento do CLR.
  
  Se você tiver extensões gerenciadas para o aplicativo C++, você pode atualizar o projeto usar a nova sintaxe. Para obter mais informações, consulte Portando e atualizando programas.
- /clr:noAssembly
  Especifica que um manifesto do assembly não deve ser inserido no arquivo de saída. Por padrão, a opção de noAssembly não é aplicado.
  
  A opção de noAssembly é substituída. Use /LN (criar módulo MSIL) em vez disso. Para obter mais informações, consulte Deprecated Compiler Options.
  
  Um programa gerenciado que não tem metadados de assembly no manifesto é conhecido como um módulo. A opção de noAssembly pode ser usada para produzir somente um módulo. Se você compila usando /c e /clr:noAssembly, especifique a opção de /NOASSEMBLY na fase do vinculador criar um módulo.
  
  Antes do Visual C++ 2005, /clr:noAssembly sugerido /clr. No entanto, /clr também oferece suporte a /clr:oldSyntax, de modo que você deve especificar o formato de /clr quando você especifica /clr:noAssembly. Por exemplo, /clr:noAssembly /clr cria um módulo usando a nova sintaxe de Visual C++ CLR e /clr:noAssembly,oldSyntax cria um módulo usando extensões gerenciadas para C++.
  
  Antes do Visual C++ 2005, /clr:noAssembly necessária /LD. /LD é sugerida agora quando você especifica /clr:noAssembly.
- /clr:initialAppDomain
  Permite que um aplicativo de Visual C++ executar na versão 1 do CLR. Se você usar initialAppDomain, você pode ver alguns dos problemas que são discutidos em BUG: Exceção de AppDomainUnloaded quando você usar extensões gerenciadas para componentes do Visual C++ no site de suporte da Microsoft.
  
  Um aplicativo que é construído usando initialAppDomain não deve ser usado por um aplicativo que usa o ASP.NET porque não tem suporte na versão 1 do CLR.
- /clr:nostdlib
  Instrui o compilador para ignorar o diretório padrão \ CLR. O compilador gerenciar erros se você está incluindo várias versões de um DLL como System.dll. Usar essa opção permite especificar a estrutura específica a ser usado durante a compilação.

Comentários

O código gerenciado é o código que pode ser inspecionado e gerenciado por CLR. O código gerenciado pode acessar objetos gerenciados. Para obter mais informações, consulte /clr Restrições.

Para obter informações sobre como desenvolver aplicativos que definem e consomem tipos gerenciados, consulte Recursos de idioma para o direcionamento do CLR.

Um aplicativo compilado usando /clr pode ou não pode conter dados gerenciados.

Para habilitar a depuração em um aplicativo gerenciado, consulte /ASSEMBLYDEBUG (Adicionar DebuggableAttribute).

Apenas os tipos CLR serão instanciados no heap com coletados. Para obter mais informações, consulte Classes e estruturas (gerenciadas). Para criar uma função em código nativo, use o pragma de unmanaged . Para obter mais informações, consulte gerenciado, não gerenciado.

Por default, /clr não está ativo. Quando /clr é aplicado, /MD também é aplicado. Para obter mais informações, consulte /MD, /MT, /LD (usar biblioteca em tempo de execução). /MD garante que as versões dinamicamente vinculadas, multi-threaded de rotinas de tempo de execução estão selecionadas do cabeçalho .h (padrão). A multithreading é necessária para a programação gerenciada como o coletor de lixo de CLR executa finalizers em um thread auxiliar.

Se você compila usando /c, você pode especificar o tipo CLR (IJW, isento, ou puro) do arquivo de saída resultante com /CLRIMAGETYPE.

/clr implica /EHa, e nenhuma outra opção de /EH tem suporte para /clr. Para obter mais informações, consulte /EH (modelo de tratamento de exceções).

Para obter informações sobre como determinar o tipo de imagem de CLR de um arquivo, consulte /CLRHEADER.

Todos os módulos passados para uma determinada invocação do vinculador devem ser compilados usando a mesma opção do compilador da biblioteca de tempo de execução (/MD ou /LD).

Use a opção do vinculador de /ASSEMBLYRESOURCE inserir um recurso em um assembly. /DELAYSIGN, /KEYCONTAINER, e as opções do vinculador de /KEYFILE também permitem personalizar como um assembly é criado.

Quando /clr for usado, o símbolo de _MANAGED está definido como 1. Para obter mais informações, consulte Macros predefinidas.

Variáveis globais em um arquivo de objeto nativo são inicializados primeiro (durante DllMain se o executável é uma DLL), e variáveis globais na seção gerenciado são inicializados em (antes que a execução do código gerenciado). #pragmainit_seg afeta somente a ordem de inicialização em categorias gerenciados e não gerenciados.

A compilação usando /clr:safe equivale a criar usando /platform: anycpu em linguagens como C#.

Imagens estejam seguras e puras

Uma imagem pura usa uma versão de CLR da biblioteca (CRT) de tempo de execução C. No entanto, o CRT não é verificável, portanto você não pode usar o CRT quando você compila usando /clr:safe. Para obter mais informações, consulte Recursos da biblioteca CRT.

Os exemplos de código nativo que não podem aparecer em uma imagem pura incluem o assembly embutido, o setjmp, e o longjmp.

Cada ponto de entrada de uma imagem pura ou segura é gerenciado. Quando você compila usando /clr, o ponto de entrada é nativo. Para obter mais informações, consulte __clrcall.

Quando você compila usando /clr:safe, por padrão, as variáveis são appdomain e não podem ser criados pelo processo. Para /clr:pure, embora appdomain é a opção, é possível usar variáveis de processo .

Ao executar um arquivo .exe de 32 bits que foi criado com /clr ou /clr:pure em um sistema operacional de 64 bits, o aplicativo será executado sob WOW64, que permite que um aplicativo de 32 bits sejam executados em CLR de 32 bits em um sistema operacional de 64 bits. Por padrão, um arquivo .exe que é criada usando /clr:safe será executado em CLR de 64 bits em um computador que esteja executando um sistema operacional de 64 bits. (Em um sistema operacional de 32 bits, o mesmo arquivo .exe executará em CLR de 32 bits.) No entanto, um aplicativo seguro foi possível carregar um componente de 32 bits. Nesse caso, uma execução segura de imagem no suporte de 64 bits do sistema operacional falhará quando carrega o aplicativo de 32 bits (BadFormatException). Para assegurar que uma imagem continue executando segura quando carregar uma imagem de 32 bits em um sistema operacional de 64 bits, você deve usar /CLRIMAGETYPE para alterar os metadados (.corflags), e marque-os a ser executado sob WOW64. A linha de comando a seguir é um exemplo. (Substituir seu próprio símbolo de entrada.)

cl /clr:safe t.cpp /link /clrimagetype:pure /entry:?main@@$$HYMHXZ /subsystem:console

Para obter informações sobre como obter um nome decorado, consulte Usando uma listagem para exibir nomes decorados. Para obter mais informações sobre a programação de 64 bits, consulte Configurar programas para 64 bits (Visual C++).

Para obter exemplos, os passo a passo, e mais informações, consulte:

Metadados e classes sem-nome

As classes sem-nome aparecerão nos metadados chamada como segue: $UnnamedClass$crc-of-current-file-name$index$, onde index é uma contagem sequencial das classes sem-nome na compilação. Por exemplo, o exemplo de código gerenciado uma classe sem-nome nos metadados.

// clr_unnamed_class.cpp
// compile by using: /clr /LD
class {} x;

Use ildasm.exe para exibir metadados.

Para definir esta opção do compilador no Visual Studio

Em Gerenciador de Soluções, clique com o botão direito do mouse no nome de projeto, e clique em Propriedades para abrir a caixa de diálogo de Páginas de Propriedades do projeto.
Selecione a pasta de Propriedades de Configuração .
Na página de propriedades de Geral , modifique a propriedade de Suporte a Common Language Runtime .

Dica

Quando /clr é habilitado na caixa de diálogo de Páginas de Propriedades , as propriedades padrão do compilador que não são compatíveis com /clr sejam ajustadas também, conforme necessário.Por exemplo, se /RTC é ajustado e /clr está habilitado em seguida, /RTC será desativada.

Além disso, quando você depura um aplicativo de /clr , defina a propriedade de Tipo de Depurador a Misto ou a Gerenciado somente.Para obter mais informações, consulte Definições do projeto para uma configuração de depuração do C++.

Para obter informações sobre como criar um módulo, consulte /NOASSEMBLY (criar um módulo MSIL).