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:
- 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.
- On the C/C++ panel, set
Omit Default Library Name
to Yes /Zl
- For the linker, disable
Incremental Linking
and Link Library Dependencies
- 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.
- 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.
- 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.
won'tC++/CLI AnyCPUunmanagedstatic 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.]