.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);//獲取應用程序所在目錄（絕對，不受工