Question

I am trying to create a pure MSIL assembly from a C++/CLI project using /clr:pure and /clrimagetype:pure flags, however, the output assembly specifically targets x86.

Am I missing anything that might be preventing my project to be compiled as MSIL only?

Answer 1

You can create an AnyCPU dll with C++/CLI, but in the simplest case, you will not be able to use MFC, ATL or the CRT. However, if you just want to write pure managed .NET code in C++/CLI, including managed pointers (which /clr:safe does not allow), and get the more elaborate code optimization of the C++/CLI compiler, read on:

1. For best results, start with a fresh project from the managed class library project template. Set the C++/CLI project properties for the DLL class library to /clr:pure. This is on the Configuration Properties page in Visual Studio 2010.
2. On the C/C++ panel, set Omit Default Library Name to Yes /Zl
3. For the linker, disable Incremental Linking and Link Library Dependencies
4. On the linker’s “Advanced” page, I set the Target Machine to Not Set and the CLR Image Type to Force Pure IL Image /CLRIMAGETYPE:PURE, but some of these aparently settings aren’t honored, since the 32BIT+ flag is still set by the linker in the PE32 header.
5. Therefore, add a corflags step to your build. The best way to do this is to exit Visual Studio and edit your vcxproj file with a text editor. At the bottom of the file, add:

       <!-- at the bottom of the file... -->
       <Target Name="AfterBuild">
           <Exec Command="corflags $(TargetPath) /32BIT-" />
       </Target>
   </Project>

   This runs the corflags tool to turn off the 32BIT flag in your DLL. Make sure that the corflags.exe tool is available in your path.

6. Finally, add a stub entry to your C++/CLI source file. This is the module static constructor. What worked for me is to place the following outside of any namespace:

   #pragma warning(disable:4483)
   void __clrcall __identifier(".cctor")() { }

That’s it, you can now build the AnyCPU dll; it is pure MSIL by virtue of the ‘pure’ settings, and it will load either as x64 or x86 thanks to the corflags adjustment. It is up to you to avoid using any incompatible features, such as Interop, at runtime. However–and this is the difference versus just trivially using /clr:safe mode (which also produces an AnyCPU library)–you can use unsafe managed pointers to access managed value types.

---

[edit:] To elaborate on Ben Voight’s comment, one thing that won’t work in this type of C++/CLI AnyCPU dll is the use of C/C++ initialization syntax to initialize unmanaged (i.e. native), static primitives, structs, (or arrays):

static int my_arr[] = { 1, 2, 3 };

The linker issues a warning to this effect, warning LNK4210: .CRTMA section exists; there may be unhandled static initializers or terminators. You can, however, declare them, initialize them yourself, and use them–that is, take their addresses–and read/write them from managed code (if you want to declare such an array as const, then you’ll have to provide empty braces { } for an initializer and cast a pointer to volatile to initialize it.):

static int my_arr[3];

Ironically, one way to initialize these native static resources or tables is to copy them, during the module constructor or class static constructor, from a managed variable or resource.

Why bother with native statics, you ask? Because they can be quickly accessed without pinning. One nice thing C++/CLI still does for you here is to silently create a managed value-type (struct) to overlay each of your native statics, so that the IL code can get at them directly with IL pointers, thus keeping the assembly /pure.

[edit: corrected mis-statement regarding “native” pointers in an AnyCPU assembly]
[edit: clarify: ‘unsafe’ C# code in pure assembly uses managed pointers via IL instructions such as ldloca, etc.]