首页 文章

.NET Process的不止一条重要途径

提问于
浏览
6

在我正在进行的项目中,我正在开始一个外部流程 . 但是,外部进程是复杂程序的EXE,它从用户文件夹加载当前用户信息 . 程序的桌面快捷方式通过将"Target:"参数设置为 X:\exepath\prgm.exe 并将"Start In"参数设置为用户的路径 X:\exepath\users\username 来解决此问题 .

我目前正在启动这样的流程:

Process p = new Process();
p.StartInfo = new ProcessStartInfo( "X:\exepath\prgm.exe" );
p.StartInfo.WorkingDirectory = "X:\exepath\users\username";
p.Start();
while (!p.HasExited) { }

但是,当进程启动时,它启动的程序最终会查找 WorkingDirectory 中的所有资源,而不是从该文件夹中提取用户内容以及EXE所在目录中的所有其他内容 . 这表明工作目录和系统快捷方式“Start In:”参数表现不同 .

有没有办法用C#进程模仿这种行为?或者,是否可以在C#中创建一个快捷方式,然后我可以从我的Process调用开始?

如果有更多信息可以提供帮助,请与我们联系 .

编辑 -

经过一些试验和错误之后,我决定使用WSH to create a shortcut并运行它 . WSH使用名称WorkingDirectory作为"Start In:"参数的值 . 它的行为与我上面代码中的进程执行情况相同 . 我仍然得到错误 .

2 回答

  • 1

    差异可能是由于使用Shell进程执行:http://msdn.microsoft.com/en-us/library/system.diagnostics.processstartinfo.useshellexecute.aspx

    当UseShellExecute为true时,WorkingDirectory属性的行为与UseShellExecute为false时的行为不同 . 当UseShellExecute为true时,WorkingDirectory属性指定可执行文件的位置 . 如果WorkingDirectory是空字符串,则当前目录被理解为包含可执行文件 . 当UseShellExecute为false时,不使用WorkingDirectory属性来查找可执行文件 . 相反,它由启动的进程使用,并且仅在新进程的上下文中具有意义 .

    我怀疑如果你将p.StartInfo.UseShellExecute设置为false,它可能会按你的意愿运行 .

  • 1

    我已经解决了我的问题,毕竟这与创建一个过程无关 . 事实上,根本原因是有点尴尬,但可能有教育意义,所以我会提供一个解释 .

    我在OP中发布的代码是用于说明问题的示例代码 . 在我的实际项目中,我从注册表项中检索 ExePathUserPath . 该项目是一个Chooser工具,用于在多个已安装的第三方软件版本之间切换,并读取/编辑这些注册表项以完成其工作 .

    当我编写写入注册表的代码时,我使用了 DirectoryInfo.FullPath ,它返回 "X:\ExePath" 而不是 "X:\ExePath\" . 这使程序无法从ExePath文件夹中找到所需的文件,查找X:\ ExePathsettings.inf " instead of " X:\ ExePath \ settings.inf“ . 我将尾部反斜杠插入到我的代码和现有的注册表中,并且一切都很好 .

    获得的经验:请务必非常仔细地检查您的路径值 .

相关问题