CLI/C++ DLL wraps unmanaged DLL, crashed at run time in .NET (ieshims.dll and gpsvc.dll missing)

I have inherited an unamanged DLL (originally built from C code) and want to use it in a .NET project. I have header files which wrap the DLL's functionality in a C++ type object, it is this object-oriented functionality I want to expose. Everything works fine when I #include these header files it in a standard C++ (Win32) project and in a C++/CLI project, referencing the original DLL.

Using Visual C++ Express 2010, I have tried to build a managed DLL for .NET. This DLL then crashed at runtime because of dependency issues. Dependency walker says:

Warning: At least one delay-load dependency module was not found.

Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.

and complains that it can't find gpsvc.dll or ieshims.dll. I know this has something to do with x86 vs x64 (I am running Win7 on x64) but, since I can use the DLL on my system in a C++ project, I suspect it must be possible to wrap this in a managed DLL for use in .NET on the same system.

Thanks very much in advance to anyone who can offer any insight!

(by the way, my goal is to develop a .NET assembly instead of using p/invoke directly on the original DLL, since it will be used by a lot of C#/VB programmers w开发者_运维知识库ith limited interop experience after me)

Solution: the x86/x64 issue is a red herring. I had a three-dll long chain of dependencies. Visual Studio's 'copy local' property for all references was set to true, so the managed dll I was referencing was copied local, away from its dependencies.

For some reason I can't figure out, setting the copy local property of the reference to false and deleting the local copy it made does not solve the problem. I had to copy over the dependencies to the C# project's local bin.

A potential takeaway is that paying too much attention to absent call-time dependencies in dependency walker may lead you in the wrong direction..

As you, Rory, mentioned in your answer, the solution seems to be that you need to include ALL dependent DLLs in the References section of your C# application/manually include all DLLs in the C# bin or the same folder that the .exe is running from.

I just ran into this issue with a similar setup to yours. I have the following dependencies:

C# application -> (1) CLI Wrapper DLL -> (2) C++ Wrapper DLL -> (3) 3rd Party DLL

In the References section, I included the (1) CLI DLL. I did not include the (2) C++ DLL because it throws the error ERROR ...could not be added. Please make sure that the file is accessible, and that it is a valid assembly or COM component (interpretation : C++ DLL is not .NET/CLR compliant).

I then simply assumed that because the (1) CLI DLL correctly and successfully linked to the (2) C++ DLL (I tested this with a C++/CLI Console Application), the C# application would be able to access the (2) C++ dependency through the referenced (1) CLI dependency. This was incorrect.

I don't know the reason why, but the C# application cannot access the CLI's dependencies.

My solution was manually include the (2) C++ DLL in the .exe's directory. Remember that the (1) CLI DLL is automatically copied over if Local Copy is set to true in the C# application. I did not seem to run into any issues with the (2) C++ DLL referencing the (3) 3rd Party DLL (i.e. (3) 3rd Party DLL could reside in its specified path/did not need to be locally copied).