Compartilhar via

/CLR (common Language Runtime Compilation)

  • Artigo

Permite que aplicativos e componentes usar os recursos do common language runtime (CLR).

/clr[:options]

Argumentos

  • options
    Uma ou mais das seguintes opções, vírgula-separados.

    • /clr
      Cria os metadados para o aplicativo.Os metadados podem ser consumidos por outros aplicativos CLR e permite que o aplicativo consumir dados nos metadados de outros componentes do CLR e tipos.

      Para obter mais informações, consulte

      Mistos Assemblies (nativos e gerenciados)e

      Como: Migrar para /clr.

    • /clr:pure
      Produz um Microsoft Intermediate Language (MSIL)-somente o arquivo de saída que não possui nenhum código executável nativo.No entanto, ele pode conter tipos nativos compilados para MSIL.

      Para obter mais informações, consulte Código puro e verificável (C + + / CLI).

    • /clr:safe
      Produz um MSIL somente (não executável código nativo), arquivo de saída verificável./clr:safepermite o diagnóstico de verificação (PEVerify ferramenta (peverify)).

      Para obter mais informações, consulte Writing Verifiably Type-Safe Code.

    • /clr:oldSyntax
      Permite que Managed Extensions for C++ a sintaxe, o que é o original Visual C++ sintaxe de programação do CLR. 

      Managed Extensions for C++ a sintaxe está obsoleto.Use /clr:oldSyntax somente se você está mantendo um aplicativo que usa o Managed Extensions for C++.Se você estiver desenvolvendo um novo aplicativo, use a sintaxe atualizada.Para obter mais informações, consulte Extensões de componente para plataformas de tempo de execução.

      Se você tiver um Managed Extensions for C++ do aplicativo, você pode atualizar o projeto para 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, o noAssembly opção não está em vigor.

      O noAssembly opção é obsoleto.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 do assembly no manifesto é conhecido como um módulo de.O noAssembly opção pode ser usada somente para produzir um módulo.Se você compilar usando /c e /clr:noAssembly, em seguida, especifique o /NOASSEMBLY opção na fase de vinculador para criar um módulo.

      Antes do Visual C++ 2005, /clr:noAssembly implícita /clr.No entanto, /clr agora também oferece suporte a /clr:oldSyntax, portanto, você deve especificar o /clr de formulário quando você especifica /clr:noAssembly.Por exemplo, /clr:noAssembly /clr cria um módulo usando a nova Visual C++ sintaxe CLR e /clr:noAssembly,oldSyntax cria um módulo usando Managed Extensions for C++.

      Antes do Visual C++ 2005, /clr:noAssembly necessária /LD./LDagora está implícito quando você especifica /clr:noAssembly.

    • /clr:initialAppDomain
      Permite que um Visual C++ aplicativo seja executado na versão 1 do CLR.Se você usar initialAppDomain, e em seguida, você poderá ver alguns dos problemas que são discutidos em BUG: AppDomainUnloaded exceção quando você usa o managed extensions para componentes do Visual C++ no site de suporte da Microsoft.

      Um aplicativo que é compilado, usando initialAppDomain não deve ser usado por um aplicativo que usa o ASP.NET porque ele não é suportado na versão 1 do CLR.

    • /clr:nostdlib
      Instrui o compilador ignorar o diretório padrão de \clr.O compilador produz erros se você estiver incluindo várias versões de DLL, como System. dll.O uso dessa opção permite especificar a estrutura específica para usar durante a compilação.

Comentários

Código gerenciado é um código que pode ser inspecionado e gerenciado pelo CLR.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 consumam tipos gerenciados, consulte Extensões de componente para plataformas de tempo de execução.

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

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

Somente os tipos CLR serão instanciados no heap coletado ao lixo.Para obter mais informações, consulte Classes e Estruturas (Extensões de Componentes C++).Para compilar uma função para código nativo, use o unmanaged pragma.Para obter mais informações, consulte gerenciado, não gerenciado.

Por default, /clr não está efetivo.Quando /clr está em vigor, /MD também está em vigor.Para obter mais informações, consulte / MD, /MT, /LD (biblioteca de tempo de execução de uso)./MDgarante que as versões dinamicamente vinculadas, multithread das rotinas do runtime são selecionadas dos arquivos de cabeçalho padrão (. h).Multithreading é exigido para o managed programação porque o coletor de lixo do CLR executa os finalizadores em um segmento auxiliar.

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

/clrimplica /EHae nenhum outro /EH opções são suportadas para /clr.Para obter mais informações, consulte /EH (modelo de manipulação de exceção).

Para obter informações sobre como determinar o tipo de imagem 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 de compilador biblioteca run-time (/MD ou /LD).

Use o /ASSEMBLYRESOURCE. opção de vinculador para incorporar um recurso em um assembly./ DELAYSIGN, /KEYCONTAINER, e /KEYFILE opções do vinculador também permitem que você personalize como um assembly é criado.

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

As variáveis globais em um arquivo de objeto nativo são inicializadas primeiro (durante DllMain se o executável é uma DLL) e, em seguida, as variáveis globais na seção gerenciada são inicializados (antes que qualquer código gerenciado é executado).#pragmainit_seg só afeta a ordem de inicialização nas categorias gerenciadas e não gerenciadas.

Compilando usando /clr:safe é análogo à compilação por meio de /Platform: AnyCPU em linguagens como, por exemplo, C#.

Imagens seguras e puras

Uma imagem pura usa uma versão do CLR a biblioteca do C Runtime (CRT).No entanto, a CRT não é verificável, é possível usar a CRT quando você compilar usando /clr:safe.Para obter mais informações, consulte Recursos da biblioteca CRT.

Exemplos de código nativo que não pode aparecer em uma imagem pura assembly embutido, setjmp, e longjmp.

Cada ponto de entrada de uma imagem puro ou seguro é 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 pode ser por processo.Para /clr:pure, apesar de appdomain é o padrão, você pode usar processo variáveis.

Quando a execução de um arquivo. exe de 32 bits que foi compilado usando /clr ou /clr:pure em um sistema operacional de 64 bits, o aplicativo será executado no WOW64, o que permite que um aplicativo de 32 bits em execução no CLR de 32 bits em um sistema operacional de 64 bits.Por padrão, um arquivo. exe que é compilado, usando /clr:safe será executado no CLR 64-bit em um computador que esteja executando um sistema operacional de 64 bits.(Em um sistema operacional de 32 bits, o mesmo arquivo. exe seria executado no CLR de 32 bits). No entanto, um aplicativo seguro foi possível carregar um componente de 32 bits.Nesse caso, uma imagem de segurança em execução com o suporte de 64 bits do sistema operacional irá falhar ao carregar o aplicativo de 32 bits (BadFormatException).Para garantir que uma imagem de segurança continua a executar quando ele carrega uma imagem de 32 bits em um sistema operacional de 64 bits, você deve usar /CLRIMAGETYPE para alterar os metadados (.corflags) e marcá-lo para ser executado no WOW64.A linha de comando a seguir é um exemplo.(Substitua 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 Usar uma listagem para o modo decorada nomes.Para obter mais informações sobre a programação de 64 bits, consulte Configurar programas para 64 bits (Visual C++).

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

Metadados e Classes sem nome

Classes sem nome aparecerá nos metadados nomeados da seguinte maneira: $UnnamedClass$crc do nome do arquivo atual$índice$, onde índice é uma contagem seqüencial das classes sem nome na compilação.Por exemplo, o exemplo de código a seguir gera uma classe sem nome nos metadados.

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

Use o Ildasm. exe para exibir os metadados.

Para definir essa opção de compilador em Visual Studio

  1. Em Solution Explorer, clique com o botão direito no nome do projeto e, em seguida, clique em Propriedades para abrir o projeto Páginas de propriedades caixa de diálogo.

  2. Selecione o Propriedades de configuração pasta.

  3. No Geral propriedade de página, modificar o suporte a Common Language Runtime propriedade.

    ObservaçãoObservação

    Quando /clr está habilitada no Páginas de propriedades caixa de diálogo, propriedades de opção de compilador que não são compatíveis com /clr também são ajustados, conforme necessário.Por exemplo, se /RTC está definido e, em seguida /clr estiver habilitada, /RTC serão desativadas.

    Além disso, quando você depura um /clr aplicativo, defina a Tipo de depurador propriedade para mista ou gerenciado apenas.Para obter mais informações, consulte Configurações de 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).

Para definir essa opção de compilador programaticamente

Consulte também

Referência

Opções do compilador

Configurando opções de compilador