Duration (Pacific Standard Time):
To (Pacific Standard Time):
  • None
User Action:
  • None
Visual C++ Compiler Options

/clr (Common Language Runtime Compilation)


where options is zero or more of the following,

Specifies that an assembly manifest should not be inserted into the output file. By default, :noAssembly is not in effect (an assembly manifest is inserted into the output file).

A managed program that does not have an assembly metadata in the manifest is called a module.:noAssembly can only be used when a DLL is the output file of the compilation. If you compile with /c and /clr:noAssembly, specify the /NOASSEMBLY option in the linker phase to create a module.

Allows a Visual C++ application build with Visual Studio .NET 2003 to run on version 1 of the common language runtime. If you use initialAppDomain, you might see some of the problems discussed in http://support.microsoft.com/default.aspx?scid=kb;en-us;Q309694. An application compiled with initialAppDomain should never be used by an application using ASP.NET; upgrade to a newer runtime to do ASP.NET work with C++.

When both options are passed to /clr, separate them with a comma.


The /clr compiler option enables the use of Managed Extensions for C++ and creates an output file that will require the .NET Framework common language runtime at run time. There may or may not be managed data in the application.

To allow debugging on a managed application file, see /ASSEMBLYDEBUG.

The /clr option does not imply that classes, interfaces, or structs are managed; use __gc to explicitly specify when you want a construct to be managed.

The /clr option does imply that all functions will be managed. To make specified functions unmanaged, use the unmanaged pragma.

Code compiled with /clr must also use the #using <mscorlib.dll> statement when managed objects are used in your code.

Managed code is code that can be inspected and managed by the common language runtime. Managed code can access managed objects.

By default, the /clr compiler option is not in effect. When /clr is in effect, the /MT compiler option is also in effect.

See the /ASSEMBLYRESOURCE linker option for information about how you can create a .NET Framework assembly when you compile and link your Managed Extensions for C++ program. /DELAYSIGN, /KEYCONTAINER, and /KEYFILE linker options also let you customize how an assembly is created.

The /CLRHEADER DUMPBIN option displays .NET Framework header information for an image that was built with /clr.

Metadata and Unnamed Classes

Unnamed classes will appear in metadata named as follows: $UnnamedClass$crc-of-current-file-name$index$, where index is a sequential count of the unnamed classes in the compilation. For example, the following code sample will generate an unnamed class in metadata:

#using <mscorlib.dll>
} x;

int main()

Use ildasm.exe to view metadata.

CLS Compliance

If you create an assembly, you can indicate that all or part of your code is compliant with the Common Language Specification (CLS) with the CLSCompliant attribute.

// clr_clscompliant.cpp

// compile with: /clr

#using <mscorlib.dll>

[assembly:System::CLSCompliant(true)];   // specify assembly compliance

[System::CLSCompliant(false)]   // specify compliance for an element

public __gc class TestClass



   int i;


int main()


   TestClass *x = new TestClass();


/clr Restrictions

Note the following restrictions on the use of /clr:

  • The use of Run-time Error Checks is not valid with /clr.
  • When /clr is used to compile a program that does not use Managed Extensions for C++, the following guidelines apply to the use of inline assembly:
    • Inline assembly code that assumes knowledge of the native stack layout, calling conventions outside of the current function, or other low-level information about the computer may fail if that knowledge is applied to the stack frame for a managed function. Functions containing inline assembly code are generated as unmanaged functions, as if they were placed in a separate module that was compiled without /clr.
    • Inline assembly code in functions that pass copy-constructed function parameters is not supported.
  • The vprintf Functions cannot be called from a program compiled with /clr.
  • The naked __declspec modifier is ignored under /clr.
  • The use of dllexport or dllimport on classes is not permitted under /clr.
  • The translator function set by _set_se_translator will affect only catches in unmanaged code. See Handling Exceptions Using Managed Extensions for C++ for more information.
  • The comparison of function pointers is not permitted under /clr.
  • The use of functions that are not fully prototyped is not permitted under /clr.
  • The following compiler options are not supported with /clr: /GL, /Zd, /ZI or /Z7, /ML and /MLd, /Gm, /YX, and /RTC.
  • When using /Zi with /clr, there are performance implications; see /Zi for more information.
  • Passing a wide character to a .NET Framework output routine without also specifying /Zc:wchar_t or without casting the character to __wchar_t will cause the output to appear as an unsigned short int. For example:
    Console::WriteLine(L' ')              // will output 32
    Console::WriteLine((__wchar_t)L' ')   // will output a space
  • /GS is ignored when compiling with /clr, unless a function is under #pragma unmanaged or if the function must be compiled to native, in which case the compiler will generate warning C4793, which is off by default.
  • See /ENTRY for function signature requirements of a managed application.
  • Functions that take a variable number of arguments (varargs) will be generated as native functions. Any managed data types in the variable argument position will be marshaled to native types. Note that System::String* types are actually wide-character strings, but they are marshaled to single-byte character strings. So if a printf specifier is %S (wchar_t*), it will marshal to a %s string instead.

For more information, see 24.1 Effects of the /clr Switch.

To set this compiler option in the Visual Studio development environment

  1. Open the project's Property Pages dialog box. For details, see Setting Visual C++ Project Properties.
  2. Click the Configuration Properties folder.
  3. Click the General property page.
  4. Modify the Use Managed Extensions property.

    See /NOASSEMBLY for information about how to specify that you want to create a module.

When /clr is enabled in a project's Property Pages dialog box, the compiler option properties that are not compatible with /clr (see above) will also be adjusted, as necessary. For example, if /RTC is set and then /clr is enabled, /RTC will be turned off.

Also, be aware that, when you debug a application with Managed Extensions for C++, the Debugger Type property should be set to Mixed or Managed only. See Project Settings for a C or C++ Debug Configuration for more information.

To set this compiler option programmatically

See CompileAsManaged Property.

See Also

Compiler Options | Setting Compiler Options