Linux下的C#,WorkingDirectory无法正常工作 [英] C# under Linux, WorkingDirectory not working properly

查看:409
本文介绍了Linux下的C#,WorkingDirectory无法正常工作的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

I have an issues with WorkingDirectory, and it is not setting the desired path correctly. I wrote a simple hello world test program, a.out, to try out WorkingDirectory. And the directory hierarchy is such:

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

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

I have the following settings for the Process class

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

执行dotnet run时,会出现以下错误:

When I execute dotnet run, I would get an error of:

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

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

The issue that confuses me is that if I move a.out to the top directory such that:

/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的原因.

While having the same StartInfo settings, process.start() executes the hello world program without error. Furthermore, if I change FileName = "ls" with the original subdirectory hierarchy, it does print out a.out. For that case the WorkingDirectory is behaving as expected. So I do understand this discrepancy and why I cannot call a.out in a different directory.

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

Also I have tried both absolute and relative path for WorkingDirectory, neither works when I call a.out.

推荐答案

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

The meaning of process.StartInfo.WorkingDirectory in this case is not the location of the executable.

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

That is what's causing the behavior your are experiencing, and the meaning process.StartInfo.WorkingDirectory changes based on the value of process.StartInfo.UseShellExecute.

Microsoft文档:

当UseShellExecute为true时,WorkingDirectory属性的行为与UseShellExecute为false时的行为不同.

The WorkingDirectory property behaves differently when UseShellExecute is true than when UseShellExecute is false.

如果UseShellExecute为false,则不使用WorkingDirectory属性查找可执行文件.相反,它的值适用于已启动的流程,并且仅在新流程的上下文中具有意义.

When UseShellExecute is false, the WorkingDirectory property is not used to find the executable. Instead, its value applies to the process that is started and only has meaning within the context of the new process.


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


The default value for UseShellExecute in dotnet core is false. I have experienced strange things when setting UseShellExecute to true on Linux.

我个人将其设置为false,并确保使用完整路径或相对于项目根目录的路径,如下所示:

Personally, I would keep it false and make sure to use the full path or a path relative to the project root directory like this:

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

这篇关于Linux下的C#,WorkingDirectory无法正常工作的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆