過去在 .NET Framework 想要取得執行檔所在位置，我都是用 System.Reflection.Assembly.GetExecutingAssembly().Location 搞定，很少有無法正常運作的時候，但是到了 .NET Core／.NET 的時代，這個方法已經不再適用於多數情境了。
底下這幾種取得執行檔所在位置的方式，都能在 .NET Core／.NET 執行。
- System.AppContext.BaseDirectory：等同於 System.AppDomain.CurrentDomain.BaseDirectory
- System.IO.Directory.GetCurrentDirectory()
- System.Environment.CurrentDirectory
- System.Reflection.Assembly.GetExecutingAssembly().Location
- System.Reflection.Assembly.GetEntryAssembly().Location
- System.Diagnostics.Process.GetCurrentProcess().MainModule.FileName
只不過，不同的情境，我們會取到不一樣的值，所以說想要取得執行檔的所在位置，我們得先了解應用程式的發佈方式、部署的環境，以及 SDK 的版本，比如說，應用程式被發佈成單一檔案，或者是說交由工作排程器啟動，在這些情境下，有些方式所取得的路徑，可能就不符合我們預期。
上面的執行畫面是我用 .NET Core 3.1 建置出來的結果，下面則是用 .NET 6，我們可以看到，發佈成單一檔案的執行結果就不一樣了。
好，那這幾種取得執行檔所在位置的方法中，有沒有通用的方法？ 有，如果我們是 .NET 6+ 的應用程式，基本上 System.AppContext.BaseDirectory 應該是通用了，不是的話，則可以用 System.Diagnostics.Process.GetCurrentProcess().MainModule.FileName，.NET 6+ 則有新的 API - System.Environment.ProcessPath 可以使用。
.NET 自從開源以來，API 就不斷地在更新，可能有朋友會覺得怎麼改來改去的？但是我認為這是無法避免的，畢竟微軟是將 .NET 打掉重練，發展了一二十年的成果，要一邊拆解、移植，還要一邊尋找最適的設計方式，也不是一件容易的工作，不過就目前 .NET 每更新一個主要版本，效能就提升一層的節奏來看，後世可期，我很期待 .NET 未來的發展。
