.NET Core 中的路径问题

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

1.工作路径 WorkingDirectory

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

Environment.CurrentDirectory;
Directory.GetCurrentDirectory();

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

（1）我们通过VS F5直接运行

1529820341662

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

（2）通过dotnet 命令运行

我们在项目根目录，执行 dotnet run命令：

1529820460067

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

1529820714691

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

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

1529821435227

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

2.结论

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

Environment.CurrentDirectory; //获取应用程序工作目录
Directory.GetCurrentDirectory();//获取应用程序工作目录(和上面的方式效果是一样的)

Path.GetDirectoryName(typeof(Program).Assembly.Location);//获取应用程序所在目录（绝对，不受工作目录影响）