Не только appsettings.json — практика конфигурации бизнес-приложений Windows (среды, секреты, куда писать)

«Нужно менять строку подключения по средам». «Хочу сохранять персональные настройки отображения». «API-ключ уже лежит в appsettings.json». Управление конфигурацией бизнес-приложений Windows почти всегда доходит до одного appsettings.json и чтения через IConfiguration. Дальше — настройки по средам, куда класть то, что приложение само записывает, как хранить секреты, как менять конфигурацию на ходу — часто уезжает в эксплуатацию так и не разобранным.

В статье идём по тем решениям, в которых на практике обычно путаются: от основы системы конфигурации .NET — IConfiguration и наложения поставщиков — к настройкам по средам, к типобезопасному получению через шаблон Options, к месту для записываемых настроек, к секретам, к реальным пределам изменения на ходу и к карте миграции с app.config/Settings.settings.

Глав восемь, текст длинный, поэтому сначала — как читать под задачу.

1. Сначала выводы

Управление конфигурацией начинается с того, что для каждого вида настроек выбирают место. Сначала — общая таблица решений.

Выводы с опорой на эту таблицу.

• Приоритет конфигурации подчиняется одному правилу: побеждает поставщик, которого добавили позже. По умолчанию источники читаются в порядке appsettings.json → appsettings.{Environment}.json → user secrets (только в development) → переменные окружения → аргументы командной строки. Если ключ есть в нескольких местах, действует значение, прочитанное позже. Одного этого порядка хватает, чтобы объяснить большую часть случаев «в JSON записал, а не применилось».¹
• Host.CreateApplicationBuilder собирает эту иерархию сам, вручную её складывать не нужно. Даже настольные приложения на Windows Forms/WPF получают те же значения по умолчанию, если берут Generic Host.²³
• Среду переключают через DOTNET_ENVIRONMENT (или ASPNETCORE_ENVIRONMENT). В приложениях на WebApplication приоритет у DOTNET_ENVIRONMENT; если не задано ни то, ни другое, по умолчанию будет Production. Для настольного приложения и службы Windows заранее решите, кто и как передаёт эту переменную процессу.⁴
• Настройки принимайте не как голый DTO, а как тип через семейство IOptions<T>. Если достаточно вычислить значение один раз при запуске — IOptions<T>; если изменение должно применяться без перезапуска — IOptionsMonitor<T>. Если мешать их без понимания разницы, получаются обе аварии: меняется то, что меняться не должно, и не меняется то, что должно.⁵
• Ошибку конфигурации ловите при запуске, а не во время работы. ValidateDataAnnotations() вместе с ValidateOnStart() превращает ошибку настроек в исключение сразу после старта — вместо NullReferenceException глубокой ночью в production.⁶
• Секреты в appsettings.json открытым текстом не кладите. В разработке — user-secrets, в production — DPAPI (ProtectedData) или Диспетчер учётных данных. В официальной документации прямо сказано: user-secrets не шифруются и предназначены только для разработки.⁷⁸

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 25, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Основа системы конфигурации .NET — IConfiguration и поставщики

Система конфигурации .NET выглядит как одно хранилище ключ–значение IConfiguration, а за ним накладываются несколько поставщиков конфигурации. Выгода в том, что источники разной природы — JSON, переменные окружения, аргументы командной строки, INI, XML, коллекции в памяти — сходятся за одним интерфейсом IConfiguration.⁹

Поставщики складываются по простому правилу: побеждает добавленный позже. Если один ключ есть у нескольких поставщиков, действует значение из последнего.¹

Host.CreateApplicationBuilder(args) по умолчанию собирает поставщиков в таком порядке (чем больше номер, тем выше приоритет, то есть источник добавлен позже).²

1. appsettings.json
2. appsettings.{Environment}.json
3. Secret Manager (только в development)
4. Переменные окружения
5. Аргументы командной строки

Этот порядок одинаков для консольного приложения, Worker Service и Windows Forms. Минимальный пример:

using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.Hosting;

HostApplicationBuilder builder = Host.CreateApplicationBuilder(args);

// По умолчанию уже загружены appsettings.json / appsettings.{Environment}.json /
// переменные окружения / аргументы командной строки в указанном выше приоритете
string? connectionString = builder.Configuration.GetConnectionString("Main");

using IHost host = builder.Build();
await host.RunAsync();

Даже настольное приложение на Windows Forms может брать тот же HostApplicationBuilder, если добавить пакет Microsoft.Extensions.Hosting. Как написано в статье «Что такое Generic Host», Generic Host — основа, которая сразу закрывает конфигурацию, DI и логирование; настольному приложению нет причин отказываться от системы конфигурации. Как встраивать это в приложение с фоновой работой, см. «Generic Host + BackgroundService в настольном приложении».

У переменных окружения есть оговорка. Параметры хоста (корень содержимого, имя среды и т. п.) читаются из переменных с префиксом DOTNET_, но этот префикс не используется для параметров приложения — обычных значений, которые читают через IConfiguration. Переменные, которые должны войти как параметры приложения, без префикса уже стоят в стандартном порядке через AddEnvironmentVariables().¹⁰ Если нужен свой префикс, добавьте его явно: builder.Configuration.AddEnvironmentVariables(prefix: "MyApp_").

using Microsoft.Extensions.Configuration;

// Добавляется после стандартных поставщиков, поэтому приоритет становится наивысшим
builder.Configuration.AddEnvironmentVariables(prefix: "MyApp_");

3. Настройки по средам — appsettings.{Environment}.json

Если строка подключения или эндпоинт должны отличаться по средам, берите файлы вроде appsettings.Development.json / appsettings.Staging.json / appsettings.Production.json. Важно, что эти файлы — не полная копия, а переопределение базового appsettings.json. Переписывать все пункты не нужно: достаточно значений, которые меняются от среды к среде.¹

Имя среды задают переменные DOTNET_ENVIRONMENT или ASPNETCORE_ENVIRONMENT. Если используется WebApplication, значение DOTNET_ENVIRONMENT важнее ASPNETCORE_ENVIRONMENT; если не задано ни то, ни другое, по умолчанию будет Production. В Windows имена переменных окружения не зависят от регистра, в Linux зависят, поэтому если смотрите в сторону контейнеров, безопаснее держать написание одинаковым.⁴

Здесь и всплывает проблема: для настольного приложения и службы Windows само «как передать переменную окружения» — отдельная задача. Механизмы вроде launchSettings.json в ASP.NET Core работают только в локальной разработке, поэтому для production переключение среды нужно готовить отдельно. Типичных способов три.

• Задать переменную на всю машину. Если сохранить её как setx DOTNET_ENVIRONMENT Production /M, её унаследует каждый процесс на этом компьютере. На одной машине с приложениями разных сред это не подходит.
• Передать переменную процессу запуска службы Windows. Служба стартует в контексте, отличном от интерактивного сеанса пользователя, поэтому пользовательские переменные окружения не наследуются. Об учётной записи запуска и изоляции сеансов см. «Как создавать службы Windows и как их сопровождать». На практике берут переменную уровня машины либо тонкий bat-файл-обёртку, который делает SET и затем запускает сам exe (содержимое bat ниже).
• Если запускаете через Планировщик заданий, надёжнее передать аргумент командной строки. Во вкладке «Действие» нет UI, чтобы задать переменные окружения напрямую, поэтому аргумент вроде --environment Production и чтение через AddCommandLine(args) даёт меньше сбоев. Особенности учётной записи запуска и типа входа у Планировщика заданий разобраны в «Задача Планировщика не запускается или завершается с кодом 0x1».

Второму способу хватает трёх строк в bat-обёртке.

@echo off
set DOTNET_ENVIRONMENT=Production
"%~dp0MyApp.Service.exe" %*

%~dp0 — каталог, где лежит сам bat (со слешем \ в конце), поэтому exe рядом запускается независимо от текущего рабочего каталога. set действует только на этот процесс и его дочерние, поэтому приложения других сред на той же машине друг другу не мешают. Но сам этот bat нельзя зарегистрировать службой через sc create. Службой может быть только exe, который отвечает на команды управления службами; если указать bat, при запуске будет таймаут (ошибка 1053). Этот приём работает, когда процесс стартует через обёртку службы или через Планировщик заданий, о котором ниже. Если хотите зарегистрировать саму службу как есть, берите переменную уровня машины или аргументы командной строки.

using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.Hosting;

var options = new HostApplicationBuilderSettings
{
    Args = args,
    // Для путей запуска, где переменная окружения не передаётся (Планировщик заданий и т. п.),
    // допускаем переключение среды и через аргументы командной строки
};
HostApplicationBuilder builder = Host.CreateApplicationBuilder(options);

Console.WriteLine($"Текущая среда: {builder.Environment.EnvironmentName}");

4. Шаблон Options — принимать настройки типом

Чтение по строковому ключу вроде IConfiguration["Key:SubKey"] слабо тем, что опечатку не поймаешь и при глубокой вложенности трудно следить за ключами. На практике базовый путь — шаблон Options: связать настройки с POCO и принимать их как тип.

public sealed class ExternalApiOptions
{
    public const string SectionName = "ExternalApi";

    public required string BaseUrl { get; set; }
    public required string ApiKey { get; set; }
    public int TimeoutSeconds { get; set; } = 30;
}

Регистрация и привязка выглядят так:

using Microsoft.Extensions.DependencyInjection;

builder.Services
    .AddOptions<ExternalApiOptions>()
    .Bind(builder.Configuration.GetSection(ExternalApiOptions.SectionName));

Для получения значений есть три интерфейса с разным поведением.⁵

В настольном приложении и службе Windows нет HTTP request scope, поэтому IOptionsSnapshot<T> ведёт себя по сути как IOptions<T>, пока вы сами не создаёте scope. Если нужно замечать изменения, берите IOptionsMonitor<T> — такое правило снимает большую часть сомнений.

Значения настроек (BaseUrl, ApiKey, тайм-аут) берите из IOptionsMonitor на каждый вызов, а сам HttpClient получайте через IHttpClientFactory и используйте повторно. Если на каждый вызов делать new и Dispose для HttpClient, внутренний пул сокетов и соединений каждый раз уничтожается и собирается заново; при частом опросе или пакетной обработке это ведёт к исчерпанию эфемерных портов. Поэтому значения могут меняться, а повторное использование соединений оставляют IHttpClientFactory.

using Microsoft.Extensions.Options;

public sealed class ExternalApiClient(
    IHttpClientFactory httpClientFactory,
    IOptionsMonitor<ExternalApiOptions> optionsMonitor)
{
    public async Task<string> FetchAsync(CancellationToken cancellationToken)
    {
        // На каждый вызов берём актуальное значение. Если файл настроек обновили — подхватится
        ExternalApiOptions current = optionsMonitor.CurrentValue;

        // Сам HttpClient берём через фабрику и переиспользуем внутренний пул соединений
        HttpClient client = httpClientFactory.CreateClient(nameof(ExternalApiClient));

        using var request = new HttpRequestMessage(HttpMethod.Get, new Uri(new Uri(current.BaseUrl), "status"));
        request.Headers.Add("X-Api-Key", current.ApiKey);

        using var timeoutCts = new CancellationTokenSource(TimeSpan.FromSeconds(current.TimeoutSeconds));
        using var linkedCts = CancellationTokenSource.CreateLinkedTokenSource(cancellationToken, timeoutCts.Token);

        using HttpResponseMessage response = await client.SendAsync(request, linkedCts.Token);
        response.EnsureSuccessStatusCode();
        return await response.Content.ReadAsStringAsync(cancellationToken);
    }
}

На вызывающей стороне зарегистрируйте именованный клиент: builder.Services.AddHttpClient(nameof(ExternalApiClient));. Значения вроде BaseUrl и ApiKey, которые могут смениться через конфигурацию, кладите в HttpRequestMessage на каждый запрос, а стоимость создания и освобождения экземпляра HttpClient оставляйте фабрике. В этом и состоит разделение ролей.

Если ошибка настроек всплывает исключением во время работы, расследование затягивается. Проверка DataAnnotations вместе с ValidateOnStart() позволяет спроектировать систему так, что приложение с сломанной конфигурацией просто не стартует.⁶

using System.ComponentModel.DataAnnotations;
using Microsoft.Extensions.DependencyInjection;

public sealed class ExternalApiOptions
{
    public const string SectionName = "ExternalApi";

    [Required, Url]
    public required string BaseUrl { get; set; }

    [Required, MinLength(16)]
    public required string ApiKey { get; set; }

    [Range(1, 300)]
    public int TimeoutSeconds { get; set; } = 30;
}

builder.Services
    .AddOptions<ExternalApiOptions>()
    .Bind(builder.Configuration.GetSection(ExternalApiOptions.SectionName))
    .ValidateDataAnnotations()
    .ValidateOnStart(); // Проверка идёт при запуске хоста (StartAsync/RunAsync), до старта hosted services

Без ValidateOnStart() проверка откладывается до первого фактического обращения к этим параметрам. Сама проверка выполняется не сразу после Build(), а при запуске хоста (StartAsync/RunAsync), поэтому в тестах, которые вызывают только Build() и ещё не вызывают RunAsync(), она в этот момент ещё не бежала. Чтобы не получить плавающий сбой «приложение стартовало, а упало в момент открытия экрана с этой настройкой», для настроек бизнес-приложения по умолчанию ставьте ValidateOnStart().⁶

5. Куда класть настройки, которые приложение само записывает

appsettings.json — место для «значений по умолчанию только для чтения», а не место для настроек, которые приложение перезаписывает само. Многие бизнес-приложения ставятся в Program Files, куда у обычного пользователя нет права записи, и тогда наступают на одну из двух проблем: исключение во время работы либо виртуализация файловой системы Windows, из-за которой видимое содержимое разъезжается между пользователями.

То, что нужно писать, разделяйте по характеру. Безопаснее опираться на специальные папки, которые возвращает Environment.GetFolderPath.¹¹

using System;
using System.IO;
using System.Text.Json;

public sealed class UserSettingsStore
{
    private readonly string _filePath;

    public UserSettingsStore()
    {
        string root = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData);
        string dir = Path.Combine(root, "YourCompany", "MyApp");
        Directory.CreateDirectory(dir);
        _filePath = Path.Combine(dir, "user-settings.json");
    }

    public UserSettings Load()
    {
        if (!File.Exists(_filePath))
        {
            return new UserSettings();
        }
        string json = File.ReadAllText(_filePath);
        return JsonSerializer.Deserialize<UserSettings>(json) ?? new UserSettings();
    }

    public void Save(UserSettings settings)
    {
        string json = JsonSerializer.Serialize(settings, new JsonSerializerOptions { WriteIndented = true });
        // Предполагается, что параллельную запись в рамках одного процесса сериализует вызывающий код
        File.WriteAllText(_filePath, json);
    }
}

public sealed class UserSettings
{
    public string? LastOpenedFolder { get; set; }
    public int WindowWidth { get; set; } = 1024;
    public int WindowHeight { get; set; } = 768;
}

Если смешать настройки пользователя и настройки машины в одном файле, на общей машине получите аварию вида «настройка пользователя A мешает пользователю B». О разделении «на пользователя / на машину» и о самой структуре профиля Windows см. «Как устроен профиль пользователя Windows»; общая таблица выбора места хранения — в «Как выбрать место хранения данных Windows-приложения».

6. Секреты — строки подключения и API-ключи

Писать пароль из строки подключения или API-ключ прямо в appsettings.json — практический риск, даже если файл в .gitignore. Открытый текст утекает через общую папку при распространении, через пересылку файла в поддержку, через забытый старый файл настроек, который остался в резервной копии.

В разработке берите Secret Manager (dotnet user-secrets). Но это механизм удобства разработки, и он не шифруется. Значения лежат открытым JSON в %APPDATA%\Microsoft\UserSecrets\<UserSecretsId>\secrets.json; официальная документация прямо говорит: «не считайте это доверенным хранилищем, только для разработки». Класть туда production-секреты и распространять их — ошибка.⁷

dotnet user-secrets init
dotnet user-secrets set "ExternalApi:ApiKey" "значение для разработки"

В production шифруйте значение через DPAPI (Data Protection API) Windows, привязав его к учётным данным пользователя или машины. Protect/Unprotect в System.Security.Cryptography.ProtectedData — обёртки над ним; с DataProtectionScope.CurrentUser расшифровать можно только под той же учётной записью и только на той же машине. Проектируйте с учётом того, что DPAPI — функция только для Windows: на других платформах будет PlatformNotSupportedException.⁸

using System.Security.Cryptography;
using System.Text;

public static class SecretProtector
{
    // Дополнительная энтропия по назначению снижает шанс перепутать данные, защищённые для другой цели
    private static readonly byte[] Entropy = Encoding.UTF8.GetBytes("MyApp.ExternalApi.ApiKey");

    public static string Protect(string plainText)
    {
        byte[] plainBytes = Encoding.UTF8.GetBytes(plainText);
        byte[] protectedBytes = ProtectedData.Protect(plainBytes, Entropy, DataProtectionScope.CurrentUser);
        return Convert.ToBase64String(protectedBytes);
    }

    public static string Unprotect(string protectedBase64)
    {
        byte[] protectedBytes = Convert.FromBase64String(protectedBase64);
        byte[] plainBytes = ProtectedData.Unprotect(protectedBytes, Entropy, DataProtectionScope.CurrentUser);
        return Encoding.UTF8.GetString(plainBytes);
    }
}

Коротко о роли энтропии (optionalEntropy) в коде выше. Область CurrentUser у DPAPI означает «расшифровать может тот же пользователь на той же машине», поэтому без энтропии расшифровать смогут и другие приложения, запущенные с правами того же пользователя. Если защищать с энтропией, при расшифровке нужно передать то же значение — это прямо сказано в официальной документации.⁸ То есть энтропия — пароль самого приложения: она мешает расшифровать данные другим программам того же пользователя на той же машине. Но этот пароль вшит в exe, поэтому защита такого уровня, который снимается разбором файла. Это не способ запретить расшифровку самому пользователю.

Где хранить значение после защиты DPAPI, какую область выбрать между CurrentUser и LocalMachine, какие ловушки ждут бизнес-приложение с несколькими пользователями на одной машине — это уже уровень реализации, подробно разобранный в «Хранение секретов в Windows-приложениях: как не оставлять настройки открытым текстом с DPAPI». При реализации смотрите туда.

Граница «можно открытым текстом / нельзя» простая. Смотрите, потребуется ли при утечке перевыпустить пароль или API-ключ, расследовать несанкционированный доступ или отчитываться перед надзорным органом. Имя узла или порт в строке подключения при утечке чаще дают небольшой реальный вред; встроенный пароль или токен аутентификации всегда нужно защищать. Если собирать строку подключения из «информации о сервере» и «учётных данных» и отдавать под DPAPI только второе, на уровне кода отделяется то, что в открытом виде относительно безвредно, от того, что нужно защищать.

7. Смена конфигурации на ходу — реальность reloadOnChange

Стандартный вызов AddJsonFile — тот, что внутри делает Host.CreateApplicationBuilder — задаёт reloadOnChange: true, поэтому appsettings.json / appsettings.{Environment}.json сами перечитываются, когда файл изменился. Внутри PhysicalFileProvider следит за изменениями через FileSystemWatcher.¹²

У механизма есть несколько практических пределов.

• Обновляются только значения, прочитанные через IOptionsMonitor<T> (и IOptionsSnapshot<T>). IOptions<T> держит значение старта, поэтому после правки файла остаётся старым. Большинство обращений «файл настроек правил напрямую, а не применилось» сводятся к путанице этих двух.
• FileSystemWatcher не всегда надёжно доставляет уведомления об изменении на таких файловых системах, как контейнер Docker или сетевая папка. В этих средах переменная окружения DOTNET_USE_POLLING_FILE_WATCHER со значением 1 или true переключает наблюдение на опрос раз в 4 секунды (интервал не меняется).¹³ Формулировку «4 секунды, интервал не настраивается» на момент написания (июль 2026) мы сверяли со страницей Microsoft Learn «Options pattern in .NET» (обновлена в октябре 2025). У документа нет привязки к версии, поэтому если кладёте это в долгоживущую архитектуру, сверьтесь с актуальной редакцией той же страницы. Типичные особенности самого FileSystemWatcher — пропуски, переполнение буфера, дубли событий — собраны в «Практическое руководство по FileSystemWatcher».
• На одно изменение файла настроек уведомление может прийти несколько раз. Если приложение при каждом срабатывании заново запускает тяжёлую работу, учитывайте это: делайте debounce частых срабатываний подряд или сравнивайте хеш содержимого файла и обрабатывайте только реальные изменения.

Не обязательно всегда целиться в «применить без перезапуска». Лёгкие значения вроде уровня журнала или feature flag можно сразу подхватывать через IOptionsMonitor. Строку подключения к БД или размер пула потоков — значения, которые в момент смены могут разъехаться с уже живыми ресурсами, — безопаснее явно описать в спецификации как «применяется после перезапуска». Важнее самого reloadOnChange спроектировать так, чтобы эксплуатация ясно слышала: «эта настройка действует сразу после сохранения», «эта требует перезапуска».

8. Карта миграции с app.config / Settings.settings

Когда приложение эпохи .NET Framework переносят на .NET, механизм конфигурации тоже нужно собрать заново. Сводим соответствия.¹⁴

На миграции часто наступают на две ловушки.

Первая: если добавить NuGet-пакет System.Configuration.ConfigurationManager, код чтения App.config продолжит работать без изменений. Как первый этап миграции это годится, но на нём нельзя останавливаться: перенос на appsettings.json нужно заложить в план. Сопутствующие библиотеки вроде logging provider почти везде уже ждут appsettings.json, поэтому держать старый механизм только ради чтения App.config становится всё менее оправданно.¹⁴

Вторая — настройки Settings.settings с областью пользователя. В .NET Framework вызов Properties.Settings.Default.Save() сам сохранял параметры на пользователя; в .NET аналогичной автогенерации из коробки нет. При миграции подготовьте свой класс сохранения, как в главе 5.

У миграции есть и другая сторона — совместимость зависимых библиотек, есть ли COM, пересмотр способа распространения и прочие проверки вне конфигурации. Такую инвентаризацию мы собрали в «Чек-лист перед миграцией с .NET Framework на .NET»; имеет смысл просмотреть его на ранней стадии проекта миграции.

Итоги

Управление конфигурацией .NET складывается из трёх механизмов: наложение поставщиков через IConfiguration, типобезопасное получение значений через семейство IOptions и переключение среды переменными окружения. До этого места большинство приложений пользуются системой одинаково. Специфика бизнес-приложений Windows начинается дальше: куда класть то, что приложение само записывает, как защищать секреты, насколько разрешать смену настроек на ходу и как свернуть наследие поколения app.config.

Сделайте шаг дальше состояния «всё записано в appsettings.json» и разделите место и способ обработки для каждого вида настроек. Если таблица решений в статье станет отправной точкой такой раскладки — хорошо. Инвентаризация конфигурации существующего приложения и выбор, как уходить с app.config, часто не дают лучшего ответа без реальных файлов настроек и среды развёртывания — если застряли, напишите нам.

Связанные статьи

• Что такое Generic Host
• Generic Host + BackgroundService в настольном приложении
• Задача Планировщика не запускается или завершается с кодом 0x1
• Как создавать службы Windows и как их сопровождать
• Как выбрать место хранения данных Windows-приложения
• Как устроен профиль пользователя Windows
• Хранение секретов в Windows-приложениях: как не оставлять настройки открытым текстом с DPAPI
• Практическое руководство по FileSystemWatcher
• Чек-лист перед миграцией с .NET Framework на .NET

Связанные области консультаций

KomuraSoft LLC консультирует по проектированию конфигурации бизнес-приложений Windows, по сопровождению настроек по средам и по стратегии миграции с существующего app.config.

• Разработка Windows-приложений
• Техническая консультация и ревью архитектуры
• Контакты

Справочные ссылки

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Можно ли класть appsettings.json в ту же папку, что и exe?

Если это значения по умолчанию только для чтения — да. Но если приложение ставится в Program Files, его нельзя проектировать так, чтобы оно само перезаписывало appsettings.json. У обычного пользователя нет права записи в Program Files: во время работы получите исключение либо виртуализация файловой системы Windows покажет разным пользователям разное содержимое. Всё, что нужно писать, вынесите в отдельный файл под %LOCALAPPDATA% или %ProgramData%.

Что должно побеждать: переменные окружения или appsettings.json?

Стандартный приоритет не меняйте: используйте встроенный порядок переопределения appsettings.json → appsettings.{Environment}.json → переменные окружения → аргументы командной строки. Если сомневаетесь, смотрите на характер значения. Значения по умолчанию, которые можно класть в артефакты сборки, — в appsettings.json; то, что меняется на целевом стенде или в контейнере, — в переменные окружения. Такое разделение потом не путает.

Как делить классы настроек?

Делите options-классы по функции или зоне ответственности. Строка подключения — ConnectionOptions, внешний API — ExternalApiOptions: не складывайте в один класс несвязанные настройки. Тогда и единица проверки и перечитывания для IOptionsSnapshot/IOptionsMonitor получается естественной, и проверка DataAnnotations замыкается на класс.

Стоит ли уходить с INI-файлов или реестра?

Если конфигурацию поднимаете заново, лучше свести её к appsettings.json + IConfiguration. В .NET есть и INI configuration provider, поэтому существующие INI можно продолжать читать и переносить постепенно. Реестр в стандартный набор поставщиков конфигурации .NET не входит. Если от реестра зависят старые активы, напишите мост только для чтения и постепенно переносите значения в appsettings.json.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.