I'm loading a dll with DllImport and the name of the dll (as it is in the same folder as my application):
[DllImport("myDll.dll")]
and till here all works fine if application is opened from the same location. But if I run cmd and type:
"C:\path\to\my\application\app.exe"
the application opens but the dll called from the application itself isn't loaded anymore.
So to sum up if I open manually app.exe from C:\path\to\my\application\ the DllImport works fine and loads the dll in the same path.
If I open the application from another location, it isn't loaded anymore.
Any suggestions? Tried also
[DllImport("C:\\path\\to\\my\\application\\myDll.dll")]
and
[DllImport("\\myDll.dll")]
but no way, it doesn't work.
The DLL is located using the DLL search order, as described here: http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586.aspx. Since the DLL is in the same directory as the executable, it will be found because the directory containing the executable is the first place that the system searches.
So we can conclude that the DLL is found by the loader. Since you report that the behaviour changes when the working directory changes it would seem that is the problem. Your DLL has a dependency on the working directory. It's probably a mistake to have such a dependency. You should find a way to avoid such a dependency.
Related
My program runs perfectly except when it is launched as a startup program. When launched as a start up program it is not able to find a first party DLL (or one of it's dependencies).
I get the following exception:
Could not find file or assembly X or one of it's dependencies: C:\Windows\SysWow64\X.dll
It is looking for the first party DLL in the C:\Windows\SysWOW64\ directory instead of in the local directory C:\Program Files\MyProgram\.
The confusing part is, if I launch the program manually everything works fine.
How do I go about finding the source of this problem? I tried using Fusion Log but it only told me the same thing as the exception: That it was trying to load from C:\Windows\SysWOW64 only.
I read that this can occur when your application uses Assembly.Load - The culprit program does use Assembly.LoadFrom - but again, this works fine except when done at start up.
Furthermore, the culprit program does have some [DllImport] attributes.
The issue was to do with using Assembly.LoadFrom and the current directory at start up.
The Assembly.LoadFrom states that it:
assemblyFile may be absolute or relative to the current directory, and the assembly is loaded into the domain of the caller.
When the program is set as a start up program the current directory is
C:\Windows\SysWOW64 for whatever reason.
As you can demonstrate by outputting Directory.GetCurrentDirectory().
Instead of using Assembly.LoadFrom which does not follow the normal probing I am using Assembly.Load as this searches the normal directories where DLLs are contained.
The load context contains assemblies found by probing: in the GAC, in a host assembly store if the runtime is hosted, or in the ApplicationBase and PrivateBinPath of the application domain. Most overloads of the Load method load assemblies into this context.
The load-from context contains assemblies for which the user provided a path not included in the directories searched by probing. LoadFrom, CreateInstanceFrom, and ExecuteAssembly are examples of methods that load by path.
This also explains why Fusion was telling me it was only searching for DLLs in C:\Windows\SysWOW64 - as that's what LoadFrom does, only searches in the directory given. Which in my case was the current directory.
I am using Nmodbus to setup an implementation, and everytime I try to run one of the instances in the code I am prompted with the following error
unable to load DLL 'FTD2XX.dll': The specified module could not be found
I have searched through my system32 folder and copied and pasted a copy of the above DLL in there, and it is also in the folders corresponding to the C# solution. I can see it, it is there, but why am I being prompted with this error?
Aren't you mixing 32bit code with 64bit? Try changing target from AnyCPU to 32bits.
I wrote a dll c++/cli library which uses my other c# dll library. C++/cli library works fine when I've got c# dll in the same folder as application which calls it. This library will be finally loaded to many applications and a C# dll must not be copied into directory with application. It has to be in the same folder as c++/cli library, but in that cases I've got System.IO.FileNotFoundException.
My suggestion is to load c# library manually or to change path where f.ex. firefox is looking for dependencies, but I tried with LoadLibrary() and Assembly::LoadFrom() methods to force loading from right directory. Of course I added directory path with dll to system PATH.
I work on VS2010.
You don't change the default directory where an application will look for dlls.
At design time put your dll in some well know location, the one you are going to deploy to. Add a reference to it, make sure it's set to Don't copy ever, otherwise it will end up in the bin folder. You have to do this otherwise it won't compile.
When you deploy, you'll need one package to deploy common dlls, and one for each application. Careful you don't create your own version of dll hell, if appA needs an older or new version of the common dll, compared to AppB
Add an AppDomain.AssemblyResolve event to main (for windows app). At run time the event handler will get fired when you reference a type in your dll, and the assembly has not yet been loaded.
In there you load it from the well known location. That usually in config, or in a relative path.
E.g.
AllMyApps
CommonDLLS
MyFirstApp
So the path you load the required common dll from would be "..\CommonDlls\MyCommondll.dll".
NB you will want to secure the dlls in some way, otherwise a bad guy might be able to inject their version of one in to your app, which would be bad...
You can use this mechanism to get the dll from a remote server or a database blob as well.
The simplest case is only a few lines of code, just look the event up. Took me about 15 minutes to get this going in a similar scenario.
Not on this machine though, otherwise I'd have pasted in the code.
I'm writing a WebService that references another managed DLL which then uses a third-party DLL. When I start debugging my WebService I get the following error:
Could not load file or assembly 'AForge.Video.FFMPEG.DLL' or one of
its dependencies.
As recommended in many other posts, I tried these steps:
Changed from AnyCPU to x86
Copied all DLLs to %system32% directory
But had no success so far. Any ideas?
Thanks, Matthias
Could not load file or assembly 'AForge.Video.FFMPEG.DLL' or one of its dependencies.
You are either copying the file(s) to the wrong place or not copying the correct files.
Get to the bottom of this by downloading Dependency Walker
You can then drag AForge.Video.FFMPEG.DLL into the application and it will tell you what is missing.
Also, determine the base directory for your application to ensure you are copying the files to the correct folder at runtime. You can do this by writing System.AppDomain.CurrentDomain.BaseDirectory to the console (or add it to your watch)
Also see this
I re-engineered the project structure in VisualStudio to get rid of the dependency to AForder.Video.FFMPEG.DLL. That helped. I found no other solution so far.
I'm getting a System.DllNotFoundException for a .dll which is in the same folder as the executable whenever my application attempts to use a function which exists in the DLL. The weird thing is that it is only occurring on one user's PC; it works fine on my dev PC and it works fine on one non-dev PC that I tried it on. Also, there are other DLLs in the folder which are being found and used correctly. The DLL in question is a native library which is referenced by my application via another DLL which is a c# wrapper for the native library.
My initial instinct is that there must be some other library being referenced by this DLL which doesn't exist on the problematic PC, but I cannot imagine what library this PC could be missing that the other non-dev PC has.
So my questions are this: is there a way to determine the dependencies of a given DLL file? Keep in mind that the DLL in question is a native library (i.e. not managed code), and I do not have access to it's source code. And if it turns out no dependency is missing, what else might cause such an issue?
For unmanaged dlls you can use Dependency Walker to find dependencies.
I would suggest using ILSpy to open the dll and view its dependencies first.