[英]Why does Process.Start(ProcessStartInfo) fail?
We've developed a new WPF application, and I have had difficulty launching it from external C# script. 我们开发了一个新的WPF应用程序,我很难从外部C#脚本启动它。
While calling Process.Start(ProcessStartInfo)
method with ProcessStartInfo
object which is initialized with both WorkingDirectory
and FileName
successes, init the FileName
property only fails to launch. 使用
ProcessStartInfo
对象调用Process.Start(ProcessStartInfo)
方法时,该对象使用WorkingDirectory
和FileName
成功进行初始化,但init的FileName
属性仅启动失败。
This is not the case when calling any other application. 调用任何其他应用程序时不是这种情况。
My question - Does different approach to start process has different logic? 我的问题 - 启动过程的不同方法是否有不同的逻辑?
See code for more details: 有关详细信息,请参阅代码
public void LaunchApp(){
/********************************/
/* This code PASSES */
/********************************/
var pStartInfoCalc1 = new ProcessStartInfo
{
FileName = @"C:\Windows\system32\calc.exe",
};
Process.Start(pStartInfoCalc1);
/*****************************/
/* !!!This code FAILS !!! */
/*****************************/
var pStartInfo1 = new ProcessStartInfo
{
FileName = @"C:\Program Files\MyAppFolder\MyApp.exe",
};
Process.Start(pStartInfo1);
/********************************/
/* This code PASSES */
/********************************/
var pStartInfo2 = new ProcessStartInfo
{
WorkingDirectory = @"C:\Program Files\MyAppFolder",
FileName = @"MyApp.exe",
};
Process.Start(pStartInfo2);
/********************************/
/* This code PASSES */
/********************************/
var pStartInfoCalc2 = new ProcessStartInfo
{
WorkingDirectory = @"C:\Windows\system32\",
FileName = @"calc.exe",
};
Process.Start(pStartInfoCalc2); }`
This is the image as it crashes: 这是崩溃的图像:
And following is the the problem signature from the crash screenshot: 以下是崩溃屏幕截图中的问题签名:
Problem signature:
Problem Event Name: CLR20r3
Problem Signature 01: MyApp.exe
Problem Signature 02: 1.0.0.0
Problem Signature 03: 51ef9fd8
Problem Signature 04: mscorlib
Problem Signature 05: 4.0.30319.18052
Problem Signature 06: 5173bf28
Problem Signature 07: 266d
Problem Signature 08: a4
Problem Signature 09: System.Windows.Markup.XamlParse
OS Version: 6.1.7601.2.1.0.256.4
Locale ID: 1033
Additional Information 1: 1989
Additional Information 2: 1989c043e2e04efdbf18835c58bb867b
Additional Information 3: 37d3
Additional Information 4: 37d31c18f56cf3083b1c45ca83bbb78e
Read our privacy statement online:
http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409
If the online privacy statement is not available, please read our privacy statement offline:
C:\Windows\system32\en-US\erofflps.txt
When you do not specify the working directory, the new process will inherit the working directory of your process. 如果未指定工作目录,则新进程将继承进程的工作目录。 That is, the new process will inherit the working directory of the process that called
Process.Start()
. 也就是说,新进程将继承调用
Process.Start()
的进程的工作目录。
That's the only difference between the two attempts to start MyApp
. 这是两次尝试启动
MyApp
的唯一区别。 One of them inherits the working directory, and one of them specifies it. 其中一个继承了工作目录,其中一个指定了它。 Clearly
MyApp
does not like to run with the initial working directory being the directory of your parent process. 显然,
MyApp
不喜欢在初始工作目录是父进程的目录的情况下运行。
Why that is so, I cannot say for sure. 为什么会这样,我不能肯定地说。 It would seem that
MyApp
is attempting some XML parsing at startup. 看起来
MyApp
正在尝试在启动时进行一些XML解析。 So perhaps that XML parsing reads a file that is presumed to be in the working directory. 因此,XML解析可能会读取一个假定在工作目录中的文件。 But in fact the file is located in the same directory as the executable.
但实际上该文件与可执行文件位于同一目录中。
If that is the case then you need to modify MyApp
to solve the problem. 如果是这种情况,那么您需要修改
MyApp
来解决问题。 Instead of using a relative path for this XML file, you need to build an absolute path based on the directory of the executable file. 您需要根据可执行文件的目录构建绝对路径,而不是使用此XML文件的相对路径。
The MyApp
startup code can that directory, like this: MyApp
启动代码可以是该目录,如下所示:
string ExeDir = System.IO.Path.GetDirectoryName(System.Reflection.Assembly.
GetExecutingAssembly().Location));
And then you would use Path.Combine
to form the full path to the XML file. 然后,您将使用
Path.Combine
来形成XML文件的完整路径。
When you don't provide the working directory it will use that of your current application. 如果您不提供工作目录,它将使用您当前应用程序的目录。
Applications such as calc
don't have any external file dependencies, so they don't care where they are launched from. calc
应用程序没有任何外部文件依赖性,因此它们并不关心它们的启动位置。 They don't need to read any files from the working directory . 他们不需要从工作目录中读取任何文件。
Your MyApp.exe
most likely requires data from it's own working directory, possibly a config file. 您的
MyApp.exe
很可能需要来自其自己的工作目录的数据,可能是配置文件。 This test passes because it knows to look in C:\\Program Files\\MyAppFolder
此测试通过,因为它知道查看
C:\\Program Files\\MyAppFolder
/********************************/
/* This code PASSES */
/********************************/
var pStartInfo2 = new ProcessStartInfo
{
WorkingDirectory = @"C:\Program Files\MyAppFolder",
FileName = @"MyApp.exe",
};
Process.Start(pStartInfo2);
When you don't specify the working directory your app crashed because it can't load the required resource because it is trying to find it in the directory of you launching app. 当您没有指定工作目录时,您的应用程序崩溃了,因为它无法加载所需的资源,因为它试图在您启动应用程序的目录中找到它。
It's always best to provide the working directory when launching an application, if you know it. 如果您知道的话,最好在启动应用程序时提供工作目录。
If you can update the MyApp.exe
it can use System.Reflection.Assembly.GetExecutingAssembly().Location
to determine it's own location, then you can read your file paths relative to this, thus eliminating the need for setting the working directory. 如果您可以更新
MyApp.exe
它可以使用System.Reflection.Assembly.GetExecutingAssembly().Location
来确定它自己的位置,然后您可以读取相对于此的文件路径,从而无需设置工作目录。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.