.NET Core 中的路径问题

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

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

1.工做路径 WorkingDirectory

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

Environment.CurrentDirectory;
Directory.GetCurrentDirectory();

其实所谓的工做路径就是咱们应用程序的启动路径，因此咱们平时所说的获取应用程序的启动路径，也是经过上面的方式。

（1）咱们经过VS F5直接运行

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

（2）经过dotnet 命令运行

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

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

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

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

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

2.结论

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

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

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