Ответ 1
Все они дают одинаковый результат
Конечно, нет. currentDir
и dir
оба дают вам текущий рабочий каталог, то есть по умолчанию каталог, из которого был запущен ваш исполняемый файл (но его можно изменить во время выполнения).
В отличие от этого, appBaseDir
и path
получают каталог, содержащий файл исполняемых сборок.
Чтобы проиллюстрировать, как они отличаются, учтите, что у вас есть исполняемый файл, который находится в C:\bar\baz.exe
. Теперь я могу выполнить приложение, введя следующую цепочку команд в терминале:
$ md C:\foo
$ cd C:\foo
$ ..\bar\baz.exe
Теперь текущий рабочий каталог C:\foo
, но базовый каталог приложений C:\bar
. Существуют аналогичные способы установки рабочего каталога для других способов запуска приложения (например, с помощью значка ярлыка или программно, например, через Process.Start
).
Тем не менее, структура предоставляет различные способы доступа к этой информации:
Environment.CurrentDirectory
довольно точно передает значение, которое запрашивает среда выполнения (переменная среды). Directory.GetCurrentDirectory()
может фактически сделать то же самое внутри (я не знаю), но он инкапсулирует это и скорее фокусируется на предоставлении пользователю логического API для запроса информации о каталогах.
AppDomain.CurrentDomain
содержит информацию о текущем AppDomain
(грубо говоря, исполняемом файле). Часть этой информации логически относится к пути AppDomain
. Напротив, System.Reflection.Assembly
дает вам общую информацию о сборках - они представляют собой любые двоичные объекты в .NET, включая библиотеки DLL и EXE. GetExecutingAssembly
в частности возвращает текущую выполненную сборку. И вы можете получить свой путь снова, запросив его свойство Location
, которое дает физический путь файла сборки.