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).