views:

1538

answers:

2

Hi, I'm trying to get a simple mixture between Managed C++ and plain C++ working. I'm using Visual Studio 2005 but keep hitting a problem. Here's my setup.

First, I have a simple DLL built from the code

#using "mscorlib.dll"

#include "windows.h"

__declspec(dllexport)
void sayHello()
{
    OutputDebugStringA( "Hello from managed code!" );
}

I compile this on the commandline to a DLL using

cl /CLR /LD dllcode.cpp

Next, I have a simple program consisting of nothing more than

#include <windows.h>
int main()
{
    HINSTANCE lib = LoadLibrary( "dllcode.dll" );
    if ( !lib ) {
        return 1;
    }
    return 0;
}

I build an application out of this using

cl loader.cpp

So I end up with dllcode.dll and loader.exe in the same directory. When trying to run loader.exe, I always get return code '1'. Looking up the error code yielded by GetLastError() shows that loading dllcode.dll failed due to The specified module could not be found.

Does anybody know why this could be? Does it have something to do with manifests which need to be embedded into dllcode.dll or so? I ran the depends program on dllcode.dll but it didn't yield any problems as far as I could tell.

A: 

You might try using filemon to see what LoadLibrary is trying to load.

jdigital
Good idea; it seems that filemon was superseded by procmon. Using the latter, running the demo program yielded 1076 events. Unfortunately I couldn't see any errors in there - all the LoadImage calls succeeded, at least. Do you maybe have a suggestion what to look out for?
Frerich Raabe
That's why I still use FileMon even though it has been superseded; procmon takes more work to set up and it's easier to make mistakes when configuring the filters.
jdigital
+2  A: 

I just found out why loading the Managed C++ DLL from my vanilla C++ program didn't work. Thanks once again to jdigital for pointing me to a useful tool:

The source of the error was that the MSVC8 runtime library was not found. I thought that the manifest which is generated when building via

cl /CLR /LD dllcode.cpp

is already embedded into the DLL. Apparently, it's not - so the loader failed to locate the appropriate MSVCR80.dll copy.

I fixed this problem by adding a second step to the DLL building routine:

cl /CLR /LD dllcode.cpp
mt -manifest dllcode.dll.manifest -outputresource:dllcode.dll;2

Hope this helps. Quite a beginner problem, I suspect...

Frerich Raabe