Extension members в C# 14, пожалуй, лучшее, что Microsoft добавила в язык. Теперь можно писать такой чистый и лаконичный код.

👉 @KodBlog

Новая версия AsyncAwaitBestPractices v10.0.0

✅Добавлена поддержка .NET 10

Та самая библиотека async/await, которую все любят, теперь собрана и оптимизирована под .NET 10.

👉 @KodBlog

Оптимизация запроса в EF Core снизила время выполнения с 30 секунд до 30 миллисекунд.

Вот какие шаги помогли

Исходный запрос был из реального проекта соцсети.

Сущности и связи:

Users — у каждого много постов и комментариев

Comments — привязаны к юзеру и посту

Categories — у постов есть категория

Posts — имеют категорию и множество лайков

Likes — относятся к конкретному посту

Задача:

Выбрать топ 5 пользователей, которые оставили больше всего комментариев за последние 7 дней под постами категории .NET.

Для каждого нужно вернуть:

- UserId
- Username
- количество комментариев (только под .NET постами за последние 7 дней)
- топ 3 .NET поста по лайкам, которые этот пользователь чаще всего комментировал (PostId, LikesCount)

Что было сделано для ускорения:

- Предфильтрация пользователей
- Ограничение до топ-5
- Сокращение числа JOIN
- Проекция только нужных полей
- Формирование результата в одном запросе
- Использование AsSplitQuery
- Трехфазный подход
- Двухфазный подход

Подробности можно посмотреть здесь

👉 @KodBlog

WinForms приложения на .NET Framework можно переехать в web на .NET 9+ и задеплоить в Azure App Services через Visual Studio и copilot за пару минут.

Вся логика приложения и бизнес-код сохраняются.
Сочетание Visual Studio 2026 и GitHub Copilot творит вещи.

👉 @KodBlog

Ты уже смотрел на новый IExceptionHandler?

Исключения как-то обрабатывать все равно нужно.

IExceptionHandler реализует паттерн с префиксом Try-.
Ты сам решаешь, какие исключения обрабатывать.

Чтобы сообщить middleware, что ты обработал исключение, нужно вернуть true.

Так что же делает это таким интересным?

Можно выстраивать несколько обработчиков исключений в цепочку, и они будут вызываться по очереди.
Первый, который успешно обработает исключение, прерывает цепочку.

Вот как использовать это в .NET 10: читать

👉 @KodBlog

Понимание паттерна Observer это одна из базовых вещей, которую должен знать любой frontend-разработчик.

// Наблюдатели, которые выполняют Update, когда получают уведомление
interface IObserver
{
    void Update(string message);
}

// Субъект, который уведомляет подписанных наблюдателей
interface ISubject
{
    // Регистрация, удаление и уведомление наблюдателей
    void Register(IObserver observer);
    void Unregister(IObserver observer);
    void Notify(string message);
}

// Конкретная реализация субъекта, который рассылает обновления подписчикам
class ConcreteSubject : ISubject
{
    private readonly List<IObserver> observers = new();

    public void Register(IObserver observer)
    {
        observers.Add(observer);
    }

    public void Unregister(IObserver observer)
    {
        observers.Remove(observer);
    }

    public void Notify(string message)
    {
        foreach (var observer in observers)
        {
            observer.Update(message);
        }
    }
}

// Конкретная реализация наблюдателя, который реагирует на уведомления субъекта
class ConcreteObserver : IObserver
{
    private readonly string name;

    public ConcreteObserver(string name)
    {
        this.name = name;
    }

    public void Update(string message)
    {
        Console.WriteLine($"{name} получил сообщение: {message}");
    }
}

// Создаем субъект и наблюдателей
var subject = new ConcreteSubject();
var observer1 = new ConcreteObserver("Наблюдатель 1");
var observer2 = new ConcreteObserver("Наблюдатель 2");

// Подписываем наблюдателей на субъект
subject.Register(observer1);
subject.Register(observer2);

// Субъект меняет состояние и уведомляет подписчиков
subject.Notify("Состояние изменилось.");
subject.Notify("Доступно новое обновление.");

👉 @KodBlog

Это приложение прям отличный вариант для разработчиков. Показывает, какие порты у тебя открыты, и позволяет закрыть любой в один клик.

Опенсорсное и работает на Windows, Linux и macOS.

👉 @KodBlog

Есть два способа настроить оптимистичный контроль конкурентности в EF Core:

1. Использовать атрибут [Timestamp] в модели сущности

2. Определить поле row version через Fluent API

👉 @KodBlog

Производительность платежной системы в проде была увеличена примерно в 15 раз — всего одной строкой кода в EF Core

Система обрабатывает массовые платежи, разбивая один запрос на множество аккаунтов получателей.

В тестах всё работало нормально, но при переходе в прод с реальными объёмами данных API стал тратить секунды на обработку одного запроса по нескольким тысячам счетов.

Каждый платежный запрос делает выборку из таблицы payment_accounts, чтобы определить счета, которые еще не были полностью оплачены.

Тест на 19 000 аккаунтов в SQL Server показал время обработки: 8.22 секунды.

Требование SLA (p99): 1 секунда.
API был примерно в 8 раз медленнее порога SLA.

Основная проблема оказалась в методе SaveChangesAsync.

EF Core умеет группировать несколько вставок, но база данных все равно выполняет их по отдельности.

В SQL Server EF Core использует оператор MERGE для массовых вставок, но подход ограничен лимитом SQL-параметров (2100 на батч). Если у сущностей много полей = производительность быстро падает.

После оптимизаций стало понятно, что штатными инструментами EF Core не удастся добиться нужной скорости.

Решением стала библиотека Entity Framework Extensions.

Она даёт простой, гибкий и быстрый способ для bulk-вставок, позволяя вставлять тысячи записей за один запрос к базе.

Методы BulkInsert и BulkInsertOptimized позволяют выполнить массовую вставку буквально одной строкой кода.

С их помощью время вставки удалось снизить до 521 мс, что укладывается в SLA.

👉 @KodBlog

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

Почему так происходит? Потому что без change tracker EF Core не делает identity resolution - он не проверяет, была ли эта сущность уже загружена ранее. В итоге можно получить несколько объектов, которые на самом деле представляют одну и ту же запись в базе.

Пример:

var orders = await context.Orders
    .AsNoTracking()
    .Include(o => o.Customer)
    .Where(o => o.OrderDate > DateTime.Now.AddDays(-30))
    .ToListAsync();

Если у нескольких заказов один и тот же пользователь, то Customer будет склонирован под каждый заказ. То есть:

• больше памяти
• сравнение сущностей по ссылке становится бесполезным
• нарушается связность графа объектов

Решение — AsNoTrackingWithIdentityResolution()

Этот метод даёт баланс:

• нет change tracking (то есть быстрый чтение-only режим)
• есть identity resolution (одна сущность — один объект)

Пример:

var orders = await context.Orders
    .AsNoTrackingWithIdentityResolution()
    .Include(o => o.Customer)
    .Where(o => o.OrderDate > DateTime.Now.AddDays(-30))
    .ToListAsync();

Теперь все заказы, у которых один и тот же Customer, будут ссылаться ровно на один объект пользователя.

Как это работает внутри:

• запрос выполняется без отслеживания
• EF Core создаёт временную identity map
• сущности с одинаковым ключом получат одинаковый объект
• карта удаляется после завершения запроса

То есть tracking нет, но дубликатов тоже нет.

Если это поведение нужно часто, его можно включить по умолчанию:

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    optionsBuilder
        .UseSqlServer(connectionString)
        .UseQueryTrackingBehavior(QueryTrackingBehavior.NoTrackingWithIdentityResolution);
}

Когда использовать:

1. Отслеживание по умолчанию:

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

2. AsNoTracking:

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

3. AsNoTrackingWithIdentityResolution:

- операции только чтения с include/join;
- требуется ссылочная целостность в графе объектов;
- запросы, возвращающие одну сущность несколько раз;
- требуется сравнивать сущности по ссылке.

👉 @KodBlog

Visual Studio 2026 официально вышла.

Раньше обновление Visual Studio автоматически тянуло за собой обновление .NET и C++ toolchain. Один пакет значит один риск. Хотел новые фичи IDE? Заодно получай новые компиляторы, нужные они тебе или нет.

В VS 2026 это разделили. IDE обновляется отдельно. Новые фичи прилетают раз в месяц. Build tools остаются в нужной версии.

Производительность подтянули по всем направлениям. Количество UI фризов уменьшилось на 50%. Запуск под F5 стал быстрее на 30% вместе с .NET 10. Большие решения загружаются ощутимо быстрее, а не только формально по цифрам.
Code coverage больше не только в Enterprise.

Теперь он доступен во всех версиях. Разработчики на Community и Professional могут анализировать покрытие тестами без апгрейда лицензии.

Интеграция с AI стала глубже. Copilot теперь понимает внешние символы в C#, а не только твой проект. Он может подтягивать контекст по URL. Debugger агент умеет автоматически чинить упавшие unit-тесты: предполагает причину, правит, проверяет и повторяет цикл, пока тест не пройдет.

Обратная совместимость полная. Проекты из VS 2022 открываются напрямую. Все 4000+ расширений работают без правок. Никакой миграции.

Fluent UI — самое заметное изменение, но далеко не главное. Главное то, что IDE стала быстрее, стабильнее и обновляется без принудительных обновлений compiler toolchain.

Что попробовать в первую очередь:
- Открой свою самую тяжелую solution и почувствуй разницу
- Запусти code coverage в Community/Professional
- Дай debugger агенту починить упавший тест

Уже доступно. Проекты и расширения из VS 2022 переносятся автоматически.

👉 @KodBlog

Поддержка Server-Sent Events (SSE)

В ASP.NET Core теперь можно возвращать результаты в формате ServerSentEvents через API TypedResults.ServerSentEvents. Эта фича работает как в Minimal APIs, так и в контроллерах.

Server-Sent Events это механизм push-уведомлений, где сервер может отправлять поток событий клиенту по одному HTTP-соединению. В .NET каждое сообщение представлено как SseItem<T>, где может быть тип события, его ID и payload типа T.

В TypedResults появилась новая статическая функция ServerSentEvents, которая возвращает результат типа ServerSentEvents. Первый аргумент это IAsyncEnumerable<SseItem<T>> — поток событий, который будет отправляться клиенту.

Ниже пример, как с помощью TypedResults.ServerSentEvents стримить JSON-события с данными пульса:

app.MapGet("/json-item", (CancellationToken cancellationToken) =>
{
    async IAsyncEnumerable<HeartRateRecord> GetHeartRate(
        [EnumeratorCancellation] CancellationToken cancellationToken)
    {
        while (!cancellationToken.IsCancellationRequested)
        {
            var heartRate = Random.Shared.Next(60, 100);
            yield return HeartRateRecord.Create(heartRate);
            await Task.Delay(2000, cancellationToken);
        }
    }

    return TypedResults.ServerSentEvents(
        GetHeartRate(cancellationToken), 
        eventType: "heartRate"
    );
});

👉 @KodBlog

Хватит выкатывать релиз каждый раз, когда появляется новый фильтр.

Пусть фильтры обновляются сами.

Что если твой LINQ Where принимал бы правило во время выполнения и при этом оставался нормальным SQL-транслируемым запросом?

Хардкодить фильтры кажется нормальным… пока продукт не приходит с очередным запросом: "добавьте ещё одно поле".

И вот уже вокруг if-джунгли, дублированные запросы и новый деплой ради мелкой правки. Динамические предикаты меняют всё → правила живут в конфиге/БД/UI, а код остаётся компактным и стабильным.

Где это реально помогает:

• Админки и отчёты → пользователь комбинирует поля/условия без твоих доп. веток.
• Поисковые API: query-string/JSON → динамический предикат, без плясок с expression trees.
• Multi-tenant/white-label → у каждого клиента свои правила, ты просто загружаешь и применяешь.
• Сегменты пользователей → маркетинг собирает аудитории вроде
"Активен в DACH И (последние 90 дней ИЛИ ≥ 500€) И подписан на рассылку" - без релиза.

Зачем оно нужно:

• Меньше условных веток → чище код и проще тестирование.
• Гибкость на рантайме → быстрее итерации, меньше релизов.
• Всё ещё IQueryable → EF прогоняет фильтры в SQL, а не в память.

Полезные практики:

• Ввести whitelist допустимых полей/операторов (безопасность и предсказуемость).
• Валидировать правила до сборки предиката.
• Оставлять всё на IQueryable до конца (пускай EF делает работу).
• Унифицировать формат дат и параметров, чтобы не ловить культуру-зависимые баги.
• Добавить snapshot-тесты для сохранённых фильтров/сегментов.

Когда это не нужно = если у вас всего 2–3 фиксированных фильтра, которые редко меняются, обычный LINQ проще и надёжнее.

Если у тебя когда-то было ощущение "я пишу фичи, а не переписываю запросы", значит этот подход тебе зайдёт.

Полный гайд и примеры

👉 @KodBlog

Использование Git Conditional Includes для нескольких конфигураций

Когда работаешь с несколькими репозиториями Git, часто нужны разные настройки под разные контексты. Например, можно использовать личную почту для open-source проектов и рабочую почту для корпоративных репозиториев. Да, можно настроить Git глобально или в каждом репозитории вручную, но со временем это становится муторно и легко ошибиться.

Функция Git conditional includes решает эту проблему = она автоматически применяет нужную конфигурацию в зависимости от условий вроде пути репозитория, URL remotes или имени ветки. В итоге нужные настройки подтягиваются сами - без ручных переключений.

Вот пример, который подключает отдельную конфигурацию, если работаешь с личными репозиториями GitHub:

[includeIf "hasconfig:remote.*.url:https://github.com/meziantou/*"]
    path = .gitconfig-github-personal

Git проверяет remotes и если URL совпадает с шаблоном, он автоматически подгружает настройки из .gitconfig-github-personal, где, например, могут храниться твоя личная почта и ключ подписи.

Понимаем, как работают Git Conditional Includes

Git поддерживает несколько типов условий для conditional includes. Каждый подходит под свой сценарий.

gitdir - совпадение по пути репозитория

Условие gitdir срабатывает, если путь к репозиторию совпадает с заданным. На Unix-системах проверка чувствительна к регистру.

[includeIf "gitdir:~/personal/"]
    path = .gitconfig-personal

[includeIf "gitdir:~/work/"]
    path = .gitconfig-work

Так настройки .gitconfig-personal применяются ко всем репозиториям под ~/personal/, а .gitconfig-work к тем, что в ~/work/.

gitdir/i - совпадение по пути без учета регистра

То же самое, что gitdir, но нечувствительное к регистру. Полезно на Windows или когда нужен более гибкий матчинг.

[includeIf "gitdir/i:c:/projects/company/"]
    path = .gitconfig-company

onbranch - совпадение по текущей ветке

Это условие подключает конфигурацию в зависимости от того, какая ветка сейчас checkout -нута.

[includeIf "onbranch:main"]
    path = .gitconfig-production

[includeIf "onbranch:feature/**"]
    path = .gitconfig-development

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

hasconfig - совпадение по существующей настройке Git

Это условие проверяет, существует ли конкретная настройка и подходит ли под шаблон. Особенно полезно, чтобы матчить remote-URL.

[includeIf "hasconfig:remote.*.url:https://github.com/meziantou/*"]
    path = .gitconfig-github-personal

[includeIf "hasconfig:remote.*.url:[email protected]:*/**"]
    path = .gitconfig-company

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

👉 @KodBlog

API Gateway и Load Balancer часто путают новички, но это база для любого бэкенд разработчика

API Gateway  работает как входная точка

• это единая точка, куда стучатся клиенты, он берет на себя всю первичную обработку запросов
• умный слой, который управляет авторизацией и аутентификацией (AuthN), rate limiting, логированием, мониторингом запросов и маршрутизацией
• идеально подходит для микросервисов, потому что централизует управление API во всей системе
• работает на уровне приложения L7

Load Balancer  работает как распределитель трафика

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

API Gateway управляет, валидирует и контролирует API запросы (про сложность)

Load Balancer равномерно распределяет трафик и оптимизирует нагрузку (про производительность)

👉 @KodBlog