Related
I have a dll library with unmanaged C++ API code I need to use in my .NET 4.0 application. But every method I try to load my dll I get an error:
Unable to load DLL 'MyOwn.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
I have read and tried several solutions I have found on the internet. Nothing works..
I have tried using following methods:
[DllImport("MyOwn.dll", CallingConvention = CallingConvention.Cdecl)]
[return: MarshalAs((UnmanagedType.I4))]
public static extern Int32 MyProIni(string DBname, string DBuser_pass,
string WorkDirectory, ref StringBuilder ErrorMessage);
When I tried following this article and when I run this example (from the downloaded code) it runs without a problem (the dll used is in the bin/debug folder)
I have copied my dll (along with all the files the it depends on into my bin folder).
I also tried this approach but got the same error:
[DllImportAttribute(MyOwnLibDllPath, EntryPoint="TMproIni")]
[return: MarshalAs(UnmanagedType.I4)]
public static extern int MyproIni(string DBname, string DBuser_pass,
string WorkDirectory, ref StringBuilder ErrorMessage);
Any suggestions?
From what I remember on Windows the search order for a dll is:
Current Directory
System folder, C:\windows\system32 or c:\windows\SysWOW64 (for 32-bit process on 64-bit box).
Reading from the Path environment variable
In addition I'd check the dependencies of the DLL, the dependency walker provided with Visual Studio can help you out here, it can also be downloaded for free: http://www.dependencywalker.com
You can use the dumpbin tool to find out the required DLL dependencies:
dumpbin /DEPENDENTS my.dll
This will tell you which DLLs your DLL needs to load. Particularly look out for MSVCR*.dll. I have seen your error code occur when the correct Visual C++ Redistributable is not installed.
You can get the "Visual C++ Redistributable Packages for Visual Studio 2013" from the Microsoft website. It installs c:\windows\system32\MSVCR120.dll
In the file name, 120 = 12.0 = Visual Studio 2013.
Be careful that you have the right Visual Studio version (10.0 = VS 10, 11 = VS 2012, 12.0 = VS 2013...) right architecture (x64 or x86) for your DLL's target platform, and also you need to be careful around debug builds. The debug build of a DLL depends on MSVCR120d.dll which is a debug version of the library, which is installed with Visual Studio but not by the Redistributable Package.
The DLL has to be in the bin folder.
In Visual Studio, I add the dll to my project NOT in References, but "Add existing file". Then set the "Copy to Output Directory" Property for the dll to "Copy if newer".
This is a 'kludge' but you could at least use it to sanity-test:
Try hard-coding the path to the DLL in your code
[DllImport(#"C:\\mycompany\\MyDLL.dll")]
Having said that; in my case running dumpbin /DEPENDENTS as suggested by #anthony-hayward, and copying over 32-bit versions of the DLLs listed there into my working directory solved this problem for me.
The message is just a bit misleading, becuase it isn't "my" dll that can't be loaded - it's the dependencies
Try to enter the full-path of the dll.
If it doesn't work, try to copy the dll into the system32 folder.
"Unable to load DLL 'xxx.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)" means the file CAN be found BUT it's not able to load it. Try to copy the DLL file to the root folder of your application, some DLL libraries need to be available in the root folder of the application in order for it to work. Or check if there are any other depending DLL files required by it.
"Cannot find DLL 'xxx.dll': ..." means the file CANNOT be found. Try to check the path. For example, [DllImport(#"\Libraries\Folder\xxx.dll")]
Ensure that all dependencies of your own dll are present near the dll, or in System32.
Turn on the fusion logging, see this question for lots of advice on how to do that. Debugging mixed-mode apps loading problems can be a right royal pain. The fusion logging can be a big help.
Make sure you set the Build Platform Target to x86 or x64 so that it is compatible with your DLL - which might be compiled for a 32 bit platform.
There is one very funny thing (and has a technical relevance) which might waste your hours so thought of sharing it here -
I created a console application project ConsoleApplication1 and a class library project ClassLibrary1.
All the code which was making the p/invoke was present in ClassLibrary1.dll. So before debugging the application from visual studio I simply copied the C++ unmanaged assembly (myUnmanagedFunctions.dll) into the \bin\debug\ directory of ClassLibrary1 project so that it can be loaded at run-time by the CLR.
I kept getting the
Unable to load DLL
error for hours. Later on I realized that all such unmanaged assemblies which are to be loaded need to be copied into the \bin\debug directory of the start-up project ConsoleApplication1 which is usually a win form, console or web application.
So please be cautious the Current Directory in the accepted answer actually means Current Directory of main executable from where you application process is starting. Looks like an obvious thing but might not be so at times.
Lesson Learnt - Always place the unamanaged dlls in the same directory as the start-up executable to ensure that it can be found.
I had the same problem when I deployed my application to test PC. The problem was development PC had msvcp110d.dll and msvcr110d.dll but not the test PC.
I added "Visual Studio C++ 11.0 DebugCRT (x86)" merge module in InstalledSheild and it worked. Hope this will be helpful for someone else.
In my case one unmanaged dll was depending on another which was missing. In that case the error will point to the existing dll instead of the missing one which can be really confusing.
That is exactly what had happen in my case. Hope this helps someone else.
If the DLL and the .NET projects are in the same solution and you want to compile and run both every time, you can right click the properties of the .NET project, Build events, then add something like the following to Post-build event command line:
copy $(SolutionDir)Debug\MyOwn.dll .
It's basically a DOS line, and you can tweak based on where your DLL is being built to.
I think your unmanaged library needs a manifest.
Here is how to add it to your binary. and here is why.
In summary, several Redistributable library versions can be installed in your box but only one of them should satisfy your App, and it might not be the default, so you need to tell the system the version your library needs, that's why the manifest.
Setup: 32-bit Windows 7
Context: Installed a PCI-GPIB driver that I was unable to communicate through due to the aforementioned issue.
Short Answer: Reinstall the driver.
Long Answer:
I also used Dependency Walker, which identified several missing dependency modules. Immediately, I thought that it must have been a botched driver installation. I didn't want to check and restore each missing file.
The fact that I was unable to find the uninstaller under Programs and Features of the Control Panel is another indicator of bad installation. I had to manually delete a couple of *.dll in \system32 and registry keys to allow for driver re-installation.
Issue fixed.
The unexpected part was that not all dependency modules were resolved. Nevertheless, the *.dll of interest can now be referenced.
I have come across the same problem, In my case I had two 32 bit pcs.
One with .NET4.5 installed and other one was fresh PC.
my 32-bit cpp dll(Release mode build) was working fine with .NET installed PC but Not with fresh PC where I got the below error
Unable to load DLL 'PrinterSettings.dll': The specified module could not be
found. (Exception from HRESULT: 0x8007007E)
finally,
I just built my project in Debug mode configuration and this time my
cpp dll was working fine.
Also faced the same problem when using unmanaged c/c++ dll file in c# environment.
1.Checked the compatibility of dll with 32bit or 64bit CPU.
2.Checked the correct paths of DLL .bin folder, system32/sysWOW64 , or given path.
3.Checked if PDB(Programme Database) files are missing.This video gives you ans best
undestand about pdb files.
When running 32-bit C/C++ binary code in 64bit system, could arise this because of platform incompatibility. You can change it from Build>Configuration manager.
I faced the same problem when import C++ Dll in .Net Framework +4, I unchecked Project->Properties->Build->Prefer 32-bit and it solved for me.
It has nothing to do with dependencies if you checked all dependencies and you know you got them all, it has nothing to do with the file being in the wrong directory either or incorrect ARGUMENTS passed to dll, the DLL Fails to load using LoadLibrary itself.. you could check the address returned from LoadLibrary is always 0x0000000 (not loaded).
I couldn't figure this error out either it worked fine on Windows 7, but on Windows 10 it doesn't work. I fixed the problem though it had nothing to do with missing dependencies or Runtime redistributable packs.
The problem was I had to pack the DLL with upx and it started working again.
Something with the file being unpacked and compiled on old Windows XP operating system created a bad PE Header or Bad file format or something, but packing it with UPX did the trick works fine now and the DLL got 3x smaller haha.
I got this error for one C++ project in our solution, and only on our buildmaster's machine. The rest of us could build it with no problem.
In our case it was because that particular project had <WindowsTargetPlatformVersion> in the .vcxproj file set to "10.0" vs. "10.0.18362.0" as in all our other C++ projects.
Not specifying the entire SDK version number seems to have allowed MSBuild to choose the newest(?) SDK and associated build tools.
Our buildmaster likely had the remnants of a newer SDK on his machine, and MSBuild was trying to use it (and thus RC.exe was not found).
In any case, bringing up the project's property page and changing Configuration Properties > General > Windows SDK Version to "10.0.18362.0" (or whichever specific version of the SDK you have installed) for all of the project's configurations/platforms did the trick.
I am using a C# application to try to connect to a SQLite database. The application uses the library System.Data.Sqlite, version 108. In Visual Studio 2017, my Solution Configuration is Debug, and my Solution Platform is Any CPU. Whenever I build and run the application, I get the following runtime exception:
The exception is unhandled, and the application terminates.
There is, of course, a SQLite.Interop.dll file in my bin\Debug directory. (If there wasn't, the exception would be different.) Specifically, there are two, each in their own subdirectories named x64 and x86. My assumption is that the file in the x86 directory is being used, since the Solution Platform is set to Any CPU. The version of the SQLite.Interop.dll assembly matches that of System.Data.SQLite.dll, being 1.0.108.0.
When I use the following command to interrogate the assemblies:
dumpbin /exports SQLite.Interop.dll
I do find the following line in the output for the x64 version of the assembly:
175 AE 00040750 sqlite3_open_interop
but in the output for the x86 version I do not. Instead, I find this line:
175 26 00037F10 _sqlite3_open_interop#20
which is close, but not a match. So there is indeed no such method as sqlite3_open_interop exposed by the assembly.
I have tried the obvious solution of changing the Solution Platform to x64, but that change leads to another exception (BadImageFormatException) which I don't much want to contend with.
I have tried dropping the reference to System.Data.SQLite and using Nuget to add the most recent version, 1.0.111.0, then cleaning and rebuilding the solution, but all to no effect. The same issue recurs.
Could anyone suggest a solution to this issue? SQLite is widely used, I believe, so I have to think there's a way to work through it.
*Edit1: I tried this project on my home computer, and observed the same difference between the two SQLite.Interop.dll files. The x64 version had a sqlite3_open_interop, while the x86 version had a _sqlite3_open_interop#20. However, the problem did not occur there. So apparently this mangled name "issue" is a red herring. I am still very interested in solving this problem, and would appreciate the assistance of someone who works on System.Data.Sqlite!
Delete your x64 and x86 directory then do a build. It will put the correct version in the folder when the installer does the NuGet check. For some reason, when you upgrade to a newer version, the x64 and x86 folders do not update the interop file in those folders if one already exists.
It turned out the issue was that the assembly was being blocked or disrupted somehow by McAfee Host Intrusion Prevention. The Activity log had the following message:
Attack type: DISA McAfee - Prevent unexpected DLL files from Running
in User AppData and ProgramData folders (Sig Id = 7020)
Which is odd because I don't think my program was executing in either such folder; in fact, there are no such folders, as I am looking at the matter. I was able to fix the issue by moving the program to My Documents.
It's also notable that the exception made no hint of interference by a security scanner.
Sigh. I don't know how generally useful this answer is, but I will leave it here. It might help someone. The admins can remove it if they deem appropriate.
Though its an old thread but nevertheless someone else may face similar issue again. In my case, this error occurs when I try to make connection string with password, since in the latest version of sqlite, ecnryption has been a paid feature that's why it doesn't work in free version. So, to circumvant this issue I restored old version of sqlite (picked from my old project) and it worked ok.
Add following reference in your project:
System.Data.SQLite.dll
Copy following files in binary folder:
System.Data.SQLite.dll.config (Optional)
System.Data.SQLite.xml (Optional)
x64\SQLite.Interop.dll
x86\SQLite.Interop.dll
Where 'x64' and 'x86' are folders
Packages available on nuget have same issue so you need old dll
I have a dll library with unmanaged C++ API code I need to use in my .NET 4.0 application. But every method I try to load my dll I get an error:
Unable to load DLL 'MyOwn.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
I have read and tried several solutions I have found on the internet. Nothing works..
I have tried using following methods:
[DllImport("MyOwn.dll", CallingConvention = CallingConvention.Cdecl)]
[return: MarshalAs((UnmanagedType.I4))]
public static extern Int32 MyProIni(string DBname, string DBuser_pass,
string WorkDirectory, ref StringBuilder ErrorMessage);
When I tried following this article and when I run this example (from the downloaded code) it runs without a problem (the dll used is in the bin/debug folder)
I have copied my dll (along with all the files the it depends on into my bin folder).
I also tried this approach but got the same error:
[DllImportAttribute(MyOwnLibDllPath, EntryPoint="TMproIni")]
[return: MarshalAs(UnmanagedType.I4)]
public static extern int MyproIni(string DBname, string DBuser_pass,
string WorkDirectory, ref StringBuilder ErrorMessage);
Any suggestions?
From what I remember on Windows the search order for a dll is:
Current Directory
System folder, C:\windows\system32 or c:\windows\SysWOW64 (for 32-bit process on 64-bit box).
Reading from the Path environment variable
In addition I'd check the dependencies of the DLL, the dependency walker provided with Visual Studio can help you out here, it can also be downloaded for free: http://www.dependencywalker.com
You can use the dumpbin tool to find out the required DLL dependencies:
dumpbin /DEPENDENTS my.dll
This will tell you which DLLs your DLL needs to load. Particularly look out for MSVCR*.dll. I have seen your error code occur when the correct Visual C++ Redistributable is not installed.
You can get the "Visual C++ Redistributable Packages for Visual Studio 2013" from the Microsoft website. It installs c:\windows\system32\MSVCR120.dll
In the file name, 120 = 12.0 = Visual Studio 2013.
Be careful that you have the right Visual Studio version (10.0 = VS 10, 11 = VS 2012, 12.0 = VS 2013...) right architecture (x64 or x86) for your DLL's target platform, and also you need to be careful around debug builds. The debug build of a DLL depends on MSVCR120d.dll which is a debug version of the library, which is installed with Visual Studio but not by the Redistributable Package.
The DLL has to be in the bin folder.
In Visual Studio, I add the dll to my project NOT in References, but "Add existing file". Then set the "Copy to Output Directory" Property for the dll to "Copy if newer".
This is a 'kludge' but you could at least use it to sanity-test:
Try hard-coding the path to the DLL in your code
[DllImport(#"C:\\mycompany\\MyDLL.dll")]
Having said that; in my case running dumpbin /DEPENDENTS as suggested by #anthony-hayward, and copying over 32-bit versions of the DLLs listed there into my working directory solved this problem for me.
The message is just a bit misleading, becuase it isn't "my" dll that can't be loaded - it's the dependencies
Try to enter the full-path of the dll.
If it doesn't work, try to copy the dll into the system32 folder.
"Unable to load DLL 'xxx.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)" means the file CAN be found BUT it's not able to load it. Try to copy the DLL file to the root folder of your application, some DLL libraries need to be available in the root folder of the application in order for it to work. Or check if there are any other depending DLL files required by it.
"Cannot find DLL 'xxx.dll': ..." means the file CANNOT be found. Try to check the path. For example, [DllImport(#"\Libraries\Folder\xxx.dll")]
Ensure that all dependencies of your own dll are present near the dll, or in System32.
Turn on the fusion logging, see this question for lots of advice on how to do that. Debugging mixed-mode apps loading problems can be a right royal pain. The fusion logging can be a big help.
Make sure you set the Build Platform Target to x86 or x64 so that it is compatible with your DLL - which might be compiled for a 32 bit platform.
There is one very funny thing (and has a technical relevance) which might waste your hours so thought of sharing it here -
I created a console application project ConsoleApplication1 and a class library project ClassLibrary1.
All the code which was making the p/invoke was present in ClassLibrary1.dll. So before debugging the application from visual studio I simply copied the C++ unmanaged assembly (myUnmanagedFunctions.dll) into the \bin\debug\ directory of ClassLibrary1 project so that it can be loaded at run-time by the CLR.
I kept getting the
Unable to load DLL
error for hours. Later on I realized that all such unmanaged assemblies which are to be loaded need to be copied into the \bin\debug directory of the start-up project ConsoleApplication1 which is usually a win form, console or web application.
So please be cautious the Current Directory in the accepted answer actually means Current Directory of main executable from where you application process is starting. Looks like an obvious thing but might not be so at times.
Lesson Learnt - Always place the unamanaged dlls in the same directory as the start-up executable to ensure that it can be found.
I had the same problem when I deployed my application to test PC. The problem was development PC had msvcp110d.dll and msvcr110d.dll but not the test PC.
I added "Visual Studio C++ 11.0 DebugCRT (x86)" merge module in InstalledSheild and it worked. Hope this will be helpful for someone else.
In my case one unmanaged dll was depending on another which was missing. In that case the error will point to the existing dll instead of the missing one which can be really confusing.
That is exactly what had happen in my case. Hope this helps someone else.
If the DLL and the .NET projects are in the same solution and you want to compile and run both every time, you can right click the properties of the .NET project, Build events, then add something like the following to Post-build event command line:
copy $(SolutionDir)Debug\MyOwn.dll .
It's basically a DOS line, and you can tweak based on where your DLL is being built to.
I think your unmanaged library needs a manifest.
Here is how to add it to your binary. and here is why.
In summary, several Redistributable library versions can be installed in your box but only one of them should satisfy your App, and it might not be the default, so you need to tell the system the version your library needs, that's why the manifest.
Setup: 32-bit Windows 7
Context: Installed a PCI-GPIB driver that I was unable to communicate through due to the aforementioned issue.
Short Answer: Reinstall the driver.
Long Answer:
I also used Dependency Walker, which identified several missing dependency modules. Immediately, I thought that it must have been a botched driver installation. I didn't want to check and restore each missing file.
The fact that I was unable to find the uninstaller under Programs and Features of the Control Panel is another indicator of bad installation. I had to manually delete a couple of *.dll in \system32 and registry keys to allow for driver re-installation.
Issue fixed.
The unexpected part was that not all dependency modules were resolved. Nevertheless, the *.dll of interest can now be referenced.
I have come across the same problem, In my case I had two 32 bit pcs.
One with .NET4.5 installed and other one was fresh PC.
my 32-bit cpp dll(Release mode build) was working fine with .NET installed PC but Not with fresh PC where I got the below error
Unable to load DLL 'PrinterSettings.dll': The specified module could not be
found. (Exception from HRESULT: 0x8007007E)
finally,
I just built my project in Debug mode configuration and this time my
cpp dll was working fine.
Also faced the same problem when using unmanaged c/c++ dll file in c# environment.
1.Checked the compatibility of dll with 32bit or 64bit CPU.
2.Checked the correct paths of DLL .bin folder, system32/sysWOW64 , or given path.
3.Checked if PDB(Programme Database) files are missing.This video gives you ans best
undestand about pdb files.
When running 32-bit C/C++ binary code in 64bit system, could arise this because of platform incompatibility. You can change it from Build>Configuration manager.
I faced the same problem when import C++ Dll in .Net Framework +4, I unchecked Project->Properties->Build->Prefer 32-bit and it solved for me.
It has nothing to do with dependencies if you checked all dependencies and you know you got them all, it has nothing to do with the file being in the wrong directory either or incorrect ARGUMENTS passed to dll, the DLL Fails to load using LoadLibrary itself.. you could check the address returned from LoadLibrary is always 0x0000000 (not loaded).
I couldn't figure this error out either it worked fine on Windows 7, but on Windows 10 it doesn't work. I fixed the problem though it had nothing to do with missing dependencies or Runtime redistributable packs.
The problem was I had to pack the DLL with upx and it started working again.
Something with the file being unpacked and compiled on old Windows XP operating system created a bad PE Header or Bad file format or something, but packing it with UPX did the trick works fine now and the DLL got 3x smaller haha.
I got this error for one C++ project in our solution, and only on our buildmaster's machine. The rest of us could build it with no problem.
In our case it was because that particular project had <WindowsTargetPlatformVersion> in the .vcxproj file set to "10.0" vs. "10.0.18362.0" as in all our other C++ projects.
Not specifying the entire SDK version number seems to have allowed MSBuild to choose the newest(?) SDK and associated build tools.
Our buildmaster likely had the remnants of a newer SDK on his machine, and MSBuild was trying to use it (and thus RC.exe was not found).
In any case, bringing up the project's property page and changing Configuration Properties > General > Windows SDK Version to "10.0.18362.0" (or whichever specific version of the SDK you have installed) for all of the project's configurations/platforms did the trick.
I built an application that used some extrnal libraries, Like Tag-lib, Naudio and Windows Media Player.
So they add me to my solution (in the same folder as my EXE file), some DLLs.
I wanted to embed those DLLs to my EXE file, so I looked at the internet and found some options.
The best answer I found was this:
Embedding DLLs in a compiled executable
And it worked, but not for all of the DLLs.
It successfully embedded Naudio and Tag-Lib, But Unabled to embed Windows Media Player's DLLs.
Can anyone help me embed the Windows Media Player's DLLs to my application's EXE?
Update:
After some help (Thanks Mathieu Wybrecht) it worked.
I did everything that he said, but still it isn't working well.
The EXE file work perfectlly, I can move him and it will work.
But when I'm in the project's solution, it error me about the missing Dlls (The Dlls of WMP that Costura.Fody just embed...), and then I copy the Dll again to the folder and the error gone. It seccessed to build the solution, rebuild the solution or starting the program, the DLLs Disapear again (embed to the EXE) and the error comes up again...
Your question is not clear. What do you mean by "when I started to use Windows Media Player, it added a DLL file, and now it doesn't ..."
Where did "it" add a DLL file?
What is "it" ? Your application? Windows Media Player?
What DLL was added?
If the problem is that you want to embed one more DLL in your exe, follow the how-to you found about Costura.Fody.
If the problem occurs at run time, ensure that all embedded DLL don't try to load more dependencies. You can check for their dependencies using "Dependency Walker", it exists for x86 and x64 platform.
Edit: you edited your question, and now I'm back to edit my answer too :)
So, you succeeded to embed few DLL but not every one of them. It can be related to some of following reasons:
Some of them are native DLL (you have to follow a particular process to embed) : you may refer to Fody/Costura unmanaged assemblies and Fody/Costura Native Libraries
For some of them, Reference in your project are maybe not marked as "Copy Local = true" and/or not considered as "Embeded Resources" for some reason
Maybe your library is correctly embedded but still present in your output directory for you may not have installed the clean-output target ?
take a look at Clean output directory
Or you may face another problem that is more specific, try to get a look at Fody/Costura issues, you may find a reason for which your desired libraries are not embedded.
If anyone who use Emgu openCv wrapper in .net 3.5 framework,please tell me why this exception appears,Its inner exception is unable to load cxcore.dll.
For Emgu CV version <= 2.1, this means the following dlls: cvXXX.dll, cvauxXXX.dll, cxcoreXXX.dll, highguiXXX.dll, opencv_ffmpegXXX.dll, mlXXX.dll and cvextern.dll where XXX is the OpenCV version number.
For Emgu CV version >= 2.2 this means the following dlls: opencv_calib3dXXX.dll, opencv_contribXXX.dll, opencv_coreXXX.dll, opencv_features2dXXX.dll, opencv_highguiXXX.dll, opencv_imgprocXXX.dll, opencv_legacyXXX.dll, opencv_mlXXX.dll, opencv_objectdetectXXX.dll, opencv_videoXXX.dll where XXX is the OpenCV version number.
copy these file and paste them in C:\WINDOWS\system32
it works with me
Here's how I could solve the problem:
Copy the x86 (or x64 on 64-bit OS) folder address under "bin" folder where your Emgu is installed. Mine is: C:\Emgu\emgucv-windows-universal-gpu 2.4.9.1847\bin\x86
Then paste this address here:
Control Panel>System>Advanced System Settings>Environment Variables> in system variables click on "Path" and click edit > add a semicolon to the end of the string there and paste the address you've just copied to clipboard after that semicolon > click on the OKs.
This error happened to me. I added cxcore210.dll (for emgucv 2.1 version) which is originally located inside the bin folder.
Then this caused a new error saying that I must also include the highgui210.dll (also for emgucv 2.1 version)...
Then the problem was solved :)
I hope it works for you too...
You don't have the right version of openCV installed, or you don't have the openCV dll's installed at all. The latest version of Emgu uses cxcore110.dll, previous version use cxcore100.dll. They have to either be in the directory your application is running, or in the path (probably %system32%). I had this problem a when I tried to get Emgu running.
After trying all posible opencv_xxx combinations, what it worked for me was including the library npp32_42_9.dll. Hope it helps.
I suggest you turn on Fusion logging and see where it's trying to load cxcore.dll from, and check that you've got it in the right place.
I'm having the same problem. I setup Fusion logging and it wasn't helpful, for me. I'm running the assembly in the same directory as cxcore110.dll, so I'm stumped.
Next, I loaded/copied all of the OpenCV DLLs in a directory in my path, same problem.
Found the solution after using dependency walker. It was working on any system that had VS2005 & VS2008. If you only have VS2008, then you'll need the Microsoft Visual C++ 2005 SP1 Redistributable Package (x86)s]1.
If you already did the dll setup and still get the exception try as follows:
Go to Project Properties -> Application -> Target Framework, and change it to NET. Framework 4 and click 'Yes'. Run again your application, and it should work just fine.
It took me a while to figure out why this was happening in my case as none of the above solutions solved the problem. It turned out that I had Windows 10 Pro N installed which lacks media features. After installing the Media Feature Pack it worked.
I had that error times and times. I was using EmguCV 2.4.9 and .Net framework 4.5.
I checked many tutorials but didn't find the answer. At the end when i put the opencv files both from version 220 and 249 it worked!
Copy and paste all the unmanaged dlls in the bin folder of your EMGU installation to where your exe file is (Release or Debug folder of your project folder).
In my case, unmanaged dlls are at "C:\Emgu\emgucv-windows-universal-cuda 2.9.0.1922\bin\x86"
I installed EmguCV 2.9 recently. 64 bit application works fine. This exception showed up when I tried to use 32 bit platform (x86).
I realized that while following a tutorial to setup Emgu , I had set the "Path" in the system environment variables to .\x64 folder. For my case, it is C:\Emgu\emgucv-windows-universal-cuda 2.9.0.1922\bin\
To make the 32 bit application work, I changed the "Path" variable to .\x86 folder, restart the computer. The draw back is 64 bit solution will no longer work.
The ideal solution is to copy all the DLL files from .\x86 or .\x64 to where the executable locates. For my case, because I am using LabVIEW + .NET DLL, the LabVIEW gets a copy of the DLL into its cache folder, so the temporary solution for the easy of development is to change "Path" variable. When I distribute the final binary executable, I will copy the matching DLL files.
In my case, adding these files under the bin\release solved this issue: npp32_42_9.dll and cudart32_42_9.dll
It took me around 2 hours to conclude this :)
I have installed OpenCv2.3.1 before and yesterday i installed the last version of EmguCV3.0 (also tried 2.9 ) but it gave that error.
all the solutions that i tried didn't work than I installed EmguCV 2.3 and its solved. i think version of EmguCV and opencv important for solution.
After trying a lot things, if your .dll files are all correctly placed and only version problem exits try following simple steps:
Open properties of created project
Go to build section
Change platform target to "Any CPU"
Save and rebuild project.