.NET Core 中的路径问题

时间:2024-07-25 09:05:20

NET Core 应用程序相对于以前的.NET Framework 应用程序在启动运行的方式上有一定的差异,今天就来谈一谈这个获取应用程序启动路径的问题。

1.工作路径 WorkingDirectory

下面的两种方式都可以获取工作路径,结果都是一样的:

Environment.CurrentDirectory;
Directory.GetCurrentDirectory();

其实所谓的工作路径就是我们应用程序的启动路径,所以我们平时所说的获取应用程序的启动路径,也是通过上面的方式。

(1)我们通过VS F5直接运行

.NET Core 中的路径问题

VS会先编译我们的项目,输出到Debug\对应的sdk版本 目录下,然后以这个目录作为工作路径,启动我们的应用程序。

(2)通过dotnet 命令运行

我们在项目根目录,执行 dotnet run命令:

.NET Core 中的路径问题

我们执行 dotnet run命令来启动时,对于程序的工作路径就是执行命令的路径,所以说,获取到的路径变化了。但是我们通过dotnet run命令运行的应用程序文件实际所在的目录也是和上面的目录一样的,即:Debug\对应的sdk版本,我们可以通过代码来测试一下:

.NET Core 中的路径问题

新加的代码是获取程序集所在的路径,可以发现也是在 Debug\对应的sdk版本 目录下的。

我们将程序发布到 D:\test 目录下

.NET Core 中的路径问题

可以看到,前两种方式获取到的都是执行dotnet命令所在的目录即工作目录,后一种方式是获取到的我们应用程序所在的目录。

2.结论

通过上面的测试,我们可以得出结论,.NET Core 应用程序获取工作路径/启动路径,就是获取的执行dotnet命令时所在的目录,所以当我们在Linux等系统部署时,设置守护进程时,记得一定要将工作路径设置为程序文件所在的目录,不然应用程序获取到的路径将不会是应用程序文件所在的目录,当我们在应用程序里设置了一些相对路径,诸如读取配置文件,写日志(Log4net、NLog),将会与我们的预期不一样。因为相对路径,是默认相对于应用程序的工作路径的。

Environment.CurrentDirectory; //获取应用程序工作目录
Directory.GetCurrentDirectory();//获取应用程序工作目录(和上面的方式效果是一样的) Path.GetDirectoryName(typeof(Program).Assembly.Location);//获取应用程序所在目录(绝对,不受工作目录影响)

AppContext.BaseDirectory 也可以获取应用程序所在目录