Esta documentación está archivada y no tiene mantenimiento.

/clr (Compilación de Common Language Runtime)

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


/clr[:options]

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:

/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, vea 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 con seguridad de tipos comprobable.

/clr:oldSyntax

Habilita la sintaxis de Extensiones administradas para C++, la sintaxis original de Visual C++ para la programación CLR.

La sintaxis de Extensiones administradas para C++ se ha dejado de utilizar en Microsoft Visual C++ 2005. Debería utilizar únicamente /clr:oldSyntax si está manteniendo una aplicación Visual C++ que utiliza Extensiones administradas para C++. Si está desarrollando una nueva aplicación, utilice la sintaxis actualizada; vea New C++ Language Features 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

Especifica que no se debe insertar un manifiesto de ensamblado en el archivo de resultados. De forma predeterminada, noAssembly está desactivado y se inserta un manifiesto de ensamblado en el archivo de resultados.

Un programa administrado que no tiene metadatos de ensamblado en el manifiesto se denomina módulo. Vea en /LN (Crear un módulo MSIL) las razones para generar un módulo.

noAssembly sólo se puede utilizar cuando un archivo DLL es el archivo de resultados de la compilación. 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.

noAssembly se deja de utilizar en Visual C++ 2005. En su lugar, se ha de utilizar /LN (Crear un módulo MSIL). Para obtener más información, vea Opciones obsoletas del compilador.

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 http://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++.

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 New C++ Language Features 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, vea managed, unmanaged.

De forma predeterminada, /clr se encuentra desactivado. Cuando /clr está en vigor, /MD también lo está (vea /MD, /MT, /LD (Utilizar la biblioteca en tiempo de ejecución) para obtener más información). /MD garantiza que, en los archivos de encabezado estándar (.h), se seleccionan 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 admite ninguna otra opción /EH con /clr. Vea /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). #pragma init_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

  1. 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.

  2. Haga clic en la carpeta Propiedades de configuración.

  3. Haga clic en la página de propiedades General.

  4. 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.

    NoteNota

    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, vea Configuración del proyecto para una configuración de depuración de C++.

Para establecer esta opción del compilador mediante programación

Mostrar: