C# app can't find DLL in the same directory?

Question

_{Tuesday, July 31, 2007 5:33 PM}

I have a C# application that is using an unmanaged C++ .DLL.  When I run it locally, it works fine (the development machine).  I can debug it and all that stuff.  When I copy the application up onto a server where it will reside, I put everything in the correct directories and whatnot.  When I go to execute this particular function in this .DLL the application errors out and says it can't find the particular DLL that is labelled in the DllImport statement. 

I have double-checked this and the .dll file is definitely in the same application directory as the C# application.  What's going on here?

Thanks,

D

All replies (3)

_{Tuesday, July 31, 2007 5:37 PM}

What IS that DLLImport statement then? 

You could always try referring to Application.startuppath...

_{Wednesday, August 1, 2007 1:34 AM}

What is the error message?

What are you using for DllImport?

Is there some permissions problem?

Is the calling dll also running from the same location as the c++ dll?  If it is being loaded from the same location, but the app is somehow running from a different location, that might also be the cause, although from what you've said, it seems unlikely.

If you could give a little more information, I will have a try at answering your question.

Martin.

_{Monday, September 10, 2007 7:57 AM}

I have also been having this problem.  When I run my application on any machine with VS2005 installed, I can have my unmanged DLL either in the app startup path, or in the system32 folder.  However, when I move to a computer that does not have VS2005 installed, it can't find the DLL no matter where I put it.

It is possible though that my directory has changed (Directory.GetCurrentDirectory) before I try to load the DLL.  I'm not sure if this would cause a problem.

Here is an example of how I'm loading in the unmanaged DLL:

Code Snippet

[DllImport("THEDLL32.dll", CallingConvention = CallingConvention.Cdecl)]

private static extern int LoadData([MarshalAs(UnmanagedType.LPStr)] String fileName);

Update: I used Dependency Walker to take a look at any dependant DLL's used.  I found out that the DLL I was using was compiled in debug mode and had a dependancy for Visual Studio's MSVCR80D.DLL .. Doh!