WinForms, WPF или WinUI: практическая таблица выбора

Для кого: разработчики настольных Windows-приложений на C# / .NET и те, кто принимает решение о выборе технологии. Предпосылки: используем текущий .NET (не .NET Framework), целевая платформа — только Windows. Как читать: если нужна только итоговая рекомендация — главы 1 и 3; если решаете, как продлевать жизнь существующему приложению — глава 7; если нужен последний критерий — глава 8.

Когда пишете настольное Windows-приложение на C# / .NET, каждый раз тихо, но ощутимо мешает вопрос: что выбрать — WinForms, WPF или WinUI.

Опасно выбирать по размытым причинам вроде:

• WinUI, потому что самое новое
• WinForms, потому что к нему все привыкли
• WPF, потому что кажется чем-то средним

flowchart TB
    accTitle: Чем опасен размытый выбор
    accDescr: Рисунок показывает, что размытый выбор вроде «WinUI, потому что новое», «WinForms, потому что привыкли», «WPF, потому что среднее» опасен, и на практике смотрят по более явным осям.
    w1["WinUI, потому что новое"] --> w4["Размытый выбор"]
    w2["WinForms, потому что привыкли"] --> w4
    w3["WPF, потому что среднее"] --> w4
    w4 --> w5["На практике смотрим по явным осям"]

Рис. 1: Выбирают не по «новое / привычное / среднее», а по явным осям.

На практике оси, на которые стоит смотреть, гораздо конкретнее.

• Новая разработка или продолжение существующего кода?
• Экраны в основном формы ввода или нужна выразительность?
• Современный UI в духе Windows сам по себе является ценностью продукта?
• Как будут устроены распространение, обновление и корпоративная эксплуатация?
• Команда ближе к стилю Windows Forms Designer или к стилю XAML / MVVM?

В этой статье мы сводим это в одну таблицу решений. WinUI здесь в основном означает WinUI 3 + Windows App SDK.¹²

Кроме того, все три технологии только для Windows. Если в поле зрения есть ещё macOS / Linux, сама постановка задачи уже другая.³⁴¹

flowchart TB
    accTitle: Все три только для Windows
    accDescr: Рисунок показывает, что WinForms, WPF и WinUI предназначены только для Windows, и если в поле зрения есть macOS или Linux, постановка задачи уже другая.
    t1["WinForms"] --> t4["Все три только для Windows"]
    t2["WPF"] --> t4
    t3["WinUI"] --> t4
    t4 -.-> t5["Если есть macOS / Linux, задача другая"]

Рис. 2: Все три только для Windows; кроссплатформенность — уже другая постановка задачи.

1. Сначала вывод (одной фразой)

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

• Если существующее приложение на WinForms большое, сначала смотрите на продолжение WinForms
• Если существующее приложение на WPF большое, сначала смотрите на продолжение WPF
• Для нового небольшого или среднего внутреннего инструмента на стандартных элементах и экранах ввода, который нужно собрать быстро, WinForms по-прежнему очень силён³⁵
• Для нового среднего или крупного бизнес-приложения с большим числом экранов, где нужны привязка данных, стили, шаблоны, команды и MVVM, чаще всего самый спокойный выбор — WPF⁴⁶⁷
• Для нового продукта только для Windows, где современный Windows UI, Fluent и актуальный опыт Windows напрямую входят в ценность продукта, сильный кандидат — WinUI¹²
• Если вы просто хотите вызывать новые Windows API, WinUI не обязателен. Возможности Windows App SDK можно взять и в WPF / WinForms²⁸⁹¹⁰
• Выбирать из расчёта «потом понемногу встроим WinUI» несколько опасно. Поэтапный переход на деле грязнее, чем кажется¹⁰¹¹

Коротко это выглядит так.

1. Если существующего кода много, сначала сохраняем эту линейку
2. Новая разработка стандартных форм в сжатые сроки — WinForms
3. Новое Windows-бизнес-приложение, которое будут долго развивать, — WPF
4. Новая разработка, где современный Windows UI сам по себе требование, — WinUI
5. Если нужен только Windows App SDK, не переводите всё сразу на WinUI

Выбор фреймворка — это одновременно выбор UI-технологии и выбор распространения, эксплуатации, стоимости обучения и стоимости перехода. Если решать это только по шкале «новое / старое», это отзовётся на схеме распространения и на стоимости сопровождения.

flowchart TB
    accTitle: Как приходят к выводу
    accDescr: Рисунок показывает порядок решения: если существующего кода много, сначала сохраняем линейку; если новая разработка и в центре стандартные формы — WinForms; если долгоживущее бизнес-приложение — WPF; если сам современный UI является требованием — WinUI.
    r1{"Существующего кода много?"} -->|"да"| r2["Сначала сохраняем эту линейку"]
    r1 -->|"нет, новая разработка"| r3{"В центре стандартные формы?"}
    r3 -->|"да"| r4["WinForms"]
    r3 -->|"нет"| r5{"Сам современный UI — требование?"}
    r5 -->|"нет"| r6["WPF, долгоживущее бизнес-приложение"]
    r5 -->|"да"| r7["WinUI"]
    r7 -.-> r8["Если цель только SDK, не переводите всё на WinUI"]

Рис. 3: Если смотреть в порядке «существующий код → характер экранов → требование современного UI», вывод в целом складывается сам.

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

2. Три технологии, о которых идёт речь

Сначала выровняем термины. Ниже раскрыты сокращения, которые будут встречаться дальше.

В Microsoft Learn WinForms описан как фреймворк с элементами, графикой, привязкой данных и пользовательским вводом, в котором приложение удобно собирать drag-and-drop Designer-ом Visual Studio.³

WPF — выразительный UI-фреймворк: векторная отрисовка, не зависящая от разрешения, XAML, привязка данных, стили / шаблоны, 2D / 3D и анимация.⁴

WinUI — часть Windows App SDK, UI-фреймворк для текущей Windows, рассчитанный на высокий DPI, современный ввод, плавную анимацию и опыт в духе Fluent.¹² Привязку данных / MVVM он тоже поддерживает обычным образом.¹²

Важно, что Windows App SDK и WinUI — не одно и то же. WinUI — UI-часть Windows App SDK, но сам SDK можно добавить и к существующим приложениям на WPF / WinForms / Win32.²¹⁰

Поэтому

• использовать WinUI
• использовать возможности Windows App SDK

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

flowchart TB
    accTitle: Windows App SDK и WinUI — не одно и то же
    accDescr: Рисунок показывает, что WinUI — UI-часть Windows App SDK, а сам SDK можно добавить и к существующим приложениям на WPF, WinForms и Win32, поэтому решение «брать WinUI» и решение «брать функции SDK» — разные.
    sdk["Windows App SDK"] --> ui["WinUI, его UI-часть"]
    sdk -.-> ex["Можно добавить и к WPF / WinForms / Win32"]
    ui --> d1["Решение «использовать WinUI»"]
    ex --> d2["Решение «использовать функции SDK»"]
    d1 --> d3["Похоже, но это разные решения"]
    d2 --> d3

Рис. 4: «Использовать WinUI» и «использовать функции Windows App SDK» — разные решения.

3. Таблица решений на одну страницу

Сначала — таблица, которой удобнее всего пользоваться на практике.

Этой таблицы в целом достаточно, но остаются два трудных места.

1. Новое Windows-бизнес-приложение: ближе к WinForms или к WPF?
2. Есть существующий WPF / WinForms — стоит ли уходить на WinUI?

Эти два пункта легче разобрать по сравнительной таблице ниже.

flowchart TB
    accTitle: Два вопроса, которые остаются после таблицы
    accDescr: Рисунок показывает, что одной таблицы недостаточно для двух вопросов: новое Windows-бизнес-приложение ближе к WinForms или к WPF, и стоит ли при существующем WPF или WinForms уходить на WinUI; дальше их разбирают по сравнительной таблице.
    hyo["Таблица на одну страницу"] --> n1["Новое бизнес-приложение: WinForms или WPF?"]
    hyo --> n2["Есть существующий код — уходить на WinUI?"]
    n1 --> hik["Смотрим сравнительную таблицу по осям"]
    n2 --> hik

Рис. 5: Два вопроса, которые остаются после таблицы решений, разбирают по сравнительной таблице.

4. Сравнение по осям

Это не официальная таблица «кто лучше», а сравнение, сильно смещённое в сторону практики.

Смысл таблицы не в том, что сильнее всего, а в том, где меньше всего трения.

Например, если у вас

• внутренний инструмент настроек
• экран настройки оборудования
• список, детали, поиск, настройки, кнопки
• важнее не внешний вид, а стабильная эксплуатация и скорость доработки

то WinForms и сегодня вполне разумный выбор.

Наоборот, если у вас

• много экранов
• часто меняется состояние отображения
• хочется отделить View от логики
• хочется естественно связать изменения данных с UI
• хочется держать UI через стили / шаблоны

то хорошо срабатывает WPF.⁶⁷

А если у вас

• хочется опираться на внешний вид в духе Windows 11
• хочется по-настоящему задействовать Fluent
• в предпосылках высокий DPI, touch и современные API окон
• новый продукт только для Windows, и впечатление от UI тоже важно

то естественный выбор — WinUI.¹²

flowchart TB
    accTitle: Выбираем по меньшему трению
    accDescr: Рисунок показывает, что смотреть нужно не на то, что сильнее, а на то, где меньше трения: внутренний инструмент на стандартных элементах — WinForms, много экранов и MVVM — WPF, Fluent и актуальный опыт Windows — WinUI.
    k0["Где меньше всего трения?"] --> k1["Внутренний инструмент на стандартных элементах"]
    k0 --> k2["Много экранов, нужен MVVM"]
    k0 --> k3["Fluent и актуальный опыт Windows"]
    k1 --> k4["WinForms"]
    k2 --> k5["WPF"]
    k3 --> k6["WinUI"]

Рис. 6: Три технологии разводят не по «кто сильнее», а по «где меньше трения».

4.1 «Разница в выразительности» на минимальном коде

Строка «совместимость с привязкой данных / MVVM» из таблицы словами даётся плохо. Ниже один и тот же экран написан на WinForms и на WPF — минимальный код, чтобы было видно, что меняется.

Экран простой: одно текстовое поле и одна кнопка сохранения.

WinForms: Designer генерирует *.Designer.cs, а значение с экрана забирают внутри обработчика события.

// MainForm.Designer.cs — это генерирует Designer. Сюда руками не пишут
private System.Windows.Forms.TextBox nameTextBox;
private System.Windows.Forms.Button saveButton;

private void InitializeComponent()
{
    this.nameTextBox = new System.Windows.Forms.TextBox();
    this.saveButton = new System.Windows.Forms.Button();
    this.SuspendLayout();

    this.nameTextBox.Location = new System.Drawing.Point(12, 12);
    this.nameTextBox.Size = new System.Drawing.Size(200, 23);

    this.saveButton.Location = new System.Drawing.Point(218, 12);
    this.saveButton.Size = new System.Drawing.Size(75, 23);
    this.saveButton.Text = "Сохранить";
    this.saveButton.Click += new System.EventHandler(this.SaveButton_Click);

    this.Controls.Add(this.nameTextBox);
    this.Controls.Add(this.saveButton);
    this.ResumeLayout(false);
}

// MainForm.cs — эту часть пишете вы
public partial class MainForm : Form
{
    private readonly EditorService _service;

    public MainForm(EditorService service)
    {
        _service = service;
        InitializeComponent();
    }

    private void SaveButton_Click(object sender, EventArgs e)
    {
        // Берём значение прямо из элемента на экране и передаём дальше
        _service.Save(this.nameTextBox.Text);
    }
}

WPF: в XAML пишут только «с чем связано», а ввод и вывод значения делает Binding.

<!-- MainWindow.xaml -->
<Window x:Class="MyApp.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="Правка" Width="360" Height="120">
    <StackPanel Orientation="Horizontal" Margin="12">
        <TextBox Width="200"
                 Text="{Binding Name, UpdateSourceTrigger=PropertyChanged}" />
        <Button Width="75" Margin="6,0,0,0" Content="Сохранить"
                Command="{Binding SaveCommand}" />
    </StackPanel>
</Window>

// MainWindow.xaml.cs — если забыть задать DataContext, Binding ничего не сделает
public partial class MainWindow : Window
{
    public MainWindow(EditorService service)
    {
        InitializeComponent();
        this.DataContext = new MainViewModel(service);
    }
}

// MainViewModel.cs — эта сторона не знает про экран. Здесь же можно писать модульные тесты
public sealed class MainViewModel : INotifyPropertyChanged
{
    private readonly EditorService _service;
    private string _name = string.Empty;

    public MainViewModel(EditorService service)
    {
        _service = service;
        SaveCommand = new RelayCommand(() => _service.Save(Name));
    }

    public string Name
    {
        get => _name;
        set
        {
            if (_name == value) return;
            _name = value;
            PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(nameof(Name)));
        }
    }

    public ICommand SaveCommand { get; }

    public event PropertyChangedEventHandler PropertyChanged;
}

RelayCommand — небольшой класс, реализующий ICommand. Он есть, например, в CommunityToolkit.Mvvm, и его же можно написать самому примерно в 20 строк.

По числу строк WPF длиннее. Разница начинается дальше.

На трёх экранах быстрее WinForms; на тридцати легче WPF — вот практический смысл этой разницы.

flowchart TB
    accTitle: Как идёт значение
    accDescr: Рисунок показывает разницу потока значения: в WinForms обработчик события забирает его прямо из элемента на экране и передаёт в сервис; в WPF Binding связывает View и ViewModel, и сервис вызывает ViewModel, который экрана не знает.
    subgraph wf["WinForms"]
    a1["Элемент View"] --> a2["Обработчик события"]
    a2 --> a3["Сервис вызывают напрямую"]
    end
    subgraph wp["WPF"]
    b1["XAML View"] --> b2["Binding"]
    b2 --> b3["ViewModel"]
    b3 --> b4["Вызов сервиса"]
    end
    a3 -.-> c1["На трёх экранах быстрее"]
    b4 -.-> c2["На тридцати всё ещё легче"]

Рис. 7: В WinForms значение берут с экрана напрямую, в WPF его держит ViewModel через Binding.

5. Каким проектам что подходит

5.1 WinForms

К WinForms часто относятся слишком легко, но по одному критерию — быстро собрать бизнес-экран на стандартных элементах — его и сейчас нельзя сбрасывать со счетов.³⁵

Особенно он подходит, например, здесь:

• внутренние инструменты настроек
• экраны настроек оборудования, измерительных приборов, средств мониторинга
• административные экраны, поиск, список + детали
• проекты с большим объёмом существующего WinForms-кода
• команды, которые сильно опираются на сборку экранов в Windows Forms Designer

Сила WinForms в том, что без тяжёлой философии довольно быстро получается экран, близкий к готовому. Формы, кнопки, подписи, текстовые поля, сетки данных. Если это ваше основное поле, здесь можно уверенно работать.

Слабые места тоже ясны.

• Хочется широко унифицировать внешний вид всего приложения
• Хочется держать UI через стили и шаблоны
• Хочется разбирать сложные смены состояния в основном через привязку данных
• Хочется аккуратно отделить логику экрана

Здесь естественнее выглядят WPF и WinUI.

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

• держать ответственность каждого экрана небольшой
• резать по UserControl
• сознательно держать границу в духе Presenter / ViewModel
• не размазывать бизнес-логику по обработчикам событий экрана

flowchart TB
    accTitle: Как не утонуть в обработчиках событий
    accDescr: Рисунок показывает, что крупное приложение на WinForms легко превращается в лес обработчиков событий, поэтому с самого начала фиксируют маленькую ответственность экрана, нарезку по UserControl и границу в духе Presenter или ViewModel.
    mo["Крупное приложение на WinForms"] --> ha["Легко получается лес обработчиков"]
    ha --> p1["Держать ответственность экрана маленькой"]
    ha --> p2["Резать по UserControl"]
    ha --> p3["Держать границу в уме"]
    p3 -.-> p4["Не писать бизнес-логику в событиях экрана"]

Рис. 8: В крупном приложении на WinForms спокойнее заранее договориться, как резать ответственность.

И ещё практический момент, который легко недооценить: желание использовать Windows App SDK — не причина бросать WinForms. Официально есть путь добавить возможности Windows App SDK к существующему приложению на WinForms.⁹¹⁰

То есть у WinForms доступен такой вариант:

• UI оставить как есть
• модернизировать только нужные функции Windows

Это реалистичный компромисс.

flowchart TB
    accTitle: Модернизация, оставаясь на WinForms
    accDescr: Рисунок показывает, что желание использовать Windows App SDK не обязывает бросать WinForms: UI можно оставить, а модернизировать только нужные функции Windows.
    g1["Нужен Windows App SDK"] --> g2["WinForms бросать не обязательно"]
    g2 --> g3["UI оставляем"]
    g2 --> g4["Модернизируем только нужные функции"]
    g3 --> g5["Реалистичный компромисс"]
    g4 --> g5

Рис. 9: WinForms позволяет сохранить UI и модернизировать только нужные функции Windows.

5.2 WPF

Если смотреть на WPF как на настольный .NET UI Windows, это самое сбалансированное ядро.⁴

Сильные стороны очевидны.

• Экраны можно описывать декларативно на XAML
• Data Binding сильный
• Доступны Style / Template
• Доступны Command
• View и логику легко разделить
• Средние и крупные наборы экранов легче держать в порядке

В официальной документации привязка данных описана как центральная функция WPF, а команды — как механизм, отделяющий ввод от логики выполнения.⁶⁷

Поэтому он подходит, например, здесь:

• бизнес-приложение с большим числом экранов
• много списков, деталей, правки, поиска, отображения статуса
• Windows-приложение, которое несколько человек будут долго сопровождать
• хочется отделить View от логики
• хочется заранее развести ответственность за внешний вид и поведение с прицелом на будущие доработки
• в WinForms экраны быстро станут тяжёлыми

Когда для нового бизнес-приложения только для Windows выбор не очевиден, WPF и сегодня безопасный первый кандидат. Отсекать его фразой «WPF устарел, значит нет» довольно грубо.

flowchart TB
    accTitle: Безопасный первый кандидат для нового бизнес-приложения
    accDescr: Рисунок показывает, что для среднего и крупного Windows-бизнес-приложения с большим числом экранов, разделением View и логики и долгим сопровождением несколькими людьми WPF и сегодня безопасный первый кандидат.
    j1["Бизнес-приложение с большим числом экранов"] --> j4["WPF — безопасный первый кандидат"]
    j2["Хочется отделить View от логики"] --> j4
    j3["Несколько человек будут долго сопровождать"] --> j4
    j4 -.-> j5["Отсекать как «устарел» грубо"]

Рис. 10: Для нового бизнес-приложения с большим числом экранов и долгим сопровождением WPF остаётся безопасным первым кандидатом.

Скорее наоборот, если

• есть существующий код на WPF
• есть опыт XAML / MVVM
• Fluent не абсолютный приоритет
• но UI хочется спроектировать аккуратнее, чем в WinForms

то WPF вполне обычно оказывается самым здравым выбором.

Конечно, у WPF есть и свои особенности.

• Слишком вычурный XAML становится трудно читать
• Слишком много собственных элементов и наслоения шаблонов утяжеляет сопровождение
• Принцип «всё решать через Binding» тоже может, наоборот, затруднить понимание потока обработки

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

В WPF тоже можно добавить часть возможностей Windows App SDK. То есть есть путь модернизировать функции Windows, оставаясь на WPF.⁸¹⁰

Поэтому вместо

• полностью бросить WPF и целиком уйти на WinUI

на практике чаще выигрывает

• подтянуть WPF к текущему .NET
• добавить только нужные функции Windows через Windows App SDK
• наводить порядок в устройстве начиная с крупных новых функций

flowchart TB
    accTitle: Постепенность лучше полной смены WPF
    accDescr: Рисунок показывает, что полностью бросать WPF и уходить на WinUI обычно хуже, чем подтянуть WPF к текущему .NET, добавить нужные функции через Windows App SDK и наводить порядок начиная с крупных новых функций.
    z1["Подтянуть WPF к текущему .NET"] --> z2["Нужные функции добавить через SDK"]
    z2 --> z3["Порядок начинать с крупных новых функций"]
    z3 -.-> z4["Так чаще выигрывают, чем при полной смене"]

Рис. 11: Для WPF чаще выигрывает не полная смена, а переход на текущий .NET и точечное добавление функций.

5.3 WinUI

WinUI — современный фаворит, когда вы пишете новое приложение только для Windows.¹²

Официально его ставят так:

• оптимизация под новейшее оборудование и ввод
• высокий DPI
• плавная анимация
• часть Windows App SDK

¹

Поэтому он подходит здесь:

• новый продукт только для Windows
• важны само впечатление от UI и опыт использования
• хочется использовать Fluent напрямую
• хочется держаться текущего состояния Windows 11
• в предпосылках новые API окон и актуальный опыт Windows

Проекты, где у WinUI действительно есть основание, это в основном не «хотим выглядеть новее», а «хотим встроить в продукт сегодняшний опыт Windows».

flowchart TB
    accTitle: Как отличить настоящее основание для WinUI
    accDescr: Рисунок показывает, что основание выбрать WinUI есть не потому, что внешний вид новый, а потому, что в продукт хотят встроить сегодняшний опыт Windows.
    y1["Есть основание выбрать WinUI"] --> y2["Не «выглядит новее»"]
    y2 --> y3["«Сегодняшний опыт Windows в продукт»"]
    y3 -.-> y4["Новый продукт только для Windows, впечатление от UI важно"]

Рис. 12: WinUI берут не из-за «новизны», а чтобы встроить сегодняшний опыт Windows.

Есть и оговорки.

5.3.1 WinUI — это не «просто более новый WPF»

Из-за XAML он кажется близким, но отличаются

• базовый API
• набор элементов
• структура проекта
• подход к deploy / packaging
• способ работы с Windows App SDK

То есть рассматривать его как лёгкую замену WPF несколько опасно.

flowchart TB
    accTitle: WinUI — не просто более новый WPF
    accDescr: Рисунок показывает, что из-за XAML WinUI кажется близким к WPF, но отличаются базовый API, элементы, структура, deploy и packaging, а также работа с Windows App SDK, поэтому считать его лёгкой заменой опасно.
    u1["Из-за XAML кажется близким"] --> u2["Но отличий много"]
    u2 --> u3["Базовый API и элементы"]
    u2 --> u4["Структура и packaging"]
    u2 --> u5["Как работают с SDK"]
    u5 -.-> u6["Считать лёгкой заменой опасно"]

Рис. 13: Даже при общем XAML WinUI нельзя считать лёгкой заменой WPF.

5.3.2 Выбор WinUI сразу выводит вперёд вопрос распространения

Приложения на WinUI 3 по умолчанию packaged. Сам Windows App SDK при этом работает и в packaged, и в unpackaged вариантах.¹³¹⁴²

Здесь важно заранее решить:

• как распространять приложение
• как ставить среду выполнения
• нужен ли package identity
• внутреннее распространение, Store, MSIX или привычный путь EXE / MSI

Одной фразы «проверьте заранее» мало: неясно, что именно смотреть. Ниже — содержание этой проверки.

Сначала есть две оси решения.¹³¹⁵

• packaging: будет ли у приложения package identity
• runtime: Windows App SDK берут как framework-dependent или кладут рядом как self-contained

flowchart TB
    accTitle: Две оси, которые решают первыми
    accDescr: Рисунок показывает, что в распространении WinUI сначала решают ось packaging (есть ли у приложения package identity) и ось runtime (Windows App SDK как framework-dependent или self-contained).
    h1["Схема распространения"] --> h2["Ось packaging"]
    h1 --> h3["Ось runtime"]
    h2 -.-> h4["Будет ли package identity"]
    h3 -.-> h5["framework-dependent или рядом с приложением"]

Рис. 14: В распространении сначала фиксируют оси packaging и runtime.

На стороне packaging три модели.¹³

Дальше package identity оценивают со стороны функций. Официально как «без package identity не работает» указаны, например, такие возможности.¹³

• фоновые задачи
• push-уведомления (WNS)
• share target
• расширение контекстного меню Проводника
• ассоциации типов файлов и URI-схем
• задачи автозапуска
• App Service
• Windows AI API

Практичный порядок проверки такой.

1. Вывести из требований. Планируете ли функции из списка выше. Достаточно одной — нужна сторона packaged.
2. Можно ли отказаться от существующего установщика. Если нет, ответ не полная смена на MSIX, а packaged, указывающий на внешнее расположение. Раскладка двоичных файлов и механизм обновления остаются, добавляется только identity.¹³
3. Проверить в рантайме. Есть ли identity у текущего процесса, можно узнать через GetCurrentPackageFullName. Если identity нет, возвращается APPMODEL_ERROR_NO_PACKAGE. Если вызов Windows API даёт E_ILLEGAL_METHOD_CALL или APPMODEL_ERROR_NO_PACKAGE, это как раз признак, что упёрлись в требование package identity.¹³
4. Проверить на машине. Установленные пакеты перечисляет PowerShell-команда Get-AppxPackage.
5. В конце решить runtime. Если раздаёте через xcopy или zip, естественнее self-contained; если идёте в Store — по умолчанию framework-dependent.¹⁵

Распространение важно и для WinForms / WPF, но у WinUI этот вопрос выходит на первый план раньше. Новое приложение на WinUI 3 по умолчанию packaged, поэтому если ничего не решать, вы автоматически садитесь на путь MSIX.¹³ Казалось, что выбираете UI, а на деле выбрали стратегию распространения — в этом небольшая сложность этого мира.

flowchart TB
    accTitle: Как проверяют package identity
    accDescr: Рисунок показывает пять шагов: вывести нужность package identity из требований, понять, можно ли отказаться от установщика, проверить в рантайме и на машине и в конце решить runtime.
    s1["1. Вывести из требований"] --> s2["2. Можно ли отказаться от установщика"]
    s2 --> s3["3. Проверить в рантайме"]
    s3 --> s4["4. Проверить на машине"]
    s4 --> s5["5. Решить runtime"]
    s2 -.-> s6["Если нет — packaged с внешним расположением"]
    s3 -.-> s7["Смотрят через GetCurrentPackageFullName"]

Рис. 15: Нужен ли package identity, проверяют в порядке требования → установщик → рантайм → машина.

5.3.3 «Понемногу подмешивать WinUI в существующий WPF / WinForms» сначала стоит проверить на практике

Здесь ожидания легко разрастаются. Но в FAQ Microsoft по смыслу сказано, что пока вы не готовы полностью сменить UI-фреймворк, WinUI часто нельзя использовать. Про XAML Islands официальная документация показывает путь встраивания в существующие настольные приложения, однако в примечаниях к выпуску Windows App SDK 1.4 указано, что сейчас это в основном тестировали в приложениях на C++, а удобных элементов-обёрток для WPF / WinForms нет.¹⁰¹¹

То есть

• «похоже, можно переходить поэтапно»
• «похоже, можно понемногу встраивать»

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

WinUI лучше всего ложится, когда вы

• начинаете с нуля
• строите опыт для продукта только для Windows

Наоборот, как площадка полной замены существующего WPF / WinForms он требует и основания, и проверки.

flowchart TB
    accTitle: Поэтапный переход проверяют до того, как делать его главной стратегией
    accDescr: Рисунок показывает, что идея понемногу подмешивать WinUI привлекательна, но FAQ исходит из полной смены, удобных обёрток для WPF и WinForms нет, поэтому до главной стратегии это проверяют на небольшом масштабе.
    v1["Хочется понемногу подмешивать WinUI"] --> v2["Как идея привлекательно"]
    v2 --> v3["FAQ по смыслу исходит из полной смены"]
    v3 --> v4["Обёрток для WPF / WinForms нет"]
    v4 --> v5["До главной стратегии проверить на небольшом масштабе"]

Рис. 16: «Понемногу подмешивать WinUI» проверяют на небольшом масштабе, прежде чем делать главной стратегией.

6. Частые ошибки выбора

6.1 «WinUI, потому что самое новое»

Это понятно, но довольно опасно.

Причину выбрать новую технологию лучше оценивать так: есть ли ценность, которую нельзя получить иначе, кроме как этой технологией.

• Современный опыт Windows — это ценность продукта?
• Хотите использовать Fluent напрямую?
• Это новый продукт?
• Готовы принять предпосылки по распространению / эксплуатации?

Если да — WinUI сильный кандидат. Если аргумент сводится к «кажется, у этого есть будущее», обоснование затрат слабое.

flowchart TB
    accTitle: Выбирают не потому что «самое новое», а по ценности
    accDescr: Рисунок показывает, что новую технологию выбирают, если без неё нельзя получить нужную ценность: при ответе «да» WinUI сильный кандидат, а одного «кажется, есть будущее» для обоснования затрат мало.
    q0["Почему берём новую технологию"] --> q1{"Есть ценность, которую иначе не получить?"}
    q1 -->|"да"| q2["WinUI — сильный кандидат"]
    q1 -->|"только «кажется, есть будущее»"| q3["Обоснование затрат слабое"]

Рис. 17: Смотрят не на «самое новое», а на ценность, которую иначе не получить.

6.2 «Раз нужен Windows App SDK, значит обязаны перейти на WinUI»

Это распространённое заблуждение, и оно неверно.

Windows App SDK можно добавить и к существующим приложениям на WPF / WinForms. Официальный FAQ тоже поясняет, что приложения на WPF / MFC / WinForms могут использовать API Windows App SDK, не связанные с WinUI.¹⁰⁸⁹

Например, такие функции, как

• App Lifecycle
• Windowing
• Toast Notifications

в ряде случаев можно взять, сохранив текущий UI.¹⁰

6.3 «WPF / WinForms уже закончились»

И здесь не стоит рубить сплеча.

И WinForms, и WPF по-прежнему получают документацию и маршруты перехода на текущем .NET и официально считаются действующим настольным UI Windows.³⁴

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

Для долгого сопровождения это читается так.

• WPF и WinForms не «заморожены и брошены»: функции приходят с ежегодными выпусками .NET. Но у WinForms часть заметных функций ещё экспериментальная, поэтому момент внедрения нужно проверять.
• Выбирая WinUI, вы ведёте срок поддержки .NET и срок поддержки Windows App SDK отдельно. В долгих проектах это незаметно, но ощутимо.
• Ни один вариант не обещает «через 10 лет будет работать без правок», поэтому практичнее сразу решить, до какой версии будете следовать.

flowchart TB
    accTitle: Как читать долгое сопровождение
    accDescr: Рисунок показывает, что WPF и WinForms получают функции с ежегодными выпусками .NET, а WinUI заставляет отдельно вести срок поддержки SDK, поэтому сначала решают, до какой версии будут следовать.
    m1["WPF / WinForms"] --> m2["Функции приходят с выпусками .NET"]
    m3["WinUI"] --> m4["Срок SDK ведут отдельно"]
    m2 --> m5["Сначала решить, до какой версии следовать"]
    m4 --> m5

Рис. 18: Для долгого сопровождения смотрят, на чём едут обновления, и заранее фиксируют, до какой версии следуют.

Особенно в бизнес-приложениях обычно тяжелее новизны UI-фреймворка оказываются

• существующий код
• сторонние элементы
• число экранов
• отчёты и печать
• связь с оборудованием
• процедура распространения

6.4 «Раз уж так, лучше переписать целиком»

Полная перепись ближе к решению о бизнесе, чем к выбору технологии.

Если приложение уже есть, сначала стоит проверить следующее.

1. Что на самом деле мешает?
2. Это проблема UI или проблема устройства системы?
3. Не являются ли настоящей нагрузкой зависимые DLL / COM / OCX / отчёты / распространение?
4. Можно ли снять боль, не меняя весь UI?

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

flowchart TB
    accTitle: Четыре вопроса до полной переписи
    accDescr: Рисунок показывает, что полная перепись ближе к решению о бизнесе, и сначала выясняют, что именно мешает, UI это или устройство системы, не тянут ли зависимости и распространение, и можно ли решить задачу без смены всего UI.
    r1["1. Что на самом деле мешает?"] --> r2["2. UI или устройство системы?"]
    r2 --> r3["3. Не тянут ли зависимости и распространение?"]
    r3 --> r4["4. Можно ли решить без смены UI?"]
    r4 -.-> r5["Перепись и стоит соответственно"]

Рис. 19: До решения о полной переписи четырьмя вопросами выясняют, в чём на самом деле боль.

6.5 «Потом как-нибудь вывезем через XAML Islands»

Ожидание понятно. Но безопаснее не рассчитывать на это с самого начала как на запасной выход.¹⁰¹¹

Для поэтапного перехода сначала на небольшом масштабе стоит проверить:

• какие элементы хотите встроить
• что будет с фокусом, вводом, DPI, темой
• действительно ли эта конфигурация хостинга остаётся стабильной

flowchart TB
    accTitle: XAML Islands сначала пробуют на небольшом масштабе
    accDescr: Рисунок показывает, что при поэтапном переходе сначала на небольшом масштабе проверяют, какие элементы встраивают, что происходит с фокусом, вводом, DPI и темой, и стабилен ли хостинг, и с самого начала не рассчитывают на это как на запасной выход.
    p0["Ожидание «потом как-нибудь вывезем»"] --> p1["Какие элементы хотите встроить"]
    p0 --> p2["Фокус, ввод, DPI, тема"]
    p0 --> p3["Стабилен ли хостинг"]
    p1 --> p4["Сначала проверить на небольшом масштабе"]
    p2 --> p4
    p3 --> p4

Рис. 20: XAML Islands не держат как запасной выход: три пункта сначала проверяют на небольшом масштабе.

7. Как смотреть, если приложение уже есть

Здесь существующее приложение важнее новой разработки.

7.1 Если есть существующий WinForms

Прежде чем сразу прыгать на WinUI, проверьте следующее.

• Можно ли подтянуть к текущему .NET?
• Нужен ли переход на 64-бит?
• Можно ли навести порядок в async / await, обработке исключений, настройках, журналировании?
• Можно ли поднять сопровождаемость нарезкой экранов или выделением UserControl?
• Можно ли добавить только нужные функции Windows через Windows App SDK?

То, что выглядит как проблема WinForms, нередко на деле оказывается просто

• смешением экрана и логики
• неаккуратной границей потоков
• скученностью ответственности за настройки / файлы / COM / БД

В таком случае переезд на WinUI лишь переименовывает проблему, но не решает её.

flowchart TB
    accTitle: Проблема просто сменит вывеску
    accDescr: Рисунок показывает, что за «проблемой WinForms» часто стоят смешение экрана и логики, неаккуратная граница потоков и скученность ответственности, и тогда переезд на WinUI только переименовывает проблему.
    e1["Выглядит как проблема WinForms"] --> e2["На деле проблема устройства"]
    e2 --> e3["Смешение экрана и логики"]
    e2 --> e4["Неаккуратная граница потоков"]
    e2 --> e5["Скученность ответственности"]
    e4 --> e6["Переезд на WinUI только сменит вывеску"]

Рис. 21: Структурная проблема, которую приняли за проблему UI, останется и после смены фреймворка.

7.2 Если есть существующий WPF

WPF удобно опирается на уже сделанное.

• Наработки XAML
• Binding
• Style / Template
• Command
• MVVM

Причина отказаться от всего этого должна быть довольно явной.

Например, если

• хотите полностью обновить UI продукта
• Fluent должен стать основной осью
• новый модуль выделяется как отдельный продукт
• хотите двигаться к новому опыту как продукт только для Windows

это может стать основанием рассматривать WinUI. Но простое «потому что WPF устарел» — слабый аргумент.

7.3 По-настоящему тяжело часто оказывается не UI

На практике тяжелее, как ни странно, часто вот это:

• ActiveX / OCX
• COM interop
• собственные отчёты
• печать
• связь с Excel / Office
• нативные DLL
• перекос 32-бит / 64-бит
• установщики, права, обновления, подпись

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

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

flowchart TB
    accTitle: Сначала инвентаризация границ зависимостей
    accDescr: Рисунок показывает, что на практике тяжелее ActiveX и COM, отчёты и печать, нативные DLL, установщик и обновления, то есть не UI, поэтому сначала инвентаризируют границы зависимостей, а не только UI-фреймворк.
    d1["ActiveX / COM interop"] --> d4["По-настоящему тяжело часто не UI"]
    d2["Отчёты, печать, связь с Office"] --> d4
    d3["Установщик, права, обновления, подпись"] --> d4
    d4 --> d5["Сначала инвентаризация границ зависимостей"]
    d5 -.-> d6["Один аккуратный UI проект не облегчит"]

Рис. 22: При переходе тяжелее зависимости вне UI, и инвентаризацию делают раньше.

8. Пять вопросов, если всё ещё не определились

Если в итоге выбор не складывается, задайте по порядку эти пять вопросов.

8.1 Много ли существующего кода?

• Много → в основном сохраняем существующую линейку
• Мало / нет → переходим к новому выбору

8.2 Обязателен ли для этого приложения «современный опыт в духе Windows»?

• Обязателен → WinUI сильный кандидат
• Не особенно → проверьте, хватит ли WPF / WinForms

8.3 Экраны в основном стандартные формы или нужна выразительность в духе XAML?

• В основном стандартные формы → WinForms
• Важны стили / шаблоны / Binding / MVVM → WPF

8.4 Нужно полное обновление UI или добавление функций Windows?

• Полное обновление UI → рассмотреть WinUI
• Только добавление функций → сначала рассмотреть текущий WPF / WinForms + Windows App SDK

8.5 Можете ли вы заранее объяснить, как будут устроены распространение / обновление / эксплуатация?

• Пока неясно → для WinUI заранее проработать packaging / deployment
• Хотите сильно опереться на существующую эксплуатацию → у WPF / WinForms обычно меньше трения

flowchart TB
    accTitle: Поток пяти последних вопросов
    accDescr: Рисунок показывает, как по очереди спрашивают, много ли существующего кода, обязателен ли современный опыт, в центре ли стандартные формы, и сужают выбор.
    f1{"Много ли существующего кода?"} -->|"много"| f2["В основном сохраняем линейку"]
    f1 -->|"мало или нет"| f3{"Обязателен ли современный опыт?"}
    f3 -->|"обязателен"| f4["WinUI — сильный кандидат"]
    f3 -->|"не особенно"| f5{"В центре стандартные формы?"}
    f5 -->|"да"| f6["WinForms"]
    f5 -->|"важнее выразительность"| f7["WPF"]
    f2 -.-> f8["Если нужны только функции — сначала SDK"]
    f4 -.-> f9["Рано проработать packaging и распространение"]

Рис. 23: Если выбор не складывается, сужают его вопросами про существующий код, опыт и характер экранов.

Эти пять вопросов заметно сужают выбор. Если в конце свести грубо, получится так:

• Быстро собрать внутреннюю форму → WinForms
• Windows-бизнес-приложение, которое будут долго развивать → WPF
• UI нового современного Windows-продукта → WinUI
• Сохранить существующее и модернизировать только функции Windows → текущий фреймворк + Windows App SDK

9. Итог

Выбор между WinForms, WPF и WinUI — это не игра «выстроить по новизне и взять крайний справа».

Сначала смотрят на эти четыре вещи.

1. Где лежит существующий код
2. Экраны ориентированы на формы или на выразительность
3. Является ли современный UI в духе Windows требованием продукта
4. Как будут устроены распространение / обновление / эксплуатация

Как только эти четыре пункта прояснились, направление в целом определяется само.

flowchart TB
    accTitle: Четыре вопроса итога
    accDescr: Рисунок показывает, что если видны существующий код, характер экранов, требование современного UI и схема распространения с эксплуатацией, направление в целом определяется само.
    n1["Существующий код"] --> n5["Направление в целом определяется"]
    n2["Характер экранов"] --> n5
    n3["Требование современного UI"] --> n5
    n4["Распространение и эксплуатация"] --> n5

Рис. 24: Когда видны четыре вопроса, направление по фреймворку в целом складывается само.

• Много существующего WinForms → сначала продолжаем WinForms
• Много существующего WPF → сначала продолжаем WPF
• Новая разработка на стандартных формах → WinForms
• Новое среднее или крупное Windows-бизнес-приложение → WPF
• Новая разработка, где сам современный опыт Windows является требованием → WinUI
• Если нужен только Windows App SDK, не переводите всё сразу на WinUI

Больше всего стоит избегать трёх подходов:

• отбрасывать, потому что старое
• выбирать, потому что новое
• начинать из расчёта «по ходу как-нибудь разберёмся»

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

10. Справочные материалы

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

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

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

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

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

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

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

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

Чем WinUI 3 отличается от WPF?

Оба используют XAML, но WinUI — это не «просто более новый WPF». Другие базовый API, набор элементов, структура проекта, подход к deploy / packaging и способ работы с Windows App SDK. WPF — UI-фреймворк для средних и крупных бизнес-приложений: векторная отрисовка, не зависящая от разрешения, привязка данных, стили / шаблоны и команды. WinUI как часть Windows App SDK — современный UI-фреймворк, рассчитанный на Fluent, высокий DPI и актуальный опыт Windows. Рассматривать его как лёгкую замену WPF опасно.

Для новой разработки что выбрать: WinForms, WPF или WinUI?

Смотрите на характер экранов и требования продукта. Небольшой или средний внутренний инструмент на стандартных элементах и формах ввода, который нужно собрать быстро, — WinForms по-прежнему очень силён. Среднее или крупное бизнес-приложение с большим числом экранов, где нужны привязка данных, стили, шаблоны и MVVM, — чаще всего самый спокойный выбор WPF. Новый продукт только для Windows, где Fluent и современный опыт Windows сами по себе входят в ценность продукта, — сильный кандидат WinUI. Если существующего кода много, сначала смотрите, можно ли продолжать ту же линейку.

WPF и WinForms уже устарели?

Не стоит отбрасывать их с ходу. И WinForms, и WPF по-прежнему получают документацию и маршруты перехода на текущем .NET и официально считаются действующим настольным UI Windows. В бизнес-приложениях существующий код, сторонние элементы, отчёты и печать, связь с оборудованием и процедура распространения обычно весят больше, чем новизна UI-фреймворка. Даже в новой разработке не редкость, что меньше всего трения дают как раз WinForms или WPF.

Чтобы пользоваться новыми возможностями Windows, обязательно переходить на WinUI?

Нет. Windows App SDK и WinUI — не одно и то же: WinUI — это UI-часть Windows App SDK. Сам SDK можно добавить и к существующим приложениям на WPF / WinForms / Win32, а такие функции, как App Lifecycle, Windowing и Toast Notifications, иногда удаётся взять, сохранив текущий UI. То есть можно остаться на существующем WPF / WinForms и модернизировать только нужные функции Windows; полная смена UI не обязательна.

Об авторе

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

Го Комура

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

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