/CLR effect on the way DLLs are loaded

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)


Comments (0)

Skip to main content