I am using a managed DLL that referencing an unmanaged dll.
I added the unmanaged dll under /External/foo/ directory, and i changed the "Copy To Output Directory" to always.
The problem is that the dlls are copied to the outputDir/External/foo dir and when the runtime tries to find it, it fails with this error: "Unable to load dll: Module cannot be found"
When i copy it directly to the output dir, everything works well.
How can i set the project runtime to search in the sub directories of the outut dir?
Thanks!
You don't want to do this, DLL Search Hell is something you want to avoid. Windows is pretty inflexible about where it looks for DLLs. Rightfully so, DLL Hell is nothing to mess with. The only good place for unmanaged DLLs is in the same directory as your EXE. If you don't want to store the DLLs in the project directory, so copying them is very easy, then you are going to need a post-build event that uses xcopy.exe to copy the DLL to the output directory.
The alternatives are not pretty. If this DLL is implicitly loaded then the only option is to use an installer to add the directory to the system's PATH environment variable. This is a Really Bad idea, way too easy for your program to break. If it is loaded explicitly, either with LoadLibrary or a pinvoke declaration then you have more attractive options since you can alter the search path in your Main() method before the DLL is needed. Either append the path to your local copy of the PATH environment variable by using Environment.SetEnvironmentVariable() or pinvoke SetDllDirectory(). Do beware that you have a deployment problem as well, somebody is going to have to create this subdirectory and copy the DLL there on the user's machine. All great reasons to not do this.
This is something we did in our last project. Write a batch file which copies this unmanaged dll to the output directory. Call the batch file every time the program compiles. You can control the calling of batch file also using a Config key. So it runs based on the config key value true/false. i hope this helps
Related
I am currently developing a program that uses the Ghost Script DLL, by importing it as so:
[DllImport("gsdll32.dll", EntryPoint = "gsapi_init_with_args")]
Now, when I set the project in my solution that uses this directly (located in the directory...\source\repos\uo_test_viewer\omr_scanner\omrmarkengine-master) as the startup project, everything works fine. However, when I change my startup project to a project located in ...\source\repos\uo_test_viewer\UOTestViewer, I get the following error:
The gsdll32.dll wasn't found in the default search path or is not in correct version
(doesn't expose required methods). Please download at least the version 8.64 from the original website.
The only thing that is being changed is that when I set the project that makes this work as the startup project, I am running it directly -- where as with the project that doesn't work, I am creating an object of the form that uses the Ghost Script implementation. Does anybody know what the issue is?
I believe that I have provided all the necessary information, but please let me know if anything more is required. Thank you in advance for your answers!
DllImport looks first in the current working directory, then in the search path (the $PATH) environment variable).
When you start your application in the folder which contains the Ghostscript DLL, then the Windows API call DllImport looks in the current working directory and finds the Ghostscript DLL, so it loads it.
When you start in a directory which does not contain the Ghostscript DLL, then DllImport looks in the Current Working Directory, and does not find the DLL. It then searches the search path, which presumably does not find a Ghostscript DLL, so you get an error.
You either need to be sure the current working directory has a copy of the Ghostscritp DLL, or the DLL is on the search path, or you need to supply a fully qualified path to the Ghostscript DLL in the first argument to DllImport.
In case you are considering distributing this application, please read the AGPL license to ensure that you comply with the terms for using Ghostscript.
I have to use the C# class library code in my native code which is written in c++. For this I added one interface written in c++ add the my C# class library project as dependency to it. This works fine till I put the C# dll in .exe folder , but I put this in libs folders (where we keep our dll's), I get file not found exception when tried to call the C# dll function.
Is there any way to keep c# dll in libs folder and make it work?
Thanks.
Yes, you need to re-add it from the libs folder and it will be fine. Or if you are naming the DLL in your code itself, then just provide the full path along with the DLL name. Then when you recompile, the .exe will contain the path you gave it in the source code and will look for the DLL there.
From the MSDN(LoadLibrary),
Remarks section::
The first directory searched is the directory containing the image
file used to create the calling process (for more information, see the
CreateProcess function). Doing this allows private dynamic-link
library (DLL) files associated with a process to be found without
adding the process's installed directory to the PATH environment
variable. If a relative path is specified, the entire relative path is
appended to every token in the DLL search path list. To load a module
from a relative path without searching any other path, use
GetFullPathName to get a nonrelative path and call LoadLibrary with
the nonrelative path. For more information on the DLL search order,
see Dynamic-Link Library Search Order.
The search path can be altered
using the SetDllDirectory function. This solution is recommended
instead of using SetCurrentDirectory or hard-coding the full path to
the DLL.
If a path is specified and there is a redirection file for
the application, the function searches for the module in the
application's directory. If the module exists in the application's
directory, LoadLibrary ignores the specified path and loads the module
from the application's directory. If the module does not exist in the
application's directory, LoadLibrary loads the module from the
specified directory. For more information, see Dynamic Link Library
Redirection.
If you call LoadLibrary with the name of an assembly
without a path specification and the assembly is listed in the system
compatible manifest, the call is automatically redirected to the
side-by-side assembly.
This is all you need to know about path search of a dll. The easy solution, enter the full path in LoadLibrary call or set your PATH environment variable to contain the alternate path of the dll.
I'm loading dynamically a .NET assembly that depends on several bunches of native .dlls
located in various folders. But Windows finds those DLLs only if their folders are in the PATH environment variable when my application is started.
I would like to modify my PATH variable from my program to allow finding the necessary libraries.
According to
MSDN
"the search order is as follows: ...
The directories that are listed in the PATH environment variable."
Which instance of the PATH environment variable is used?
Every process has an instance.
I tried Environment.SetEnvironmentVariable("PATH", ...) but it did not help.
I also tried
SetDefaultDllDirectories()
together with
AddDllDirectory()
but these made no difference either.
The symptom is that when %PATH% contains the necessary folders when starting my .exe
(from a CMD prompt – it is a console application), ProcessMonitor shows that the native .dlls are probed in all the PATH folders, and are eventually found.
But when %PATH% does not contain the necessary folders at the time of starting, then the native .dlls are probed in the .exe folder and in SYSTEM32 only (although %PATH% contains far more),
regardless of the above-mentioned SetEnvironmentVariable()/SetDefaultDllDirectories()/AddDllDirectory() calls.
What is going here? What am I doing wrong? Why I cannot adjust the PATH for my process effectively?
Note: The AppDomain.AssemblyResolve event cannot help me because it's not fired when native .dlls
load other native .dlls.
That is because each process inherits its environment from the process that spawned it. And it didn't occur to the dit at Microsoft that something like PATH might change during the course of execution, so the CLR never refreshes the environment during process execution (and doesn't provide a means for the process to do so itself). See http://social.msdn.microsoft.com/Forums/vstudio/en-US/acf2d0f3-143e-4ba5-acdc-76a70a5c9830/environment-variables-refresh?forum=csharpgeneral for details.
Since the loader is resolving references to unmanaged DLLs via the normal Win32 way, you should probably look at P/Invoking these Win32 functions to alter the DLL search order used by the Win32 LoadLibrary() and LoadLibraryEx():
SetDllDirectory().
Adds a directory to the search path used to locate DLLs for the application.
AddDllDirectory().
Adds a directory to the process DLL search path.
SetDefaultDllDirectories().
Specifies a default set of directories to search when the calling process loads a DLL.
RemoveDllDirectory().
Removes a directory that was added to the process DLL search path by using AddDllDirectory.
See also DLL Search Order.
I am using a batch file with the following commands to successfully compile a C# code on the fly, run the resulting exe and destry the exe.
start /wait C:\WINDOWS\Microsoft.NET\Framework\v3.5\csc.exe /out:PostillionOutgoing.exe PostillionOutgoing.cs /reference:AlexPilotti.FTPS.Client.dll
call SetupCI.bat
start /wait PostillionOutgoing.exe
del PostillionOutgoing.exe
It works exactly the way I wanted. File AlexPilotti.FTPS.Client.dll is present in the same folder as the .cs files are.
The assembly AlexPilotti.FTPS.Client.dll is also needed by a lot of other similar applications. My question is that is there any centralised place where I can keep this DLL so that all the above batch scripts will find it ? By this way I wont have to keep a copy of this DLL in all the separate folders.
I dont want to place the DLL in GAC. I tried in system32 folder also but it didnt work.
You can use the /lib command line to specify search folders for references
see msdn docs here http://msdn.microsoft.com/en-us/library/vstudio/s5bac5fx.aspx
As per the documentation, there is no fixed location that the runtime uses when probing for assemblies (i.e. when it looks into directories because it hasn't been able to locate the assembly already).
However, if your assembly is strongly named then you can use a <codeBase> configuration element in your app.config to direct the runtime to any path of your choosing.
If your assembly isn't strongly named and you don't want to use app.config then unfortunately you are out of options.
I have a solution with a C++ project and a c# project, which calls methods from the first one using Interop.
As I want to avoid any hard-coded path, I found a way to set the C++ dll's path in the app.config.
My problem is, that my C++ dll depends on other dlls, which I always have to copy into my bin/Release and bin/Debug folder. How can I avoid this?
It would be nice if I could set the path to the 3rd party dlls in the app.config.
I found this
<probing privatePath="bin\DLLs" />
but it seems to work for application subdirectories only.
Don't hard code location for the DLLs. Put the directories into the %PATH% variable. Assuming Windows as environment read Search path for loading DLLs.
EDIT:
%PATH% is an environment variable, so you can set it with Environment.SetEnvironmentVariables. I would read privatePath from the configuration file, and use the given method to append it to %PATH%. Reading from the configuration file could be done with the ConfigurationManager class.
I will Write folloing command in your post build event (So you need not to do the manual work)
xcopy /s c:\source\your_dll_folder c:\your_target_folder\bin\debug
xcopy /s c:\source\your_dll_folder c:\your_target_folder\bin\Release
Here is post build event location properties of your project