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



Re: Visual C# General C# app can't find DLL in the same directory?


What IS that DLLImport statement then

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

Re: Visual C# General C# app can't find DLL in the same directory?

Martin Platt

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.


Re: Visual C# General C# app can't find DLL in the same directory?


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!