/CLR effect on the way DLLs are loaded

  • Article

Yesterday evening, I had an issue that manifested itself (no pun intended) at runtime only when compiling with /CLR:pure. /CLR and /CLR:safe did not exhibit it.

The exception was:
The type initializer for '<Module>' threw an exception.
Unable to load DLL 'msvcm80d.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)"}

Arjun Bijanki from the Visual C++ team gave me a hand. Here’s the part of his e-mail I wanted to share with you:
Make sure that your C++ class library has an embedded manifest that refers to msvcm80d.dll.
…
As for why the behavior can differ for the different /clr switches:
/clr:safe binaries have no dependency on msvcm80.
/clr binaries have a native dependency. The Windows loader directly loads msvcm80 via a static load.
/clr:pure binaries have a PInvoke dependency. The managed loader is responsible for deciding when to load msvcm80 via a dynamic load.

More information:
- Pure and Verifiable Code
- Visual C++ Libraries Changes to Support Manifest-Based Assembly Generation
- Manifests (from Isolated Applications and Side-by-side Assemblies)