Как получить путь к файлу, чтобы всё работало и при разработке и при развёртывании?

Question

[Антон Барышев]

Здравствуйте. Пишу в учебных целях небольшое веб-приложение. Я создал отдельный слой для работы с данными, являющийся библиотекой. На момент разработки структура папок следующая:

В папке с конфигурацией хранится следующий файл JSON, его код будет десериализовываться в объект типа DatabaseConfiguration, чтобы потом удобно извлекать нужные данные:


Я столкнулся с одной проблемой. Мне нужно получать путь к этому файлу независимо от машины и от того, развёрнуто приложение или нет. Environment.CurrentDirectory выдаёт путь к исполняемому файлу, Directory.GetCurrentDirectory() выдаёт также путь к исполняемому файлу. Но мне то нужен как бы главный каталог приложения, где и находятся папки с конфигурацией, контекстами данных, моделями и прочим. Помогите. Расскажите, как его получить.
Заранее спасибо.
P.S. Если у вас есть предложения, как можно было бы улучшить систему конфигурации в слое данных, то рассказывайте.

Answer 1

[d-stream]

Почему бы и не плясать именно от расположения исполняемого файла?
Например ..\..\config

p.s. Только Environment.CurrentDirectory - штука несколько зыбкая, лучше Assembly.GetExecutingAssembly().Location

Comments

[Антон Барышев]

Вы предлагаете из строки пути к исполняемому файлу сделать нужный путь, я правильно понимаю?

[d-stream]

Антон Барышев, совершенно верно. По крайней мере это достаточно определенная (и более-менее гарантированная) точка отсчета от которой можно плясать.

Кстати достаточно распространенная практика - размещать неизменяемые в процессе работы конфиги рядом с исполняемым файлом исходит из этой же логики.

[Антон Барышев]

d-stream, а если у меня библиотека и конфиг находится там, это тоже сработает?

[d-stream]

А почему бы этому не сработать?

https://docs.microsoft.com/en-us/dotnet/framework/...

[Антон Барышев]

d-stream, спасибо большое, когда вернусь домой, обязательно попробую, потом отпишусь.

[Василий Банников]

Assembly.GetExecutingAssembly().Location

Тоже зыбко. Иногда может кидать исключения.
Рабочая директория - самый надёжный вариант

[d-stream]

Василий Банников,

using System;

namespace _
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine($"Current directory: {Environment.CurrentDirectory}");
            Console.ReadLine();
        }
    }
}

компилируем, создаем ярлык и е свойствах ярлыка пишем любую директорию... потом запускаем приложение по ярлыку и напрямую)

Поэтому GetExecutingAssembly() все-таки несколько понадежнее. Хотя да, под некоторыми обфускаторами и протекторами будут проблемы. Так же как и в случаях с хитростями подгрузки...
Местами может помочь Environment.CommandLine, но тоже с нюансами

[cicatrix]

Василий Банников, Далеко не всегда текущая директория будет совпадать с путём к исполняемому файлу.
Для винды есть реестр и установщик, в принципе, но для развёртывания на хостинге это не подойдёт.
Ещё есть вариант с Server.MapPath

[Василий Банников]

cicatrix,

Далеко не всегда текущая директория будет совпадать с путём к исполняемому файлу.

А действительно ли нужен именно путь к исполняемому файлу?

Просто я хз, но за три года такое так и не понадобилось - серверные приложения просто запускаются с рабочей директорией, чтобы все конфиги нормально читались.
Во время разработки - dotnet run запускает всё с рабочей директорией в папке с проектом, что тоже удобно, тк можно на лету менять конфиги.

Если очень нужно - можно всего одной командой, не трогая файлы менять конфиги.

И код не упадёт с исключением, если вдруг собрал Single File Executable

Ещё есть вариант с Server.MapPath

Это случайно не для старого asp net, который на IIS?

Для консольных и десктопных приложений существуют общеизвестные пути для хранения конфигов, по тому не надо вообще относительно пути использовать

[Василий Банников]

d-stream, >ярлык
Но это же явно не случай для сервера.
И не случай для десктопа, тк выше описал.
Проблема явно надуманная, и в принципе путь к сборке не для этого придуман был

[cicatrix]

Василий Банников,

А действительно ли нужен именно путь к исполняемому файлу?

Это, по факту, единственная более-менее надёжная точка отсчёта. Остальные варианты - только допущения, которые никто не гарантирует.

[Василий Банников]

cicatrix, самая надёжная точка отсчёта - это корень файловой системы и явные параметры конфигурации, которые указываются при запуске

Путь к запущеной сборке точно также не гарантирует, что ничего не упадёт, или что путь к ней действительно будет совпадать с путём к исполняемому файлу.

Ну и опять же - назови хоть одну задачу, где на самом деле нужно получить путь к запущенной сборке, а не путь к папке с конфигом или к папке, куда установлено приложение.

[Василий Банников]

d-stream,

Кстати достаточно распространенная практика - размещать неизменяемые в процессе работы конфиги рядом с исполняемым файлом исходит из этой же логики.

Если конфиги не меняются, то располагать их надо в ресурсах или в коде.

Любой другой конфиг считается изменяемым, и его стоит хранить в локальной папке пользователя, либо рядом с данными, с которыми происхоидт работа, либо давать внешний контроль над путём к конфигу.

[cicatrix]

Василий Банников,

назови хоть одну задачу, где на самом деле нужно получить путь к запущенной сборке, а не путь к папке с конфигом или к папке, куда установлено приложение.

В моей философии это один и тот же путь.

[Василий Банников]

cicatrix, это просто совпадение, что это один и тот же.
Может вы ещё и switch вместо if для bool используете?

[d-stream]

Василий Банников,

Проблема явно надуманная, и в принципе путь к сборке не для этого придуман был

Путь к сборке, рабочая директория - это суть разные понятия.
Наглядно можно поэкспериментировать с cd %windir% и потом dotnet d:\....путьдодлл\test.dll

Ну а ярлыки - это стандартная практика windows. Когда на компьютере больше одной учетной записи и они без админских прав - вполне разумно размещение исполняемых файлов в Program Files, а вот рабочие директории - в доступном юзеру пространстве %AppData%

Василий Банников,

Если конфиги не меняются, то располагать их надо в ресурсах или в коде.

В энтерпрайз среде распространенное явление когда конфиги не меняются (недоступны для изменения) пользователем, но естественно доступны и управляемы администраторами.
Поэтому конфиги в том числе и разделяются на несколько уровней начиная от вендорских настроек (например в ресурсах, но это не всегда удобно), административных в рамках предприятия (readonly для юзера) и заканчивая юзерскими. Естественно это разные конфиги, которые могут по содержанию не иметь полного пересечения между собой.

Answer 2

[Василий Банников]

Нормальная практика работы с конфигами в aspnet core:
1. Никаких конфигов в библиотеках. Классы, которые нужно конфигурировать, должны принимать некоторые типизированные параметры в конструкторе.
2. В ConfigureServices читаешь IConfiguration и прокидываешь из него параметры в библиотечный класс
3. Конфигурируемые значения хранишь в appsettings.json/переменных среды/etc в проекте веб-приложения.

Comments

[Антон Барышев]

Василий Банников, большое спасибо. Раз это нормальная практика, перепишу немного код приложения, чтобы конфигурация располагалась в проекте WEB API.

[Василий Банников]

Антон Барышев, и точно не будет проблем с путями, которых боится d-stream

[Антон Барышев]

Василий Банников, я попробовал, действительно проще просто использовать конфигурацию самого веб-приложения для установки каких-либо настроек базы данных. Большое спасибо.

[d-stream]

Василий Банников, вообще-то я то их не боюсь, просто знаю много разных специфических моментов и даже использую их)

Answer 3

[Владимир Коротенко]

Используйте system.io.directory для получения пути к директории из полного пути. Да и в общем случае используйте appconfig.json и секции в нем.

Comments

[Антон Барышев]

Спасибо. Обязательно попробую.