I made a DLL in C++, compiled it just fine, imported the DLL and LIB files into a C# project in VS2012, used the System.Runtime.InteropServices, and attached a [DllImport("DllName.dll")] attribute to the function I wanted to test, making sure the function name and data types match correctly and that it is a static extern function, then tried to call the function.

Everything compiled fine without any errors, but then when I run it, as soon as it gets to the line that calls the function, it crashes with a DllNotFoundException. I'm assuming that it's trying to load in the DLL automatically just before it needs to use it, right? That's fine, but for some reason it can't find it, even though I placed it in the project and it appears inside VS2012, along with the LIB file. I also tried changing the extension in the DllImport string to be .lib instead of .dll, and I still get the same error.

So does anyone know what I did wrong?

Have you tried putting the dll in the same directory as the exe file that's using it?

Do you mean inside the debug folder? Or do you mean somewhere else? This is a .NET project remember (I guess there's an exe, but it's not machine language, just byte code), but with a DLL that was made in C++.

I think I only tried putting it in the main project folder, and also the sub-folder inside of it that has the same name (it nests an extra project folder, like there's one for the solution and one for the project).

Anyway, it's imported into the project so it should be able to find it, I would think. Also, is it supposed to say "DllName.dll" in the DllImport attribute, or should it be a .lib instead?

Are there any other files I need to put into the project besides the .dll and .lib?

The .dll should be the correct one. .lib files are not used like that (On Linux you would use .so rather than .lib too).

However in Unity C# you do not seem to need to pass in the .dll suffix (may be optional). Perhaps try:

[DllImport("DllName")]

Have a look here: http://docs.unity3d.com/Manual/Plugins.html

Btw, this is a Unity Pro only feature so that could be your issue.

Perhaps also make sure you are not trying to compile for the Web Player. That has extra restrictions preventing native code for security sandboxing reasons.

Can you make sure your .dll does not require any other dlls? Usually if they require more .dlls then it could fail to load. There are tools on Windows that should help you find out (perhaps try depends (http://www.dependencywalker.com)).

Perhaps also make sure that you have built a native .dll. It is quite likely that you already know this but if you generated a .NET dll using Microsoft C++/clr:safe or pure, it will not work when loaded in like this.

Finally, I once noticed that when I made a Unity plugin with wxWidgets, it actually had to have the wxWidgets dll in the same directory as Unity.exe. Perhaps try this if none of the other suggestions work.

Do you mean inside the debug folder? Or do you mean somewhere else? This is a .NET project remember (I guess there's an exe, but it's not machine language, just byte code), but with a DLL that was made in C++.

I think I only tried putting it in the main project folder, and also the sub-folder inside of it that has the same name (it nests an extra project folder, like there's one for the solution and one for the project).

Try to find the exe and put the dll in the same folder.

You can also try putting it in the Windows folder, but I'm not sure about that at the moment. It could be syswow64 inside the Windows folder as well (for a 32bit program on 64bit Windows). This is just for testing though, you shouldn't put dlls there for a release version.

First of all, who ever said anything about Unity? I never once mentioned it. I'm using Visual Studio 2012 C#, that's it, no Unity. I'm not using any wxWidgets, and I don't even know what the "Web Player" is.

I made the DLL in C++.NET so I guess it's possible that it is a .NET DLL. I guess I assumed it was a regular one.

- How could I be sure?

- And if it's not, how can I recompile it into a regular one?

- But if it's a .NET one, might that still work anyway, even if I have to import it differently?

- And for that matter, would it still even have a .LIB file with it, or does that prove that it's a regular DLL?

Now that you mention it though, it does require another DLL. I don't remember whether I included that into the project as well. Should I just include both of them and put both of them into the debug folder where the EXE is?

First of all, who ever said anything about Unity? I never once mentioned it.

Heh, yeah, my bad. I kinda made the assumption that guys here using C# are probably using Unity. Much of my suggestions are C# issues in general than Unity so at least that cuts out licensing restrictions.

Now that you mention it though, it does require another DLL. I don't remember whether I included that into the project as well. Should I just include both of them and put both of them into the debug folder where the EXE is?

Normally just include them in the same folder as the .NET executable. However try compiling them in release mode. I think debug versions of the binaries could potentially cause issues.

If your .dll does come with a .lib file, then yeah it is likely to be a traditional native dll. So no problems here.

OK so just to be clear, I should compile the DLLs made in C++ in release mode instead of debug mode (good idea btw), but then I can still run my .NET application in debug mode while using the release mode DLL, right? And in that case, to put them in the same folder as the .NET EXE would probably still be the debug folder though, right?

(Also, thanks for all your help).

If it's a true .NET DLL, then you shouldn't need to do any DllImport at all. Just add a reference to the DLL (right-click References in Solution explorer and click Add Reference...). When the project builds, it will automatically copy the DLL to the correct output directory.

If it's not a true .NET DLL, then you will need the DllImport and you need to manually place the DLL in the same directory as your app's .exe directory. That directory will be under either the Debug or Release directory under your project, depending on whether you're doing a Debug or Release build.

If the DLL depends on other DLLs that aren't in your environment path, then you'll need to either add references to them (for .NET DLLs) or copy them to your .exe directory as well.

Well thanks. I'll try all this out when I get some free time (this weekend), and I'll tell you if I still have any problems. But if anyone has any more suggestions, feel free to post them, 'cause you never know if I might need them :-/