Запуск ASP.NET Core из Visual Studio не запускается из папки сборки

Question

Когда вы запускаете проект ASP.NET Core из Visual Studio (2017), он предполагает, что рабочий каталог находится там, где находится исходный код, а не там, где на самом деле размещаются встроенные файлы.

Это означает, что когда я запускаю свой проект, он читает файл конфигурации из C:\Path\To\My\Project\appsettings.json, а не из C:\Path\To\My\Project\bin\Debug\appsettings.json.

Я вижу, что это тот случай, когда я отлаживаю этот код:

WebHost.CreateDefaultBuilder(args)
    .UseStartup<Startup>()
    .ConfigureAppConfiguration((context, config) => {
        config.SetBasePath(context.HostingEnvironment.ContentRootPath);
        config.AddJsonFile("appsettings.json", true, false);
    });

Где ContentRootPath указывает на папку проекта, а не на место размещения встроенных файлов.

Вероятно, я мог бы исправить это, установив Working Directory в Project Properties > Debug, но, поскольку мы также используем преобразования конфигурации (SlowCheetah), у каждого разработчика будет своя собственная конфигурация сборки для вывода отладки (bin\Debug[CustomConfiguration]), и изменение .csproj для одного разработчика нарушает его для всех остальных разработчиков.

Есть ли способ заставить ASP.NET Core читать файлы конфигурации из папки, в которую помещаются встроенные файлы, а не в папку проекта, без необходимости изменять Working Directory, но все же работать для нескольких «конфигураций сборки»?

Answer 1

Если я правильно понимаю проблему, у каждого разработчика есть своя папка вывода в зависимости от имени пользователя. Итак, если вы придумаете что-то вроде этого,

        var debug = string.Empty;
        #if DEBUG
            debug = "Debug";
        #else
            debug = "Release";
        #endif

        var userNameVariable = System.Environment.GetEnvironmentVariable("USER");
        debug += $"[{userNameVariable}]";

        var path = System.IO.Path.Combine(env.ContentRootPath, "bin", debug);
        var builder = new ConfigurationBuilder()
            .SetBasePath(path) //env.ContentRootPath
            .AddJsonFile("appsettings.json", optional: false, reloadOnChange: true)
            .AddEnvironmentVariables();

Я проверил это на Mac OS, и результат

/Users/johndoe/Documents/Temp/contentasp/bin/Debug[johndoe]

Другое решение.

В visual studio у вас есть сценарии до и после сборки. В Visual Studio вы можете получить OutputFolder и указать путь к переменной окружения в сценарии предварительной сборки. Например:

powershell.exe -ExecutionPolicy Bypass -File "$(ProjectDir)outputscript.ps1" -OutputFolder $(OutputPath)

А в скрипте powershell (outputscript.ps1)

Param(
    [Parameter(Mandatory = $true, Position = 1)]
        [string]$OutputFolder
)

$env:OutputFolder = $OutputFolder

И вы можете получить значение при запуске с

var outputFolder = System.Environment.GetEnvironmentVariable("OutputFolder");
var builder = new ConfigurationBuilder()
    .SetBasePath(outputFolder) //env.ContentRootPath

Answer 2

Файлы конфигурации считываются из того места, которое вы настраиваете через SetBasePath. Что происходит в режиме разработки, так это то, что при использовании WebHost.CreateDefaultBuilder он устанавливает BasePath в папку с исходным кодом, что логично для большинства случаев разработки.

Это на самом деле не работает из коробки для консольных приложений, например, поэтому я специально делаю то же самое там.

Вероятно, есть несколько способов исправить это:

1. Использование существующей системы, так как она довольно удобна по умолчанию. Возможно, вы можете объяснить более подробно, почему у вас это не работает?

2. Не используя CreateDefaultBuilder и создавая компоновщик самостоятельно, вы сможете настроить его именно так, как вам нужно.

3. Переопределите SetBasePath требуемым значением. Я предполагаю, что, например, AppContext.BaseDirectory или Directory.GetCurrentDirectory() вернет искомый путь

4. Использование имени «Разработка» для вашей среды, вероятно, также поможет, хотя у вас будут и другие последствия, которые вам необходимо учитывать.

P.S. Зачем вам вообще использовать slowcheeta для преобразования в старом стиле, когда вы можете использовать agile config? Вы можете прочитать конфигурацию из нескольких файлов, и последний по порядку всегда побеждает, так что это будет тот же эффект, что и при использовании slowcheetah на практике.

Answer 3

Может быть, это поможет установить каталог как рабочий каталог приложения:

Directory.SetCurrentDirectory(context.HostingEnvironment.ContentRootPath);