/clr (Compilación de Common Language Runtime)

Artículo
10/07/2008

Actualización: noviembre 2007

Permite a las aplicaciones y a los componentes utilizar las características de Common Language Runtime (CLR).

/clr[:options]

Argumentos

options
Uno o más de los siguientes, separados por una coma:
- /clr
  Crea metadatos para su aplicación que se pueden utilizar en otras aplicaciones de CLR, y permite a su aplicación utilizar tipos y datos incluidos en los metadatos de otros componentes de CLR.
  
  Para obtener más información al respecto, vea:
  - Ensamblados mixtos (nativos y administrados)
  - Cómo: Migrar a /clr
- /clr:pure
  Genera un archivo de resultados solo MSIL sin código ejecutable nativo, aunque puede contener tipos nativos compilados a MSIL.
  
  Para obtener más información, consulte Código puro y comprobable.
- /clr:safe
  Genera un archivo de resultados comprobable y solo MSIL (sin código ejecutable nativo). /clr:safe habilita los diagnósticos de comprobación (Herramienta PEVerify (Peverify.exe)).
  
  Para obtener más información, vea Escribir código seguro comprobable.
- /clr:oldSyntax
  Habilita la sintaxis de Extensiones administradas para C++, la sintaxis original de Visual C++ para la programación CLR.
  
  Nota La sintaxis de Extensiones administradas para C++ ha quedado obsoleta en Microsoft Visual C++ 2005. Sólo debe utilizar /clr:oldSyntaxsi conserva alguna aplicación de Visual C++ que utilice Extensiones administradas para C++. Si está desarrollando una nueva aplicación, utilice la sintaxis actualizada; vea Language Features for Targeting the CLR para obtener más información.
  
  Si tiene una aplicación con Extensiones administradas para C++, puede comenzar a trasladar el proyecto para que utilice la nueva sintaxis; vea Trasladar y actualizar programas para obtener más información.
- /clr:noAssembly
  La opción noAssembly especifica que no debe insertarse un manifiesto de ensamblado en el archivo de resultados. La opción noAssembly está desactivada de forma predeterminada.
  
  Nota La opción noAssembly ha quedado obsoleta en Visual C++ 2005. En su lugar, se ha de utilizar /LN (Crear un módulo MSIL). Para obtener más información, consulte Opciones obsoletas del compilador en Visual C++ 2005.
  
  Un programa administrado que no tiene metadatos de ensamblado en el manifiesto se denomina módulo. La opción noAssembly sólo puede utilizarse para generar un módulo. Si compila con /c (Compilar sin vincular) y /clr:noAssembly, especifique la opción /NOASSEMBLY (Crear un módulo MSIL) en la fase del vinculador para crear un módulo.
  
  Antes de Visual C++ 2005, /clr:noAssembly implicaba /clr. Sin embargo, /clr ahora también admite /clr:oldSyntax, por lo que debe especificar un formulario /clr cuando especifique /clr:noAssembly. Por ejemplo, /clr:noAssembly /clr crea un módulo mediante la nueva sintaxis de CLR de Visual C++ y /clr:noAssembly,oldSyntax crea un módulo mediante Extensiones administradas para C++.
  
  Antes de Visual C++ 2005, /clr:noAssembly requería /LD. /LD ahora se implica cuando se especifica /clr:noAssembly.
- /clr:initialAppDomain
  Permite a una aplicación de Visual C++ ejecutarse en la versión 1 de Common Language Runtime. Si utiliza initialAppDomain, puede ver algunos de los problemas tratados en el artículo Q309694 de Knowledge Base. Encontrará artículos de Knowledge Base en la versión multimedia de MSDN Library o en la dirección https://support.microsoft.com/support.
  
  Las aplicaciones compiladas con initialAppDomain no deberían nunca utilizarse con una aplicación que usara ASP.NET. Actualícese a un programa en tiempo de ejecución más reciente para realizar el trabajo de ASP.NET con C++.

Comentarios

El código administrado es código que puede inspeccionarse y administrarse con Common Language Runtime. El código administrado tiene acceso a los objetos administrados.

Vea también Restricciones de /clr.

Vea Language Features for Targeting the CLR para obtener información sobre cómo desarrollar aplicaciones que definan y utilicen tipos administrados.

Una aplicación compilada con /clr puede o no puede contener datos administrados.

Para permitir la depuración en una aplicación administrada, vea /ASSEMBLYDEBUG (Agregar DebuggableAttribute).

En la pila de recolección de elementos no utilizados, sólo se crearán instancias de tipos de CLR. Para obtener más información, vea Classes and Structs (Managed). Para compilar una función a código nativo, utilice el pragma unmanaged. Para obtener más información, consulte managed, unmanaged.

De forma predeterminada, /clr se encuentra desactivado. Cuando /clr está en vigor, /MD también lo está (para obtener más información, consulte /MD). /MD garantiza que, en los archivos de encabezado estándar (.h), se seleccionen las versiones multiproceso con vínculos dinámicos de las rutinas en tiempo de ejecución. El subprocesamiento múltiple es en parte necesario para programación administrada porque el recolector de elementos no utilizados de CLR ejecuta los finalizadores en un subproceso auxiliar.

Si compila con /c, puede especificar con /CLRIMAGETYPE (Especificar tipo de imagen CLR) el tipo de CLR (IJW, seguro o puro) del archivo de resultados que se obtiene.

/clr implica /EHa y no se permite ninguna otra opción /EH con /clr. Consulte /EH (Modelo de control de excepciones) para obtener más información.

Para obtener información sobre cómo determinar el tipo de imagen de CLR de un archivo, vea /CLRHEADER.

Todos los módulos pasados a una invocación determinada del vinculador se deben de haber compilado con la misma opción del compilador de la biblioteca en tiempo de ejecución (/MD o /LD).

La opción /ASSEMBLYRESOURCE (Incrustar un recurso administrado) del vinculador se utiliza para incrustar un recurso en un ensamblado. Las opciones del vinculador /DELAYSIGN (Firmar parcialmente un ensamblado), /KEYCONTAINER (Especificar un contenedor de claves para firmar un ensamblado) y /KEYFILE (Especificar una clave o par de claves para firmar un ensamblado) también permiten personalizar la forma de crear un ensamblado.

Cuando se utiliza /clr, el símbolo _MANAGED se define para que sea 1. Para obtener más información, vea Predefined Macros.

Las variables globales de un archivo objeto nativo se inicializarán primero (durante DllMain si el ejecutable es un archivo DLL) y luego las variables globales de la sección administrada (antes de que se ejecute el código administrado). #pragmainit_seg sólo afecta al orden de inicialización dentro de las categorías administradas y no administradas.

La compilación con /clr:safe es equivalente a la compilación con /platform:anycpu en lenguajes como C#.

Imágenes seguras y puras

Una imagen pura utilizará una versión de CLR de la biblioteca en tiempo de ejecución de C. Sin embargo, CRT no es comprobable, por lo que no se puede utilizar CRT al compilar con /clr:safe. Para obtener más información, vea C Run-Time Libraries.

Algunos ejemplos de código nativo que no pueden aparecer en una imagen pura son ensamblado en línea, setjmp o longjmp.

Se administra cada punto de entrada de una imagen pura o segura. Cuando se compila con /clr, el punto de entrada es nativo. Para obtener más información, vea __clrcall.

Cuando se compila con /clr:safe, las variables son, de manera predeterminada, appdomain y no pueden depender del proceso. Con /clr:pure, appdomain es la opción predeterminada, pero puede utilizar variables process.

Cuando se ejecuta un archivo .exe de 32 bits que se ha compilado con /clr o /clr:pure en un sistema operativo de 64 bits, la aplicación se ejecuta bajo WOW64, que permite a CLR de 32 bits la ejecución de una aplicación de 32 bits en un sistema operativo de 64 bits. De forma predeterminada, un archivo .exe compilado con /clr:safe se ejecutará en CLR de 64 bits en un equipo con un sistema operativo de 64 bits (en un sistema operativo de 32 bits, el mismo archivo .exe se ejecutaría en CLR de 32 bits). Sin embargo, es posible que la aplicación segura cargue un componente de 32 bits. En ese caso, una imagen segura que se ejecute bajo la compatibilidad de 64 bits del sistema operativo no podrá cargar la aplicación de 32 bits y se producirá un error (BadFormatException). Para garantizar que una imagen segura se sigue ejecutando cuando carga una imagen de 32 bits en un sistema operativo de 64 bits, debe utilizar /CLRIMAGETYPE (Especificar tipo de imagen CLR) para cambiar los metadatos (.corflags), marcándola para que se ejecute bajo WOW64. A continuación, se muestra un ejemplo de línea de comandos (sustituya su propio símbolo de entrada):

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

Para obtener información sobre cómo recibir un nombre representativo, vea Utilizar una lista para ver nombres representativos. Para obtener más información sobre la programación de 64 bits, vea Programación de 64 bits (Cómo se hace en Visual C++).

Para obtener ejemplos, tutoriales y más información, vea:

Metadatos y clases sin nombre

Las clases sin nombre aparecerán en los metadatos con los nombres siguientes: $UnnamedClass$crc-del-nombre-de-archivo-actual$índice$, donde índice es un recuento secuencial de las clases sin nombre de la compilación. Por ejemplo, el siguiente código genera una clase sin nombre en los metadatos:

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

Use ildasm.exe para ver los metadatos.

Para establecer esta opción del compilador en el entorno de desarrollo de Visual Studio

Abra el cuadro de diálogo Páginas de propiedades del proyecto. Para obtener información detallada, vea Cómo: Abrir páginas de propiedades del proyecto.
Haga clic en la carpeta Propiedades de configuración.
Haga clic en la página de propiedades General.

Modifique la propiedad Compatibilidad con Common Language Runtime.

Vea /NOASSEMBLY (Crear un módulo MSIL) para obtener información sobre cómo crear un módulo.

Nota:
Cuando la opción /clr está habilitada en el cuadro de diálogo Páginas de propiedades de un proyecto, las propiedades de opciones del compilador que no sean compatibles con /clr también se ajustarán según sea necesario. Por ejemplo, si se establece /RTC y, a continuación, se habilita /clr, /RTC se desactivará.

Asimismo, al depurar una aplicación /clr, la propiedad Tipo de depurador debería establecerse en Mixto o en Sólo administrado. Para obtener más información, consulte Configuración del proyecto para una configuración de depuración de C++.