Если ты вытягиваешь очень длинную строку типа NVARCHAR(MAX) через await ToListAsync(), Entity Framework начинает творить дичь = запрос становится медленным, а потребление памяти взлетает. Хотя, если быть точным, дело не в самом EF — основная работа ложится на Microsoft.Data.SqlClient. Проблема в том, что он неправильно использует SqlDataReader, из-за чего происходят лишние аллокации и запрос тормозит.

Апдейт: речь в основном про реализацию для SQL Server, так как она использует пакет Microsoft.Data.SqlClient. Чтобы понять, зацепила ли тебя эта проблема, просто глянь зависимости в проекте, есть ли там именно этот пакет.

Вот бенчмарк от Wraith2:

BenchmarkDotNet v0.14.0, Windows 11 (10.0.26100.2314)
.NET SDK 9.0.200
  [Host]     : .NET 8.0.13 (8.0.1325.6609), X64 RyuJIT
  DefaultJob : .NET 8.0.13 (8.0.1325.6609), X64 RyuJIT


| Method | UseContinue | Mean      | Error     | StdDev    | Gen0      | Gen1      | Gen2      | Allocated |
|--------|--------------|----------:|----------:|----------:|----------:|----------:|----------:|----------:|
| Async  | False        | 757.51 ms | 15.053 ms | 36.642 ms | 2000.0000 | 1000.0000 |         - | 101.49 MB |
| Sync   | False        |  39.40 ms |  0.543 ms |  0.508 ms | 2000.0000 |  888.8889 |  777.7778 |  80.14 MB |

Источник: https://github.com/dotnet/SqlClient/pull/3161

Он пофиксил эту проблему серией PR-ов, растянувшихся почти на пять лет. Это и круто, и немного безумно. Конечно, не пять лет подряд, но всё равно впечатляет.

Последние релиз-ноты можно почитать тут:
https://github.com/dotnet/SqlClient/blob/main/release-notes/6.1/6.1.0-preview1.md

Результаты такие:

| Method | UseContinue | Mean      | Error     | StdDev    | Gen0      | Gen1      | Gen2      | Allocated |
|--------|--------------|----------:|----------:|----------:|----------:|----------:|----------:|----------:|
| Async  | True         |  49.45 ms |  0.901 ms |  1.376 ms | 4333.3333 | 3555.5556 | 1111.1111 | 101.51 MB |
| Sync   | True         |  40.09 ms |  0.476 ms |  0.445 ms | 2000.0000 |  888.8889 |  777.7778 |  80.14 MB |

Остаётся примерно 20% разницы по аллокациям, но разрыв уже почти закрыт. Отличная работа от Wraith2 и всей команды. Можно протестировать новую версию пакета даже если ты работаешь через EF — прямые зависимости перекрывают транзитивные. Или просто подожди следующий релиз EF, где уже будет обновлённый Microsoft.Data.SqlClient.

Финальный стабильный релиз 6.1 уже совсем близко.

👉 @KodBlog

Идемпотентность не зависит от HTTP-статусов. Она относится только к состоянию сервера.

Это довольно частое заблуждение у разработчиков: операция может оставаться идемпотентной, даже если сервер возвращает разные коды ответов. Главное, чтобы повторные запросы не меняли состояние системы.

Пример:

Запрос                            Ответ
DELETE /products/123              204
DELETE /products/123              404

Даже если второй запрос возвращает 404 (потому что ресурса уже нет), операция всё равно идемпотентна, при условии, что повторное удаление не вызывает новых побочных эффектов.

👉 @KodBlog

Странный техно-эксперимент:

Парень использовал RayLib C# для генерации визуала, запускал всё в ASP.NET webhost, снимал пиксельные кадры, превращал их в HTML-div-ы как пиксели, и слал эти div-ы в браузер через Server-Sent Events.
Получилось что-то вроде стриминга гипермедиа-приложения или игры — без WebGL, без видео, чисто поток div-ов.

Безумие? Да. Гениально? Тоже да.

👉 @KodBlog

Не выкатывай приложение, работающее с Kafka, в прод, без нагрузочного тестирования

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

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

Kafka-пайплайн может работать идеально в девелоперской среде, где трафик минимальный.
Но в проде неожиданные пики нагрузки легко вскрывают скрытые проблемы:

• проблемы с конкурентным доступом;
• неверные настройки для обработки backpressure;
• узкие места в I/O или сериализации при обработке сообщений;
• неправильное партиционирование, из-за которого нагрузка на консьюмеров распределяется неравномерно;
• неверно рассчитанное масштабирование числа консьюмеров под ожидаемую нагрузку;
• некорректное использование Kafka-транзакций, требующих координации;
• задержки commit-ack от нод.

В зависимости от твоего кейса, объёма данных, формата сообщений, сетевых условий, железа, конфигурации и качества кода, при работе с Kafka могут возникать разные проблемы:

• потеря или дублирование сообщений;
• перегрузка или падение брокеров;
• уязвимости или нарушения требований безопасности и комплаенса.

Для многих компаний скорость Kafka-пайплайна критична - особенно если она влияет на SLA.
Когда задаются SLO или SLA, латентность конкретных потоков должна оставаться стабильной, что делает задачу по обеспечению скорости и эффективности пайплайна ещё сложнее.

NBomber - мощный инструмент для симуляции реальной нагрузки на Kafka в .NET-приложениях.
Он позволяет тестировать продюсеров, консьюмеров и end-to-end флоу с помощью сценариев, написанных на C# или F#.

С NBomber можно:
• измерять полную латентность между продюсером и консьюмером;
• отслеживать, как меняется throughput при росте нагрузки;
• определять момент, когда консьюмер начинает отставать от продюсера.

Я использовал NBomber для нагрузочного тестирования боевого Kafka-пайплайна системы Fraud Detection, построенной на микросервисах.

👉 @KodBlog

Я как кодер довольно щепетилен в разнице между цифрой 0 и буквой O.

В конце созвона саппорт продиктовал мне номер тикета:

четыре, один, восемь, T, A, два, «ОУ»

Зная, что обычные люди вечно путают, я уточнил:

«Это ноль, цифра? Или O, буква?»

(долгая пауза)

«Это ноль, буква.»

👉 @KodBlog

Разбор самой жёсткой уязвимости в .NET. Request smuggling и CVE-2025-55315

https://andrewlock.net/understanding-the-worst-dotnet-vulnerability-request-smuggling-and-cve-2025-55315/

В статье объяснили, что такое request smuggling, разбирают свежую дыру в AspNetCore с критичностью 9.9 и показывают, как атакеры могут это дело использовать.

👉 @KodBlog

Проект на выходных: змейка на C#

Код получился кривоватый. Уверен, есть тысяча способов сделать это лучше. Я просто пытался сам допереть, как всё работает.

Немного олдскульной ностальгии по Nokia.

👉 @KodBlog

Только что вышел Minecraftonia — воксельный движок на C# 13/.NET 9 и Avalonia. В проекте экспериментируют с кастомным воксельным рейтрейсингом, процедурной генерацией террейна и отзывчивым десктопным интерфейсом, при этом всё полностью кроссплатформенно.

Ссылка на релиз: https://github.com/wieslawsoltes/Minecraftonia/releases/tag/v0.1.0

👉 @KodBlog

В Entity Framework Core ToDictionaryAsync (и синхронный ToDictionary) вытягивают из базы весь объект целиком.

Если глянуть на сигнатуру ToDictionaryAsync:

public static Task<Dictionary<TKey, TElement>> ToDictionaryAsync<TSource, TKey, TElement>(
    this IQueryable<TSource> source,
    Func<TSource, TKey> keySelector,
    Func<TSource, TElement> elementSelector,
    CancellationToken cancellationToken = default)
    where TKey : notnull
    => ToDictionaryAsync(source, keySelector, elementSelector, comparer: null, cancellationToken);

Аргументы тут обычные лямбды (Func<TSource, ...>), а не выражения (Expression<Func<...>>). Значит, вычисление этих селекторов происходит на клиенте.

Допустим, у нас есть такой класс:

public class BlogPost
{
    public int Id { get; set; }
    public required string Title { get; set; }
    public required string Description { get; set; }
    public required string Content { get; set; }
    public required string Author { get; set; }
}

И вот такой запрос:

return await dbContext.BlogPosts
    .Where(...)
    .ToDictionaryAsync(k => k.Author, v => v.Title);

Звучит красиво, но по факту EF притащит не только Author и Title, а вообще все поля, например, и Content тоже. На это есть issue, и я случайно наткнулся и офигел.

Как обойти проблему: сначала спроецировать данные через Select, это уже выполнится на стороне сервера:

return await dbContext.BlogPosts
    .Where(...)
    .Select(s => new { Author = s.Author, Title = s.Title })
    .ToDictionaryAsync(k => k.Author, v => v.Title);

👉 @KodBlog

Мне очень нравится, что в C# 14 убрали лишнюю возню, связанную с полями, лежащими в основе свойств.

Особенно круто для таких штук, как INotifyPropertyChanged, потому что больше не нужен отдельный приватный field только ради вызова уведомления.

Ссылка: https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-14#the-field-keyword

👉 @KodBlog

Перемещение Файлов и Папок в Корзину в .NET

При работе с файлами и папками в .NET-приложениях на Windows иногда нужно отправлять объекты в корзину, а не удалять их насовсем (File.Delete, Directory.Delete). Это позволяет пользователю восстановить случайно удалённые данные. Вот как сделать это через Windows Shell API:

static void MoveToRecycleBin(string path)
{
  var shellType = Type.GetTypeFromProgID("Shell.Application", throwOnError: true)!;
  dynamic shellApp = Activator.CreateInstance(shellType)!;

  // https://learn.microsoft.com/en-us/windows/win32/api/shldisp/ne-shldisp-shellspecialfolderconstants?WT.mc_id=DT-MVP-5003978
  var recycleBin = shellApp.Namespace(0xa);

  // https://learn.microsoft.com/en-us/windows/win32/shell/folder-movehere?WT.mc_id=DT-MVP-5003978
  recycleBin.MoveHere(path);
}

Этот метод подходит и для файлов, и для каталогов:

MoveToRecycleBin(@"C:\path\to\file.txt");
MoveToRecycleBin(@"C:\path\to\directory");

👉 @KodBlog

От чат‑бота к агентам: Microsoft Agent Framework в .NET

Microsoft опубликовала руководство по переходу с обычных чат-ботов на AI-агентов в .NET. В примерах показывают, как подключить Microsoft Agent Framework к AI-шаблонам, зарегистрировать агента в Program.cs, вынести поиск в инструмент через SearchAsync, настроить Azure OpenAI и векторное хранилище, а также включить телеметрию через OpenTelemetry и тестирование в .NET Aspire.

Есть упоминание расширений, мультиягентов, кастомного middleware и развёртывания в Azure с рабочими примерами. Агент уже не болтает, а самостоятельно решает задачи.

👉 @KodBlog

Requestum — новая быстрая и бесплатная альтернатива MediatR

После новостей о коммерциализации MediatR разработчики начали искать замену. Автор представил Requestum — open source-медиатор под MIT-лицензией, с упором на производительность и простоту миграции.

Библиотека явно разделяет команды, запросы и события, использует отдельные Execute/Handle/Publish, поддерживает sync и async middleware, а также множественных подписчиков. Интеграция с DI минимальная, можно подменить MediatR почти без правок кода.

Бенчмарки показывают ускорение на 20–50% и снижение аллокаций на 30–60%. API прозрачный, CQRS-подход сохраняется, а синхронные обработчики работают реально синхронно.

Requestum уже доступен на NuGet, исходники на GitHub. Хороший вариант для тех, кто не хочет зависеть от лицензий и хочет выжать максимум из .NET-медиатора.

Читать подробнее: https://habr.com/ru/articles/961936/

👉 @KodBlog

Совет по Visual Studio:

Когда создаешь метод, который возвращает JSON через raw string literal, добавь

/* lang=json*/

Этот момент нигде не задокументирован. Если в JSON будет синтаксическая ошибка вроде пропущенной запятой, Visual Studio подсветит её.

👉 @KodBlog

Тестируй API прямо в браузере

Есть опенсорсный инструмент Hoppscotch. Позволяет тестировать, дебажить и шарить API прямо из веб-браузера.

Отличная альтернатива Postman. Легкий и быстрый.

👉 @KodBlog

Конструкторное внедрение зависимостей и программирование через интерфейсы – основа хорошо тестируемого кода.

Слева: код Боба в PR
Справа: код Дейва в PR

Код Боба проходит ревью
Код Дейва заворачивают

Будь как Боб.

👉 @KodBlog

Критические изменения в Entity Framework 10

https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-core-10.0/breaking-changes

👉 @KodBlog