Compartilhar via

/CLR (common Language Runtime Compilation)

  • Artigo

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

/clr[:options]

Arguments

  • options
    Uma ou mais das seguintes opções-CSV.

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

      For more information, see

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

      For more information, see Código puro e verificável.

    • /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 (Ferramenta de PEVerify (peverify)).

      For more information, see Escrevendo verificável com código de tipo seguro.

    • /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 de está obsoleto. Use /clr:oldSyntax somente se você está mantendo um aplicativo que usa Managed Extensions for C++. Se você estiver desenvolvendo um novo aplicativo, use a sintaxe atualizada. For more information, see Language Features for Targeting the CLR.

      Se você tiver um Managed Extensions for C++ aplicativo de, você pode atualizar o projeto para usar a nova sintaxe. For more information, see Portando e atualizando programas.

    • /clr:noAssembly
      Especifica que o manifesto do assembly não deve ser inserido no arquivo de saída. Por padrão, o noAssembly opção é não está em efeito.

      O noAssembly opção é preterida. Use /LN (Criar módulo MSIL) em vez disso. For more information, see Deprecated Compiler Options in Visual C++ 2005.

      Um programa gerenciado que não têm 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 formulário quando você especificar /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 o Managed Extensions for C++.

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

    • /clr:initialAppDomain
      Permite que um Visual C++ aplicativo seja executado na versão 1 do CLR. Se você usar initialAppDomain, em seguida, você poderá ver alguns dos problemas que são discutidos em BUG: Exceção de AppDomainUnloaded ao usar 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. Usando essa opção permite especificar a estrutura específica para usar durante a compilação.

Comentários

Código gerenciado é o código que pode ser inspecionado e gerenciado pelo CLR. Código gerenciado pode acessar os objetos gerenciados. For more information, see /CLR restrições.

Para obter informações sobre como desenvolver aplicativos que definem e consumam tipos gerenciados, consulte Language Features for Targeting the 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 (adiciona DebuggableAttribute).

Somente os tipos CLR serão instanciados no heap do coletor de lixo. For more information, see Classes and Structs (Managed). Para compilar uma função para código nativo, use o unmanaged pragma. For more information, see managed, unmanaged.

By default, /clr is not in effect. Quando /clr está em vigor, /MD também em efeito. For more information, see /LD /MD, /MT, (biblioteca Run-Time uso). /MDgarante que as versões vinculadas dinamicamente, 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 de CLR (IJW, seguro, ou puro) do arquivo de saída resultante com /CLRIMAGETYPE.

/clrimplica /EHae nenhuma outra /EH opções são suportadas para /clr. For more information, see /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 chamada do vinculador devem ser compilados usando a mesma opção de compilador de biblioteca de tempo de execução (/MD ou /LD).

Use o /ASSEMBLYRESOURCE. a 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 é usado, o _MANAGED símbolo é definido como 1. For more information, see Predefined Macros.

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

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

Imagens de puras e seguras

Uma imagem pura usa uma versão do CLR a biblioteca do C Runtime (CRT). No entanto, a CRT não é verificável, portanto, não é possível usar a CRT quando você compilar usando /clr:safe. For more information, see C Run-Time Libraries.

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

Cada ponto de entrada de uma imagem puro ou segura é gerenciado. Quando você compilar usando /clr, o ponto de entrada é nativo. For more information, see __clrcall.

Quando você compilar usando /clr:safe, por padrão, as variáveis são appdomain e não pode ser por processo. Para /clr:pure, embora 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, 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 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 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 falhará quando ele carrega o aplicativo de 32 bits (BadFormatException). Para garantir que uma imagem de segurança continua sendo executado 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 o 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 exibir nomes de decorada. Para obter mais informações sobre a programação de 64 bits, consulte Programação de 64 bits com o Visual C++.

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

Metadados e Classes sem nome

Classes sem nome aparecerá nos metadados de chamada 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 esta opção de compilador no 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 Property Pages caixa de diálogo.

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

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

    ObservaçãoObservação

    Quando /clr está habilitada na Property Pages 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 está habilitado, /RTC serão desativadas.

    Além disso, quando você depurar um /clr aplicativo, defina a O tipo de depurador propriedade para mista ou gerenciado apenas. For more information, see 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 esta opção de compilador programaticamente

Consulte também

Referência

Opções do compilador

Definindo opções do compilador