Question

我遇到WorkingDirectory的问题，它没有正确设置所需的路径。我编写了一个简单的hello world测试程序a.out，以试用WorkingDirectory。目录层次结构是这样的：

/home/cli2/test
   /bin/Debug/netcoreapp2.1/subdir/
      a.out
   /obj
   Program.cs
   test.csproj

对于Process类，我具有以下设置

process.StartInfo.FileName = "a.out"
process.StartInfo.UseShellExecute = false;
process.StartInfo.WorkingDirectory = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location) + "/subdir/";

执行dotnet run时，会出现以下错误：

Unhandled Exception: System.ComponentModel.Win32Exception: No such file or directory

令我困惑的问题是，如果我将a.out移至顶层目录，例如：

/home/cli2/project
   /bin/Debug/netcoreapp2.1/subdir/
   /obj
   Program.cs
   test.csproj
   a.out

尽管StartInfo的设置相同，但process.start()会执行hello world程序而不会出错。此外，如果我用原始子目录层次结构更改了FileName = "ls"，它会打印出a.out。在这种情况下，WorkingDirectory的行为符合预期。因此，我确实理解了这种差异以及为什么我不能在其他目录中调用a.out。

我还尝试了WorkingDirectory的绝对路径和相对路径，当我调用a.out时都无效。

Answer 1

在这种情况下，process.StartInfo.WorkingDirectory的含义不是可执行文件的位置。

这就是导致您所遇到的行为的原因，并且含义process.StartInfo.WorkingDirectory根据process.StartInfo.UseShellExecute的值而变化。

来自Microsoft documentation：

当UseShellExecute为true时，WorkingDirectory属性的行为与UseShellExecute为false时的行为不同。

当UseShellExecute为false时，WorkingDirectory属性不用于查找可执行文件。相反，它的值适用于已启动的流程，并且仅在新流程的上下文中具有意义。

dotnet核心中UseShellExecute的默认值为false。在Linux上将UseShellExecute设置为true时，我遇到了奇怪的事情。

就我个人而言，我将其保留为false，并确保使用完整路径或相对于项目根目录的路径，如下所示：

process.StartInfo.FileName="bin/Debug/netcoreapp2.1/subdir/a.out";

Linux下的C＃，WorkingDirectory无法正常工作

1 个答案: