c# - Linux下的C#，WorkingDirectory无法正常工作

我对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时两者都不起作用。

最佳答案

在本例中，process.StartInfo.WorkingDirectory的含义不是可执行文件的位置。
这就是导致你正在经历的行为的原因，而process.StartInfo.WorkingDirectory的含义根据process.StartInfo.UseShellExecute的值而改变。
从Microsoft documentation开始：
当UseShellExecute为true时，WorkingDirectory属性的行为与UseShellExecute为false时的行为不同。
当UseShellExecute为false时，不使用WorkingDirectory属性查找可执行文件。相反，它的值适用于已启动的进程，并且仅在新进程的上下文中有意义。
dotnet core中UseShellExecute的默认值是false。在Linux上将UseShellExecute设置为true时，我经历了一些奇怪的事情。
就我个人而言，我会保持它为false，并确保使用完整路径或相对于项目根目录的路径，如下所示：
process.StartInfo.FileName="bin/Debug/netcoreapp2.1/subdir/a.out";

关于c# - Linux下的C#，WorkingDirectory无法正常工作，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/52613775/