Specify DLLs for an exe launched with Process.Start?
I'm trying to launch an executable with Process.Start(). When the exe has no DLL dependencies, it works fine. However, when I need to include 2 DLLs, it doesn't work. I've tried setting the WorkingDirectory, and have verified that the 2 required DLLs are present there. Any ideas?
ProcessStartInfo startInfo = new ProcessStartInfo();
startInfo.CreateNoWindow = false;
startInfo.UseShellExecute = false;
startInfo.FileName = "memcached.exe";
startInfo.WindowStyle = ProcessWindowStyle.Hidden;
startInfo.Arguments = arguments; //not shown开发者_Python百科
startInfo.WorkingDirectory = Environment.CurrentDirectory;
try
{
using (Process exeProcess = Process.Start(startInfo))
{
exeProcess.WaitForExit();
}
}
catch (Exception ex)
{
Trace.TraceError(ex.Message); // never gets here
}
This is code based on the Windows Azure Memcached Solution Accelerator. When memcached can't launch, a dialog box is displayed. Unfortunately you can't see this when the code is running remotely in the cloud.
I had similar problem trying to start another process that needed a DLL and couldn't find it. The solution was pretty simple in my case, a missing '\'.
procInfo.WorkingDirectory = @"C:\filedir"; //won't work
procInfo.WorkingDirectory = @"C:\filedir\" ; //would do the trick
procInfo.WorkingDirectory = Enviroment.CurrentDirectory; //== "C:\filedir", that won't work either
procInfo.WorkingDirectory = Enviroment.CurrentDirectory + '\\'; // would work.
Hope that helps you.
The problem might be that you are setting the WorkingDirectory
to the current directory of the current process (which could be anywhere, not necessarily the directory containing your program). Try setting the working directory to the directory containing the exe you want to start.
Also, have you verified that the DLLs are with memcached.exe
(or in the place required by the memcached.exe
)?
Try to place your .EXE file and that referenced assemblies in same place, and to define your WorkingDirectory.WorkingDirectory
to that folder. This probably will work fine.
One extreme alternative is to strong name that references assemblies (DLL) and to register them into GAC.
You should exhaust all other alternatives before think about this option.
精彩评论