DllNotFoundException in unity3d plugin for c++ dll - unity3d

Question

I am working on the Unity Plugin project and try to import the c++ native dll from c# file.
But I keep getting dllnotfoundexception.
c++ dll code:
extern "C" {
extern __declspec( dllexport ) bool IGP_IsActivated();
}
c# code:
[DllImport("mydll")]
private static extern bool IGP_IsActivated();
Dll is in place and FIle.Exists work properly. All dependent dlls are present at same hierarchy, but I still end up in dllnotfound exception.
Any help, much appreciated!!

Answer 1

Thanks to this Unity forum post I came up with a nice solution which modifies the PATH-environment variable at runtime:
Put all DLLs (both the DLLs which Unity interfaces with and their dependent DLLs) in Project\Assets\Wherever\Works\Best\Plugins.
Put the following static constructor into a class which uses the plugin:
static MyClassWhichUsesPlugin() // static Constructor
{
var currentPath = Environment.GetEnvironmentVariable("PATH",
EnvironmentVariableTarget.Process);
#if UNITY_EDITOR_32
var dllPath = Application.dataPath
+ Path.DirectorySeparatorChar + "SomePath"
+ Path.DirectorySeparatorChar + "Plugins"
+ Path.DirectorySeparatorChar + "x86";
#elif UNITY_EDITOR_64
var dllPath = Application.dataPath
+ Path.DirectorySeparatorChar + "SomePath"
+ Path.DirectorySeparatorChar + "Plugins"
+ Path.DirectorySeparatorChar + "x86_64";
#else // Player
var dllPath = Application.dataPath
+ Path.DirectorySeparatorChar + "Plugins";
#endif
if (currentPath != null && currentPath.Contains(dllPath) == false)
Environment.SetEnvironmentVariable("PATH", currentPath + Path.PathSeparator
+ dllPath, EnvironmentVariableTarget.Process);
}
Add [InitializeOnLoad] to the class to make sure that the constructor is run at editor launch:
[InitializeOnLoad]
public class MyClassWhichUsesPlugin
{
...
static MyClassWhichUsesPlugin() // static Constructor
{
...
}
}
With this script there is no need to copy around DLLs. The Unity editor finds them in the Assets/.../Plugins/...-folder and the executable finds them in ..._Data/Plugins-directory (where they get automatically copied when building).

Answer 2

Well I got it working.
For others who may face this problem, if you have more than one dll, you need to put the secondary dlls at root level of the Unity editor (e.g. C:\Program Files\Unity\Editor) and the actual referenced dll from script into plugins folder.
This worked for me.

Answer 3

Put the DLL(s) Unity interfaces with in Project\Assets\Wherever\Works\Best\Plugins.
Place any dependency DLLs that are not directly accessed by your scripts in Project. This will allow your program to run in the editor.
When you build, again copy the dependency DLL files, this time to the root of the build directory (right next to the generated executable). This should allow your application to load them at runtime.
(Tip: you can use Dependency Walker look at you DLLs and see what they depends on.)

Answer 4

I spent one day with this error. My issue was that Android doesn't get the library and always get and DDLNotFound error. My solution was:
1.- Be sure that you have the libraries for the proper architecture in the Plugins folder.
Plugins/Android/x86 and Plugins/Android/armeabi-v7a if your build settings is FAT(x86&arm)
2.- Check that Unity recognizes them as libraries. If you select them in the Project tab you should see them as a library and the platform and architecture related.
3.- After the build (don't close Unity Editor!), you can check in the Temp/StagingArea/libs if your libraries are there. If there are there for sure the libraries are going to be in the APK. As a double check, you can open your APK (change to zip extension) and see the libraries in the lib folder.
4.- In C# you should remove any lib prefix in your library name, for example:
If your library name is "libdosomething.so" you should call it as
[DllImport ("dosomething")]
I hope this work for you :)
Cheers.

Answer 5

Make sure the following chacklist is satisfied:
Plugins should all stay in a folder called Plugins.
The architecture your dll is built for (x86 or x86_64) must correspond to the architecture version of Unity Editor. Unity Editor 32-bit will not load 64 bit plugins and viceversa.
If you are targeting both 32 and 64 bit architectures you should put your dlls in special named folders inside the Plugins folder. The names are Plugins/x86 for 32 bit dlls and Plugins/x86_64 (x64 also works) for 64 bit dlls.
Visual C++ Redistributables must be installed. I have all from 2008.
When you build all your dlls should be copied into the root where your executable is (and again built for the correct x86/x64 architecture)
If you keep getting a namespace error it means the dll you are importing has unmanaged code and it must be wrapped into another managed dll Pugin in order to work.
These threads are a bit outdated but still relevant
DLLNotFoundException - Unity3D Plugin
Unity internal compiler error with custom dll

Answer 6

In my case, I have DllNotFoundException: ovrplatiformloader
Unity : DllNotFoundException: ovrplatformloader
Unity : at (wrapper managed-to-native) Oculus.Platform.CAPI.ovr_UnityInitWrapperAsynchronous(string)
Unity : at Oculus.Platform.AndroidPlatform.AsyncInitialize (System.String appId) [0x00013] in <29065e843b82403894fca6c6f2974090>:0
Unity : at Oculus.Platform.Core.AsyncInitialize (System.String appId) [0x0004f] in <29065e843b82403894fca6c6f2974090>:0
Unity : at DBHelper.Start () [0x00019] in <29065e843b82403894fca6c6f2974090>:0
My solution is:
Re-import files that doesn't work (libovrplatformloader.so)
Reconstruct the Platform/Plugins architecture. Old: Platform/Plugins/Android32/libovrplatformloader.so. New: Platform/Plugins/Android/x86/libovrplatformloader.so and Platform/Plugins/Android/armeabi-v7a/libovrplatformloader.so
Modify the import setting of libovrplatformloader.so. Change any platform to only Android platform and enable 'load on startup' selection. Choose ARMv7 CPU in armeabit-v7a while choose x86 CPU in x86 folder.

Answer 7

just put the dlls under Plugins folder and that works for me

Answer 8

I was having the same issue, and the solutions described here didn't work.
I think my case was a little different.
I think that the .dll I was importing depended on other .dll files. So I imported the other files related to that .dll (which I thought were unnecessary since I am not calling them directly on c# code) and that solved the issue.