Зачем использовать .NET Generic Host и BackgroundService в десктопных приложениях

Когда Windows-инструмент или фоновое приложение чуть подрастает, работы за пределами UI становится всё больше. Периодический опрос, наблюдение за файлами, переподключение, обработка очереди, инициализация при запуске, flush при выходе. Сначала хватает Form_Load, OnStartup и Task.Run, но если оставить так, скоро становится неясно, кто запускает, кто останавливает и кто смотрит на исключения.

Ещё до того, как спорить о записи async / await, полезно решить, кто владеет временем жизни этой работы. Здесь как раз помогают Generic Host и BackgroundService в .NET.

Про async / await на стороне потока UI речь идёт в статьях WPF и WinForms: async/await и поток UI и Практическая таблица решений для C# async/await — Task.Run и ConfigureAwait. Здесь мы берём слой снаружи: как собрать запуск и остановку всего приложения.

На практике обычно разъезжается вот это.

• из форм и ViewModel то тут, то там появляется Task.Run;
• условия остановки фоновых циклов размазаны по bool-флагам;
• к моменту выхода ещё что-то работает, и окно иногда не закрывается до конца;
• логи / конфигурация / DI входят каждый через свою дверь;
• хочется оборвать всё через Environment.Exit, и блоки finally не выполняются.

Статья исходит в основном из WPF / WinForms / фоновых Windows-приложений на .NET 6 и новее и разбирает, почему Generic Host / BackgroundService незаметно, но дают эффект, насколько далеко их стоит заводить и где небрежность потом дорого обходится.

Читатель, которого мы имеем в виду, — не столько тот, кто уже знает BackgroundService, сколько тот, кто ещё не решил, куда класть фоновую работу и как вести её время жизни. Если имя встречается впервые, в следующей главе сначала зафиксируем термины. Если вы уже этим пользуетесь, можно начинать с таблицы в 2.2 и с разделения в главе 6.

flowchart TB
    accTitle: Как понемногу разъезжается устройство
    accDescr: Разрозненные Task.Run, остановка через bool-флаги, незавершённое закрытие и разные точки входа у каждой технологии сводятся к одному — неясно, кто запускает, кто останавливает и кто смотрит на исключения.
    s1["Разрозненные Task.Run"] --> core["Неясно, кто владеет временем жизни"]
    s2["Остановка через bool-флаги"] --> core
    s3["Незавершённое закрытие"] --> core
    s4["Разные точки входа"] --> core
    core --> fix["Сначала решить, кто владеет временем жизни"]

Рис. 1: Формы разъезда разные, корень один — не решено, кто владеет временем жизни работы.

Код из статьи опубликован на GitHub как полный набор, который можно собрать и запустить: библиотека, консольная демонстрация от запуска до graceful shutdown и модульные тесты.

generic-host-backgroundservice-desktop-app - komurasoft-blog-samples (GitHub)

Сначала договоримся о терминах

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

• Generic Host
  • Основа, которая берёт на себя «запуск», «зависимости», «конфигурацию», «логирование» и «остановку» .NET-приложения.
  • Это не механизм только для ASP.NET Core: его можно использовать в консоли, worker и десктопных приложениях.
• Host / IHost
  • Уже собранный объект после Build.
  • Его запускают через StartAsync и останавливают через StopAsync.
• Hosted Service
  • Фоновая работа, которая стартует и останавливается вместе с host.
  • Её пишут, реализуя IHostedService, или, как правило, наследуя BackgroundService.
• BackgroundService
  • Удобная вспомогательная реализация IHostedService.
  • Долгое тело можно положить в ExecuteAsync, и циклы мониторинга и периодическую работу проще упорядочить.
• lifetime
  • В этой статье это значит «когда работа начинается, когда заканчивается и кто отвечает за остановку».
  • Это не просто продолжительность существования, а управление временем жизни, включая ответственность за запуск и остановку.
• graceful shutdown
  • Не принудительное завершение, а сигнал остановиться и выход после того, как текущая работа по возможности приведена в порядок.
  • Сюда входит, например, «не начинать следующий цикл», «решить, до какого места прогнать очередь», «дождаться close и flush».
• DI
  • Сокращение от Dependency Injection: зависимости не собирают вручную в месте вызова, а получают через контейнер.
  • Для этой статьи достаточно картины «logger, конфигурацию и reader не разбрасывать через new, а собрать на входе».

Статью проще читать не как «представление удобного класса BackgroundService», а как разговор о том, как собрать запуск и остановку всего приложения в host и держать время жизни фоновой работы как проектное решение.

flowchart TB
    accTitle: Связь терминов в этой статье
    accDescr: Generic Host — основа для запуска, зависимостей, конфигурации, логов и остановки; результат Build — IHost; к его времени жизни подвешен Hosted Service, а BackgroundService — удобная вспомогательная реализация.
    gh["Generic Host (основа)"] --> ihost["IHost (результат Build)"]
    ihost --> hs["Hosted Service"]
    hs --> bs["BackgroundService"]
    bs --> exec["Долгое тело — в ExecuteAsync"]
    hs -.-> lt["lifetime = запуск и остановка"]

Рис. 2: Иерархия терминов. Hosted Service живёт вместе с host, BackgroundService — вспомогательная реализация.

Карта знаний этой статьи

Статья объясняет, зачем в десктопном приложении на WPF или WinForms использовать Generic Host и BackgroundService из .NET. Generic Host — это основа запуска, которая вместе берёт на себя внедрение зависимостей, логирование и остановку. BackgroundService — удобная реализация Hosted Service: резидентный цикл перестаёт быть fire-and-forget через Task.Run и живёт в управляемом жизненном цикле. Периодическая и упорядоченная обработка на PeriodicTimer или Channel получает сигнал остановки до StopAsync через CancellationToken, а верхнюю границу ожидания graceful shutdown задают через HostOptions.ShutdownTimeout. Если из-за фатальной ошибки нужно остановить всё приложение, штатный путь — IHostApplicationLifetime; принудительный выход через Environment.Exit этот путь обрезает.

flowchart LR
    accTitle: Карта знаний Generic Host и BackgroundService
    accDescr: Схема, в которой десктопное приложение берёт Generic Host как основу запуска, BackgroundService как Hosted Service переводит резидентную обработку на управляемый graceful shutdown через CancellationToken и ShutdownTimeout, а Environment.Exit с этим путём несовместим.
    generic_host["Generic Host"]
    backgroundservice["BackgroundService"]
    hosted_service["Hosted Service (IHostedService)"]
    dependency_injection_dotnet["внедрение зависимостей (DI)"]
    wpf["WPF"]
    windows_forms["Windows Forms"]
    periodictimer["PeriodicTimer"]
    cancellationtoken_dotnet["CancellationToken (.NET)"]
    channel_t["Channel<T>"]
    graceful_shutdown["graceful shutdown"]
    shutdowntimeout_hostoption["HostOptions.ShutdownTimeout"]
    environment_exit["Environment.Exit"]
    ihostapplicationlifetime["IHostApplicationLifetime"]
    ihostedlifecycleservice["IHostedLifecycleService"]
    taskrun_dotnet["Task.Run"]
    dotnet[".NET (начиная с Core)"]
    backgroundservice -->|"реализует"| hosted_service
    generic_host -->|"использует"| hosted_service
    generic_host -->|"использует"| dependency_injection_dotnet
    wpf -.->|"использует"| generic_host
    windows_forms -.->|"использует"| generic_host
    backgroundservice -.->|"использует"| periodictimer
    backgroundservice -->|"использует"| cancellationtoken_dotnet
    backgroundservice -->|"использует"| channel_t
    backgroundservice -->|"использует"| dependency_injection_dotnet
    graceful_shutdown -->|"требует"| cancellationtoken_dotnet
    generic_host -->|"настраивается"| shutdowntimeout_hostoption
    environment_exit -->|"несовместимо с"| graceful_shutdown
    ihostapplicationlifetime -->|"рекомендуется для"| graceful_shutdown
    generic_host -.->|"использует"| ihostedlifecycleservice
    taskrun_dotnet -->|"не рекомендуется"| hosted_service
    backgroundservice -->|"требует"| dotnet
    generic_host -->|"требует"| dotnet

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

Содержание

1. Сначала вывод (коротко)
2. Сначала — одна сводка
   • 2.1. Общая картина
   • 2.2. Таблица, куда что класть
3. Почему это работает в десктопных приложениях
   • 3.1. Проще разделить ответственность UI и фоновой работы
   • 3.2. Запуск, остановку и исключения можно собрать в одной точке входа
   • 3.3. Graceful shutdown проще заложить в проект
   • 3.4. DI / логи / конфигурация собраны с самого начала
4. Где это особенно уместно
5. Минимальный пример (WPF)
6. Как разделять StartAsync / ExecuteAsync / StopAsync
   • 6.1. StartAsync
   • 6.2. ExecuteAsync
   • 6.3. StopAsync
   • 6.4. Замечание для .NET 10 и новее
7. Частые антипаттерны
8. Чек-лист для ревью
9. Краткая шпаргалка по выбору
10. Итог
11. Источники

1. Сначала вывод (коротко)

• Generic Host — сильный кандидат на основу запуска и управления временем жизни даже в десктопном приложении.
• BackgroundService — контейнер, в котором «долго живущая» работа идёт с управляемым временем жизни, а не через fire-and-forget Task.Run.
• На практике сильнее всего помогает то, что ответственность за запуск / остановку / наблюдение за исключениями / логи / DI / конфигурацию можно собрать в одном месте.
• Если StartAsync короткий, долгое тело лежит в ExecuteAsync, а уборка при выходе — в StopAsync, код заметно проще читать.
• Особенно хорошо ложится на фоновые приложения, приложения в трее, мониторинг оборудования, периодическую синхронизацию, упорядоченную постобработку и циклы переподключения.
• И наоборот, тащить в BackgroundService разовую работу по нажатию кнопки — тяжеловесно.
• StopAsync удобен, но это не страховка от падения процесса и принудительного завершения. Важно также не сваливать туда всю уборку.

Иначе говоря, Generic Host / BackgroundService в десктопном приложении дают эффект не потому, что «есть фоновая работа», а потому что временем жизни этой фоновой работы хочется владеть как проектным решением, а не как побочным эффектом UI.

flowchart TB
    accTitle: Что собирается в одном месте
    accDescr: Ответственность за запуск, остановку, наблюдение за исключениями, логи, DI и конфигурацию — то, что обычно расползается, — можно собрать в одном проектном решении; на практике это даёт наибольший эффект.
    a["Ответственность за запуск"] --> one["Собрать в одном месте"]
    b["Ответственность за остановку"] --> one
    c["Наблюдение за исключениями"] --> one
    d["Логи, DI, конфигурация"] --> one
    one --> win["Управляемое время жизни"]

Рис. 3: Ценность BackgroundService в том, что разрозненную ответственность можно собрать в одном месте.

2. Сначала — одна сводка

2.1. Общая картина

Если сначала посмотреть на эту схему, разговор идёт заметно быстрее.

flowchart LR
    accTitle: Общая картина от запуска host до graceful shutdown
    accDescr: Десктопное приложение собирает и запускает Host, готовит DI, логи и конфигурацию, стартует HostedService и ExecuteAsync с PeriodicTimer, очередью, переподключением и циклом мониторинга, показывает UI и при выходе идёт в StopAsync с CancellationToken, close, flush и graceful shutdown.
    A["Запуск десктопного приложения<br/>(WPF / WinForms)"] --> B["Build / StartAsync для Host"]
    B --> C["Подготовка DI / Logging / Configuration"]
    B --> D["HostedService.StartAsync"]
    D --> E["BackgroundService.ExecuteAsync"]
    E --> F["PeriodicTimer / очередь / переподключение / цикл мониторинга"]

    C --> G["Показать MainWindow / MainForm"]
    F --> H["Обновление состояния / логи / внешний ввод-вывод"]
    H --> I["UI вызывает Dispatcher / Invoke только там, где нужно"]

    J["Выход пользователя / фатальная ошибка / StopApplication"] --> K["IHost.StopAsync"]
    K --> L["Уведомление через CancellationToken"]
    L --> M["HostedService.StopAsync"]
    M --> N["Закрытие соединений / flush / graceful shutdown"]

Рис. 4: Общая картина от запуска host до показа UI, фонового цикла, сигнала остановки и graceful shutdown.

Для тех, у кого схема не отображается, тот же поток словами.

1. Запуск приложения (в WPF — App.OnStartup, в WinForms — Main)
2. Регистрация сервисов через Host.CreateApplicationBuilder и Build
3. Запуск host через IHost.StartAsync (здесь фиксируются DI / логи / конфигурация)
4. Вызывается HostedService.StartAsync у зарегистрированных сервисов
5. Стартует BackgroundService.ExecuteAsync (тело: цикл мониторинга, PeriodicTimer, обработка очереди)
6. Показывается UI (MainWindow / MainForm). Worker обновляет хранилище состояния и логи, UI читает это в своём контексте
7. По действию пользователя или фатальной ошибке вызывается IHostApplicationLifetime.StopApplication, дальше идёт IHost.StopAsync
8. Остановка приходит как CancellationToken (stoppingToken), цикл в ExecuteAsync выходит
9. В HostedService.StopAsync закрывают соединения и делают flush логов, затем выход

В UI-приложении типичная картина — ответственность понемногу расползается по Program.cs / App.xaml.cs / Form_Load / Closing / Task.Run / Timer / статическим синглтонам.

Если ввести Host, обязанности можно грубо разрезать так.

• UI: экраны, ввод, отображение
• HostedService / BackgroundService: фоновая работа, мониторинг, очереди, периодические задачи
• DI-сервисы: собственно бизнес-логика, внешние подключения, конфигурация, логи

Уже одно такое разделение заметно меняет удобство ревью.

flowchart TB
    accTitle: Три доли ответственности после введения host
    accDescr: UI отвечает за экран, ввод и отображение; HostedService и BackgroundService — за фон, мониторинг, очереди и периодические задачи; DI-сервисы — за бизнес-логику, внешние подключения, конфигурацию и логи.
    app["Десктопное приложение"] --> ui["UI: экран, ввод, отображение"]
    app --> hs["HostedService: фон и мониторинг"]
    app --> di["DI-сервисы: бизнес-логика"]
    hs -.-> note["Очереди и периодические задачи тоже здесь"]

Рис. 5: От расползшейся ответственности — к трём долям: UI, фон, собственно работа.

2.2. Таблица, куда что класть

Ценность Host не в том, что что-то «можно сделать асинхронным», а в том, что становится ясно, куда это класть.

3. Почему это работает в десктопных приложениях

3.1. Проще разделить ответственность UI и фоновой работы

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

Например:

• синхронизация состояния каждые 10 секунд;
• переподключение к оборудованию или серверу;
• наблюдение за файлами и приём;
• постобработка из очереди;
• пересылка логов и отправка метрик;
• прогрев кэша при запуске.

Это не «события экрана», а работа, которая живёт вместе со всем приложением.

Если поселить её в code-behind формы или окна, ответственность за остановку при закрытии экрана, за перехват исключений и за решения о повторных попытках и backoff начинает смешиваться с заботами UI.

С BackgroundService формула «эта работа живёт всё время, пока работает приложение» видна в самом коде. Это выглядит скромно, но сильно помогает.

flowchart TB
    accTitle: Куда поселить фоновую работу
    accDescr: Если фоновую работу поселить в code-behind, ответственность за остановку, исключения и повторные попытки смешивается с UI; если положить в BackgroundService, в коде видно, что работа живёт всё время работы приложения.
    q{"Куда поселить фоновую работу"}
    q -->|"Code-behind"| mix["Остановка, исключения и retry смешиваются с UI"]
    q -->|"BackgroundService"| decl["«Живёт всё время работы» видно в коде"]

Рис. 6: Одна и та же работа — разное смешение ответственности, в зависимости от того, куда её поселить.

3.2. Запуск, остановку и исключения можно собрать в одной точке входа

Даже в десктопном приложении без Host похожего эффекта можно добиться, расставив по отдельности ServiceCollection, ConfigurationBuilder и LoggerFactory.

Но такая форма обычно понемногу расползается.

• DI — в Program.cs
• конфигурация — в своём static
• логи — в отдельной фабрике
• завершение — в ApplicationExit
• фоновая работа — в Task.Run

Так сначала всё работает. Но через несколько месяцев уже трудно увидеть, кто владеет временем жизни приложения.

С Generic Host

• регистрация сервисов,
• чтение конфигурации,
• настройка логов,
• запуск hosted service,
• сигнал остановки,
• остановка всего приложения через IHostApplicationLifetime

входят в одну рамку.

Иначе говоря, точку входа для вопроса «как это приложение запускается и как останавливается» проще собрать в одном месте. В фоновых приложениях это потом окупается.

flowchart TB
    accTitle: Собрать разрозненные точки входа в host
    accDescr: От формы, где DI, конфигурация, логи, завершение и фон живут в разных местах, к форме, где регистрация, чтение конфигурации, логи, запуск hosted service, сигнал остановки и остановка всего приложения входят в одну рамку.
    before["Точки входа разбросаны"] --> pain["Неясно, кто владеет временем жизни"]
    host["Собрать в Generic Host"] --> one["Запуск и остановка в одном месте"]
    one -.-> items["Регистрация, конфигурация, логи, остановка"]

Рис. 7: По отдельности тоже работает, но через несколько месяцев важнее, входят ли они в одну рамку.

3.3. Graceful shutdown проще заложить в проект

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

Например, при завершении хочется:

• отменить текущий ввод-вывод;
• не начинать следующий цикл;
• решить, до какого места прогнать остаток очереди;
• закрыть сокеты и COM-объекты;
• дождаться flush логов и сохранения состояния.

Если свалить это в FormClosing, оно смешается с заботами экрана, и станет тяжело.

С Host / BackgroundService есть CancellationToken и StopAsync, поэтому маршрут остановки существует с самого начала.

Это не волшебство. При сбое или kill StopAsync иногда не вызывается. Но уже само наличие проекта «при штатном выходе останавливаемся по этому маршруту» заметно всё успокаивает.

flowchart TB
    accTitle: Маршрут остановки
    accDescr: При завершении нужны отмена текущего ввода-вывода, остановка следующего цикла, решение по остатку очереди и ожидание close и flush; с самого начала есть маршрут остановки через CancellationToken и StopAsync.
    stopreq["Сигнал остановки"] --> token["Уведомление через CancellationToken"]
    token --> loop["Не начинать следующий цикл"]
    token --> io["Отменить текущий ввод-вывод"]
    stopreq --> sa["close и flush в StopAsync"]
    sa -.-> limit["При сбое или kill путь не сработает"]

Рис. 8: Фоновую работу сложнее остановить, чем начать, поэтому маршрут остановки с самого начала даёт эффект.

3.4. DI / логи / конфигурация собраны с самого начала

Достоинство Generic Host не сводится к одному BackgroundService.

• Host.CreateApplicationBuilder сразу собирает основу для DI / конфигурации / логов
• appsettings.json и переменные окружения удобно использовать как есть
• ILogger<T> можно вести в одном стиле и в UI, и в worker
• при необходимости конфигурацию собирают через семейство IOptions<T>

Особенно в Windows-инструментах часто бывает так: «сначала приложение было маленьким, конфигурацию и logger держали кое-как в static, а потом это стало мучением».

Если с самого начала положить это на host, приложение меньше задыхается, когда чуть толстеет.

4. Где это особенно уместно

Generic Host / BackgroundService особенно хорошо работают в таких случаях.

• Фоновые приложения в трее Есть периодическая синхронизация, мониторинг, уведомления, переподключение
• Приложения с подключением к оборудованию / камерам / сокетам Есть удержание соединения, мониторинг, повторные попытки, опрос состояния
• Инструменты интеграции через файлы Есть наблюдение, очередь приёма, упорядоченная обработка
• Профилактика разрастания внутренних инструментов Сейчас маленькое, но конфигурация, логи и внешний ввод-вывод, похоже, вырастут
• Приложения, где важно качество завершения Не хочется оставлять недоделанное состояние при закрытии

И наоборот, есть случаи, когда сразу вводить host не обязательно.

• маленький инструмент, который запускается один раз, делает одну работу и выходит;
• экран почти без фоновой работы, который полностью закрывается событиями UI;
• по-настоящему маленький внутренний вспомогательный инструмент, у которого зависимости и конфигурация едва ли вырастут.

Host — не «обязательное требование». Но как только видно две и более фоновые задачи, его вполне стоит рассматривать всерьёз. Это заметно дешевле, чем потом разгребать разросшиеся Task.Run.

flowchart TB
    accTitle: Ориентир, вводить ли host
    accDescr: Как только видно две и более фоновые задачи, host стоит рассматривать всерьёз; для разового маленького инструмента или экрана, который закрывается событиями UI, сразу вводить не обязательно.
    q{"Видно две и более фоновые задачи?"}
    q -->|"Да"| yes["Имеет смысл рассмотреть host"]
    q -->|"Нет"| no["Сразу вводить не обязательно"]
    yes -.-> why["Дешевле, чем потом разгребать Task.Run"]

Рис. 9: Host не обязателен, но вводить его, когда фон начинает расти, дешевле, чем потом убирать.

5. Минимальный пример (WPF)

В качестве примера — минимальная сборка: в WPF запускается host и работает BackgroundService, который каждые 5 секунд читает внешнее состояние. В WinForms точка входа меняется на Main / ApplicationContext, но подход почти тот же.

Код разложен на три файла, поэтому сначала состав.

Образец на GitHub — та же сборка, запущенная как консоль: реализация BackgroundService и StatusStore, демонстрация от запуска до graceful shutdown и модульные тесты.

5.1. App.xaml.cs

using System.Windows;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

namespace DesktopHostSample;

public partial class App : Application
{
    private IHost? _host;

    protected override async void OnStartup(StartupEventArgs e)
    {
        base.OnStartup(e);

        HostApplicationBuilder builder = Host.CreateApplicationBuilder(e.Args);

        builder.Services.Configure<HostOptions>(options =>
        {
            options.ShutdownTimeout = TimeSpan.FromSeconds(15);
        });

        builder.Services.AddSingleton<MainWindow>();
        builder.Services.AddSingleton<StatusStore>();
        builder.Services.AddScoped<IDeviceStatusReader, DeviceStatusReader>();
        builder.Services.AddHostedService<DevicePollingBackgroundService>();

        _host = builder.Build();

        await _host.StartAsync();

        MainWindow mainWindow = _host.Services.GetRequiredService<MainWindow>();
        mainWindow.Show();
    }

    protected override async void OnExit(ExitEventArgs e)
    {
        if (_host is not null)
        {
            await _host.StopAsync();
            _host.Dispose();
        }

        base.OnExit(e);
    }
}

В этой форме важны три вещи.

1. Host запускают до показа UI
2. При выходе явно ждут StopAsync через await
3. DI / hosted service / тайм-аут завершения собирают на входе

ShutdownTimeout — это верхняя граница, сколько IHost.StopAsync ждёт завершающую работу. Значение по умолчанию зависит от версии: в .NET 6 это 5 секунд, начиная с .NET 7 — 30 секунд. Здесь стоит 15 секунд, потому что верхнюю границу задают сами, ориентируясь на самое медленное завершение. Ориентир — «тайм-аут текущего ввода-вывода + время на close / flush» плюс небольшой запас. Если слишком коротко, flush оборвётся на середине; если слишком долго, приложение выглядит как «не закрывается». Поэтому значение по умолчанию лучше не оставлять как есть, а один раз решить — так меньше аварий.

flowchart TB
    accTitle: Как задавать ShutdownTimeout
    accDescr: Верхнюю границу ожидания завершения не оставляют по умолчанию, а задают сами, ориентируясь на самое медленное завершение. Слишком коротко — flush оборвётся; слишком долго — кажется, что приложение не закрывается.
    base["Самое медленное завершение"] --> calc["Таймаут I/O плюс время flush"]
    calc --> setv["Задать верхнюю границу самим"]
    setv -.-> short["Слишком коротко: flush обрежется"]
    setv -.-> longw["Слишком долго: кажется, что не закрывается"]

Рис. 10: ShutdownTimeout не оставляют по умолчанию: верхнюю границу считают от самого медленного завершения.

Сделать OnExit async само по себе требует аккуратности из-за UI-фреймворка, но явно описать поток «при выходе остановить host» стоит того.

5.2. BackgroundService

using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;

namespace DesktopHostSample;

public sealed class DevicePollingBackgroundService(
    IServiceScopeFactory scopeFactory,
    StatusStore statusStore,
    ILogger<DevicePollingBackgroundService> logger) : BackgroundService
{
    public override async Task StartAsync(CancellationToken cancellationToken)
    {
        logger.LogInformation("Device polling service is starting.");
        await base.StartAsync(cancellationToken);
    }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        logger.LogInformation("Device polling loop started.");

        using var timer = new PeriodicTimer(TimeSpan.FromSeconds(5));

        while (await timer.WaitForNextTickAsync(stoppingToken))
        {
            try
            {
                using IServiceScope scope = scopeFactory.CreateScope();
                IDeviceStatusReader reader =
                    scope.ServiceProvider.GetRequiredService<IDeviceStatusReader>();

                DeviceStatus status = await reader.ReadAsync(stoppingToken);
                statusStore.Update(status);
            }
            catch (OperationCanceledException) when (stoppingToken.IsCancellationRequested)
            {
                break;
            }
            catch (Exception ex)
            {
                logger.LogError(ex, "Device polling failed.");
            }
        }

        logger.LogInformation("Device polling loop finished.");
    }

    public override async Task StopAsync(CancellationToken cancellationToken)
    {
        logger.LogInformation("Device polling service is stopping.");
        await base.StopAsync(cancellationToken);
        logger.LogInformation("Device polling service stopped.");
    }
}

Здесь важно писать ExecuteAsync просто, как «управляемый цикл while».

• период — PeriodicTimer;
• остановка — stoppingToken;
• исключения — в лог;
• если нужны scoped-зависимости, на каждой итерации открывают свой scope.

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

flowchart TB
    accTitle: Форма управляемого цикла while
    accDescr: Ждут тик PeriodicTimer, на каждой итерации открывают scope, читают состояние, обновляют store, при сбое пишут исключение в лог и продолжают, при отмене stoppingToken выходят из цикла.
    tick["Ожидание тика PeriodicTimer"] --> scope["Создать scope и взять зависимость"]
    scope --> read["Прочитать состояние и обновить store"]
    read --> tick
    read -.->|"Сбой"| logx["Записать исключение и продолжить"]
    tick -.->|"stoppingToken"| exitx["Выйти из цикла и завершиться"]

Рис. 11: ExecuteAsync — «управляемый цикл while». Период, остановка, исключения и scope читаются в одном месте.

5.3. Общее состояние не привязывать напрямую к UI

Если worker напрямую трогает объекты UI, проблема потока UI просто снова возникает там же.

Поэтому безопаснее сначала разделить так:

• worker обновляет хранилище состояния или слой сообщений;
• UI в своём контексте читает это состояние и применяет его к экрану.

StatusStore, например, можно оставить тонким общим слоем.

namespace DesktopHostSample;

public sealed class StatusStore
{
    private readonly object _gate = new();
    private DeviceStatus _current = DeviceStatus.Empty;

    public DeviceStatus Current
    {
        get
        {
            lock (_gate)
            {
                return _current;
            }
        }
    }

    public void Update(DeviceStatus next)
    {
        lock (_gate)
        {
            _current = next;
        }
    }
}

public sealed record DeviceStatus(string Message)
{
    public static readonly DeviceStatus Empty = new("No Data");
}

Если нужно немедленное уведомление UI, берут Dispatcher / BeginInvoke / события / messenger. Но эту ответственность лучше держать на границе UI — так меньше смешения.

flowchart TB
    accTitle: Общее состояние без прямой привязки к UI
    accDescr: Worker не трогает объекты UI напрямую, а обновляет хранилище состояния или слой сообщений; UI в своём контексте читает это состояние и применяет его. Немедленное уведомление остаётся ответственностью границы UI.
    worker["worker (фоновый цикл)"] --> store["Обновить хранилище состояния"]
    ui["UI"] --> readq["Читать в своём контексте"]
    store --> readq
    readq -.-> notify["Немедленное уведомление — на границе UI"]

Рис. 12: Тонкий общий слой между worker и UI не даёт снова всплыть проблеме потока UI.

6. Как разделять StartAsync / ExecuteAsync / StopAsync

Когда эти три метода смешиваются, у читателя в голове быстро мутнеет. Для начала довольно устойчиво такое разделение.

6.1. StartAsync

StartAsync — место для короткой работы, которая участвует в запуске.

Подходит:

• лог запуска;
• лёгкое начало подписки;
• быстрая подготовка начального состояния;
• минимальное упорядочивание вокруг base.StartAsync.

Не подходит:

• прогрев на десятки секунд;
• бесконечные циклы;
• тело с плотным тяжёлым вводом-выводом.

Если утяжелить StartAsync, весь старт приложения выглядит вялым. Здесь лучше думать «место для сигнала о начале» — так меньше аварий.

flowchart TB
    accTitle: Что класть в StartAsync
    accDescr: Короткая работа, которая участвует в запуске, вроде лога запуска или лёгкой подписки, подходит для StartAsync; длинный прогрев, бесконечный цикл или тяжёлый ввод-вывод замедляют старт всего приложения.
    q{"Короткая работа, участвующая в запуске?"}
    q -->|"Да"| ok["Класть в StartAsync"]
    q -->|"Нет"| ng["В ExecuteAsync или тело сервиса"]
    ng -.-> why["Тяжёлое замедляет старт приложения"]

Рис. 13: StartAsync — место для сигнала о начале, а не для тяжёлой работы.

6.2. ExecuteAsync

ExecuteAsync — это тело времени жизни сервиса.

Подходит:

• опрос;
• циклы мониторинга;
• циклы переподключения;
• потребители, читающие Channel<T>;
• периодическая работа;
• вообще всё, что «живёт до остановки».

Здесь три приёма.

1. Провести CancellationToken от начала до конца
2. Не дать исключению молча убить весь цикл
3. Не наращивать бесконечно ad hoc-повторы и backoff «на скорую руку»

BackgroundService удобен, но без присмотра превращается в «гигантский цикл, который всасывает всё подряд». Читается лучше, если собственно работу вынести в отдельные сервисы, а сам ExecuteAsync держать на управлении временем жизни и оркестрации.

flowchart TB
    accTitle: Как не превратить ExecuteAsync в свалку
    accDescr: Провести CancellationToken до конца, не дать циклу умереть молча, не раздувать retry и backoff на скорую руку — три приёма; собственно работу выносят в отдельные сервисы.
    exec["ExecuteAsync"] --> c1["Провести token до конца"]
    exec --> c2["Не дать циклу умереть молча"]
    exec --> c3["Не раздувать retry"]
    exec -.-> role["Держать фокус на времени жизни"]

Рис. 14: Три приёма, чтобы ExecuteAsync оставался местом управления временем жизни, а не гигантским циклом.

6.3. StopAsync

StopAsync — место для уборки при штатном завершении.

Подходит:

• лог остановки;
• снятие таймеров / подписок / наблюдения;
• уборка ресурсов, которые нужно явно close / flush;
• ожидание завершения через base.StopAsync.

Но важно также не ждать от StopAsync слишком многого.

• процесс упал;
• его принудительно завершили;
• его убили средствами ОС.

При таком выходе путь может просто не выполниться.

Поэтому:

• сохранение по возможности делать небольшими порциями в обычной работе;
• не проектировать так, чтобы согласованность сходилась только при выходе;
• cleanup делать идемпотентным.

Это важно. Пытаться «спасти мир» только при завершении обычно приводит к мутной конструкции.

flowchart TB
    accTitle: На что можно рассчитывать в StopAsync
    accDescr: При штатном выходе StopAsync может навести порядок, но при падении процесса, принудительном завершении или kill ОС путь может не выполниться; поэтому сохранение делают в обычной работе, а cleanup — идемпотентным.
    endkind{"Какое завершение?"}
    endkind -->|"Штатное"| sa["StopAsync может навести порядок"]
    endkind -->|"Сбой или kill"| skip["StopAsync может не вызваться"]
    skip --> ready["Сохранять по ходу обычной работы"]
    ready -.-> idem["cleanup делать идемпотентным"]

Рис. 15: StopAsync помогает при штатном выходе и не является страховкой при аварийном.

6.4. Замечание для .NET 10 и новее

Как критическое изменение в .NET 10 (выпуск в ноябре 2025 года), всё BackgroundService.ExecuteAsync целиком выполняется как фоновая задача.

Раньше была слегка запутанная особенность: синхронная часть до первого await при старте могла блокировать запуск других сервисов. После изменения авария вида «первые несколько строк ExecuteAsync утяжеляли старт» становится менее вероятной. И наоборот: если целевая платформа — .NET 9 или старше, поведение ещё старое. Сначала проверьте, к какой стороне относится ваш проект.

Но и тогда с точки зрения проектирования читаемее держать разделение:

• короткая работа, которая участвует в запуске → StartAsync;
• долгое тело → ExecuteAsync.

Если момент запуска нужно контролировать строже, в поле зрения попадает IHostedLifecycleService. Это тихий вопрос, который окупается, когда фоновое приложение толстеет.

flowchart TB
    accTitle: Различие поведения ExecuteAsync по версиям
    accDescr: В .NET 9 и старше синхронная часть до первого await может блокировать запуск других сервисов; начиная с .NET 10 всё ExecuteAsync выполняется как фоновая задача. В обоих случаях короткую работу запуска читаемее класть в StartAsync.
    v{"Какой целевой .NET?"}
    v -->|".NET 9 и старше"| oldb["Синхронная часть до await может блокировать старт"]
    v -->|".NET 10 и новее"| newb["Всё выполняется в фоне"]
    oldb --> split["Короткий старт — в StartAsync"]
    newb --> split

Рис. 16: Поведение по версиям меняется, разделение StartAsync и ExecuteAsync — нет.

7. Частые антипаттерны

7.1. Запускать бесконечный цикл в Window_Loaded / Form_Shown

Сначала это просто. Но ответственность за остановку и за исключения плотно прилипает к UI.

Как только появляются условия вроде «остановить, когда экран закрыли», «не останавливать при сворачивании в трей», «перезапустить при смене настроек», сразу становится тяжело.

7.2. Fire-and-forget Task.Run

Сам по себе Task.Run не зло. Зло — это отсутствие владельца у времени жизни и у исключений.

В частности, если начать фоновую работу через Task.Run(async () => { while (...) { ... } }), становится неясно:

• когда это заканчивается;
• кто этого ждёт;
• как видны исключения;
• сколько ждать при выходе.

Стоит перенести это на BackgroundService — и разобраться становится заметно проще.

7.3. Напрямую трогать UI из BackgroundService

Это мина. Проблема потока UI и проблема времени жизни смешиваются разом.

Worker не должен напрямую трогать UI; безопаснее провести границу через одно из:

• состояние;
• события;
• сообщения;
• очередь.

7.4. Всю важную запись сваливать только в StopAsync

StopAsync помогает при штатном выходе, но это не последний суд.

Если сохранение бывает только при выходе, flush бывает только при выходе, согласованность сходится только при выходе —

при сбое конструкция разваливается.

7.5. Host уже есть, а процесс всё равно роняют через Environment.Exit

Это тоже часто встречается.

Вызов Environment.Exit из соображений «ну ладно, надоело, давайте прибьём» своими руками обрезает маршрут graceful shutdown, который держит host.

Если фатальная ошибка должна остановить всё приложение, разумнее сначала вызвать IHostApplicationLifetime.StopApplication() и пройти штатный маршрут остановки.

flowchart TB
    accTitle: Два маршрута полного завершения
    accDescr: Environment.Exit своими руками обрезает маршрут graceful shutdown, который держит host; если из-за фатальной ошибки нужно остановить всё приложение, штатный путь — IHostApplicationLifetime.StopApplication.
    fatal["Нужно завершиться из-за фатальной ошибки"] --> q{"Чем завершать?"}
    q -->|"Environment.Exit"| cut["Обрезает путь graceful shutdown"]
    q -->|"StopApplication"| route["Штатный маршрут остановки"]
    route --> clean["Доходит до StopAsync и завершается"]

Рис. 17: Если host уже есть, а процесс роняют через Environment.Exit, вы сами обрезаете маршрут остановки, который сами же и завели.

8. Чек-лист для ревью

При ревью десктопного приложения с Generic Host / BackgroundService удобно смотреть по порядку.

• эта работа живёт вместе с приложением или это просто обработка события UI?
• ответственность запуска правильно разделена между StartAsync / ExecuteAsync / StopAsync?
• не стал ли StartAsync слишком тяжёлым?
• проводит ли ExecuteAsync CancellationToken до конца?
• не держит ли hosted service напрямую scoped-зависимости?
• не трогает ли worker объекты UI напрямую?
• не проглатываются ли исключения молча?
• не стал ли цикл повторных попыток неограниченно частым?
• есть ли верхняя граница ожидания при выходе?
• не смешано ли завершение через Environment.Exit или kill процесса?

Через этот чек-лист хорошо видна разница между «мы вроде добавили Host» и «время жизни собрано как проектное решение».

9. Краткая шпаргалка по выбору

10. Итог

Причина вносить Generic Host / BackgroundService в десктопное приложение — не «хочется писать в веб-стиле».

Реально работают вот эти три вещи.

1. Ответственность за запуск и остановку можно собрать в одном месте
2. Временем жизни долгой работы можно владеть как проектным решением
3. Graceful shutdown можно вести с входа, а не пристёгивать потом

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

И наоборот, простое разделение:

• UI как UI;
• фоновая работа как hosted service;
• собственно работа как DI-сервисы;
• завершение через StopAsync и CancellationToken

уже заметно всё упорядочивает.

flowchart TB
    accTitle: Итоговое разделение
    accDescr: UI остаётся UI, фон — hosted service, собственно работа — DI-сервисы, завершение — StopAsync и CancellationToken; одного такого разделения уже достаточно, чтобы заметно навести порядок.
    all["Приложение целиком"] --> u["UI остаётся UI"]
    all --> h["Фон — hosted service"]
    all --> d["Работа — DI-сервисы"]
    all --> s["Завершение — StopAsync и token"]

Рис. 18: Разделение без эффектности, но именно оно снижает «при закрытии иногда странно».

Эффектности здесь нет. Но такое скромное проектирование на практике хорошо работает. Оно снижает вязкость вроде «при закрытии иногда странно» и «неясно, где это останавливается».

Если вы застряли с Windows-инструментом или фоновым приложением — перевод на BackgroundService, проектирование запуска и остановки, циклы мониторинга, время жизни COM / сокетов / наблюдения за файлами, разбор сбоев при закрытии — напишите нам, хотя бы начиная с ревью архитектуры или прояснения направления.

11. Источники

• Полный набор примеров кода к этой статье (библиотека, демо, модульные тесты) https://github.com/gomurin0428/komurasoft-blog-samples/tree/main/generic-host-backgroundservice-desktop-app
• Связанная статья: Практическая таблица решений для C# async/await — Task.Run и ConfigureAwait
• Связанная статья: WPF и WinForms: async/await и поток UI
• Generic Host в .NET
• Фоновые задачи с hosted services в ASP.NET Core
• Класс BackgroundService
• Критическое изменение: BackgroundService выполняет весь ExecuteAsync как задачу
• Свойство HostOptions.ShutdownTimeout
• Logging in C# - .NET

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

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

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

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

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

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

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

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

Можно ли использовать Generic Host в десктопных приложениях?

Да. Generic Host — не механизм только для ASP.NET Core. Это основа, которая берёт на себя запуск, зависимости, конфигурацию, логирование и остановку, и её можно использовать в консоли, worker и десктопных приложениях на WPF / WinForms. Особенно хорошо она ложится на фоновые приложения, приложения в трее, мониторинг оборудования, периодическую синхронизацию, упорядоченную постобработку и циклы переподключения.

Для чего нужен BackgroundService?

Это контейнер, в котором «долго живущая» работа идёт с управляемым временем жизни, а не через fire-and-forget `Task.Run`. Это удобная вспомогательная реализация `IHostedService`: тело цикла мониторинга или периодической работы пишут в `ExecuteAsync`. Формула «эта работа живёт всё время, пока работает приложение» видна в самом коде, а ответственность за запуск, остановку, наблюдение за исключениями, логи, DI и конфигурацию можно собрать в одном месте.

Как разделять StartAsync / ExecuteAsync / StopAsync?

Код читается проще, если короткую инициализацию, которая участвует в запуске, класть в `StartAsync`, долгое тело — в `ExecuteAsync`, а сигнал остановки, flush и close при завершении — в `StopAsync`. Разовая работа по нажатию кнопки обычно остаётся обычным async-методом: тащить в `BackgroundService` всё подряд тяжеловесно.

Можно ли свалить всё завершение в StopAsync?

Лучше не стоит. `StopAsync` удобен, но это не страховка от падения процесса и принудительного завершения, поэтому не стоит сваливать туда всю уборку. Graceful shutdown (отмена текущего ввода-вывода, остановка следующего цикла, политика для остатка очереди, закрытие соединений, flush логов) проектируют через `CancellationToken` и `StopAsync`, но отдельно нужна предпосылка, что приложение не развалится и при аварийном выходе.

Об авторе

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

Го Комура

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

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