Таймаут в ASP.NET Core не гарантирует остановку выполнения

Middleware для ограничения времени выполнения в ASP.NET Core отменяет токен отмены (CancellationToken), но не останавливает поток принудительно и не заставляет endpoint немедленно вернуть ответ.

Чтобы таймаут действительно помогал, токен должен передаваться по всей цепочке вызовов: от endpoint через сервисы до EF Core или HttpClient. При этом вызываемый код тоже должен поддерживать отмену.

В примере из статьи для endpoint установлен лимит в 3 секунды. Но если внутри него выполняется десятисекундная задержка, которая игнорирует токен отмены, обработка может продолжиться и завершиться ответом 200 OK.

Проверить поведение можно в двух сценариях: когда операция корректно реагирует на отмену и когда игнорирует её. Тестировать нужно без подключённого отладчика — в описанном примере таймаут не срабатывает под отладчиком.

Разбор настройки таймаутов и обработки отмены в ASP.NET Core

👉 @KodBlog

7 архитектур .NET, которые должен знать каждый разработчик в 2026 году

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

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

Монолитная архитектура (Monolithic Architecture). Подходит для небольших приложений, MVP и проектов с простой предметной областью. Такие приложения быстро разрабатывать, но их масштабирование со временем может стать сложнее.

Многоуровневая архитектура (N-Tier Architecture). Классический подход с чётким разделением ответственности между уровнями. Идеально подходит для корпоративных приложений, хотя компоненты всё ещё могут оставаться тесно связанными.

Чистая архитектура (Clean Architecture). Предполагает независимость бизнес-логики от фреймворков и пользовательского интерфейса. Отлично подходит для систем, которые должны оставаться удобными в поддержке и тестировании в долгосрочной перспективе.

Архитектура вертикальных срезов (Vertical Slice Architecture). Организует код по функциональным возможностям, а не по слоям. Хорошо подходит для гибких команд и позволяет быстрее разрабатывать новые функции.

Микросервисная архитектура (Microservices Architecture). Подходит для крупных систем, которым необходимы независимое развёртывание компонентов и высокая масштабируемость. Однако такой подход усложняет эксплуатацию и поддержку инфраструктуры.

CQRS (Command Query Responsibility Segregation). Разделяет операции чтения и записи данных. Особенно полезен для высоконагруженных систем и приложений со сложной бизнес-логикой.

Событийно-ориентированная архитектура (Event-Driven Architecture). Обеспечивает слабую связанность компонентов и обработку событий в реальном времени. Подходит для распределённых систем и интеграции различных сервисов.

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

👉 @KodBlog

Обрати внимание, где именно расположен ToList() в этом посте про Entity Framework, который я сегодня увидел в LinkedIn.

СПОЙЛЕР: Оба варианта генерируют практически одинаковый SQL-запрос (за исключением того, что в правом варианте столбец City не выбирается).

Однако мне больше нравится правый вариант, где Where стоит перед Select, — с точки зрения стиля и читаемости кода.

👉 @KodBlog

Clean Architecture нужна не каждому .NET-проекту

При разработке на ASP.NET Core легко увлечься архитектурой и создать несколько слоёв абстракций даже для простых функций. Но иногда Vertical Slice Architecture (VSA) позволяет писать код проще и быстрее.

Вместо разделения приложения на слои VSA группирует код по функциям и сценариям: например, CreateOrder, GetOrder и CancelOrder. Внутри каждого слайса находятся необходимые обработчики, валидация, модели запросов и ответов.

В чём преимущества VSA?

— Меньше лишних абстракций и шаблонного кода.
— Изменения одной функции реже затрагивают остальные.
— Проще ориентироваться в коде и добавлять новые возможности.
— Не нужно создавать интерфейс и репозиторий для каждой операции, если они не приносят реальной пользы.

Это не значит, что Clean Architecture устарела. Она по-прежнему отлично подходит проектам со сложной бизнес-логикой и строгими архитектурными границами.

Практичный подход — начать с Vertical Slice Architecture и добавлять слои и абстракции по мере необходимости. При этом важно следить, чтобы логика не дублировалась между слайсами.

👉 @KodBlog

Кто я такой, чтобы спорить 🦀

👉 @KodBlog

HTTPS-редиректа недостаточно для защиты приложения ASP.NET Core

Многие разработчики включают UseHttpsRedirection() и считают, что приложение защищено. Но есть ещё один важный механизм безопасности, о котором не стоит забывать, — HTTP Strict Transport Security (HSTS).

Разберёмся, как они работают вместе.

1. HTTPS-редирект: UseHttpsRedirection()
Автоматически перенаправляет входящие HTTP-запросы на HTTPS. Например: http://example.com → https://example.com

Однако первый HTTP-запрос всё ещё может передаваться по незащищённому соединению до выполнения перенаправления.

2. HSTS: UseHsts(). HSTS указывает браузеру использовать для домена только HTTPS. Получив заголовок HSTS по защищённому соединению, браузер:

• Автоматически переключает последующие HTTP-запросы на HTTPS.
• Не позволяет пользователю обойти предупреждение о недействительном сертификате.
• Помогает защититься от атак, связанных с понижением версии протокола.

3. Настройка обоих механизмов в ASP.NET Core

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddHsts(options =>
{
    options.MaxAge = TimeSpan.FromDays(365);
    options.IncludeSubDomains = true;
});

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseHsts();
}

app.UseHttpsRedirection();

app.MapGet("/", () => "Secure API");

app.Run();

Здесь HSTS действует в течение одного года, а директива IncludeSubDomains распространяет его действие на поддомены.

Важно: включайте IncludeSubDomains, только если все поддомены поддерживают HTTPS.

4. Что учитывать в production

• Обратные прокси. Если используются AWS ALB, Nginx или другой reverse proxy, завершение HTTPS-соединения и перенаправление могут выполняться на уровне инфраструктуры.

• Forwarded-заголовки. При необходимости настройте UseForwardedHeaders() для доверенных прокси до UseHttpsRedirection(). Иначе приложение может неправильно определять схему запроса и создавать циклы перенаправлений.

• Web API. HSTS применяется преимущественно браузерами. Для API, которыми пользуются мобильные приложения и другие клиенты, необходимо обеспечивать HTTPS на уровне сервера или инфраструктуры, а не полагаться на редиректы.

• HSTS Preload. Рассматривайте предварительное включение домена в список HSTS только тогда, когда весь домен и все его поддомены постоянно готовы работать через HTTPS.

Рекомендация: обеспечивайте принудительное использование HTTPS на границе инфраструктуры, а для приложений, доступных через браузер, дополнительно используйте HSTS. Важно, чтобы оба механизма были настроены согласованно.

👉 @KodBlog

10 причин, почему macOS лучше Windows для .NET-разработчиков

Visual Studio работает только на Windows. И всё же для большинства .NET-разработчиков macOS может оказаться более удобной рабочей машиной.

Автор больше 13 лет разрабатывает приложения на .NET и на Windows, и на Mac. Вот его сравнение обеих платформ. 10 причин выбрать macOS

1. Unix-подобная система. Пути к файлам, права доступа и shell-скрипты работают ближе к тому, как они устроены на Linux-серверах и в контейнерах, куда вы деплоите приложения.

2. Более удобная работа с Docker. Linux-контейнеры запускаются без типичных проблем WSL, таких как чрезмерное потребление памяти, сетевые сбои и проблемы с синхронизацией файлов.

3. Производительность Apple Silicon. .NET работает нативно на ARM64. Чипы серии M быстро собирают большие проекты и при этом почти не шумят.

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

5. Отличные IDE. JetBrains Rider и VS Code с ReSharper или C# Dev Kit работают на macOS нативно и предоставляют полноценные возможности для разработки.

6. Homebrew. Одна команда позволяет установить .NET SDK, Node.js, базы данных и CLI-инструменты, а затем обновлять их.

7. Качество оборудования. Чёткий экран, удобный трекпад и корректно работающий спящий режим.

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

9. Чистая система. Меньше предустановленного ПО и никакой рекламы в системном интерфейсе.

10. Все цели для .NET MAUI на одном устройстве. Для сборки и подписания приложений под iOS и macOS нужен Mac. На нём можно разрабатывать приложения для Android, iOS и macOS в одном окружении.

5 причин выбрать Windows

1. Полноценная Visual Studio. Расширенные инструменты отладки, визуальные дизайнеры и профилировщики. Visual Studio for Mac закрыли в 2024 году. Если вы привыкли к Visual Studio и не хотите переходить на Rider или VS Code, Windows остаётся основным вариантом.

2. Разработка десктопных приложений. WPF, Windows Forms и WinUI предназначены для Windows и требуют Windows для полноценного запуска и отладки.

3. Старые проекты на .NET Framework. Устаревшие приложения на .NET Framework и ASP.NET могут требовать Windows, особенно если используют специфичные для этой платформы технологии.

4. SQL Server и SSMS. Оба инструмента нативно работают на Windows. На Mac SQL Server можно запустить в Docker, а SQL Server Management Studio (SSMS) не поддерживается нативно.

5. Цена и выбор оборудования. Больше производителей, возможность самостоятельно обновлять оперативную память и накопители, а также более высокая производительность за те же деньги у многих конфигураций.

Большинство новых .NET-приложений работают в Linux-контейнерах. Поэтому Unix-подобная система на ноутбуке может быть ближе к продакшен-окружению, чем Windows.

→ macOS — веб-разработка, облачные сервисы и мобильные приложения.

→ Windows — десктопные приложения и поддержка старых проектов на .NET Framework.

А на чём вы разрабатываете на .NET: macOS, Windows или Linux?

👉 @KodBlog

GitHub ускоряет запись данных в репозитории в 3–4 раза

GitHub меняет механизм блокировок в Spokes: вместо одной блокировки на весь репозиторий будут использоваться отдельные блокировки для каждой ссылки на Git-объект (ref).

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

По результатам внутренних тестов GitHub, новый подход увеличил пропускную способность операций записи в 3–4 раза.

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

👉 @KodBlog

Оператор присваивания с проверкой на null ??=

Оператор ??= появился в C# 8.0 и работает по принципу оператора объединения с null ??.

Он присваивает правому операнду значение только в том случае, если левый операнд равен null.

string? name = null;

name ??= "Developer";

Console.WriteLine(name); // Developer

Если переменная уже содержит значение, оно останется без изменений:

string? name = "Alex";

name ??= "Developer";

Console.WriteLine(name); // Alex

Оператор ??= позволяет сократить код и удобно задавать значения по умолчанию, если переменная ещё не инициализирована.

👉 @KodBlog

Упрощаем работу с коллекциями в C# с помощью Collection Expressions

В C# 12 появились Collection Expressions — выражения коллекций, которые позволяют создавать коллекции с помощью простого и лаконичного синтаксиса [].

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

👉 @KodBlog

7 ошибок с async/await, которые допускают даже Senior .NET-разработчики

После нескольких лет работы с production-приложениями на .NET становится понятно: написать асинхронный код несложно. Гораздо сложнее сделать так, чтобы он правильно работал под высокой нагрузкой.

Вот 7 ошибок, которых стоит избегать.

1. Блокировка асинхронного кода через .Result или .Wait(). Вызовы .Result и .Wait() блокируют текущий поток в ожидании завершения асинхронной операции. В ASP.NET Core это может привести к исчерпанию потоков Thread Pool (Thread Pool Starvation) и снижению пропускной способности приложения.

Как правильно: использовать await на протяжении всей цепочки вызовов.

2. Использование async void вместо async Task. Метод с async void нельзя ожидать через await, а его исключения нельзя перехватить вызывающим кодом с помощью стандартного механизма обработки исключений на основе Task.

Как правильно: возвращать Task или Task<T>. async void стоит использовать только для обработчиков событий, которым необходим такой формат.

3. Забывать await при вызове асинхронного метода. Если вызвать асинхронный метод без await и не отслеживать возвращённый Task, можно потерять исключения или получить операцию, которая продолжит выполняться за пределами ожидаемого жизненного цикла.

Как правильно: использовать await или явно управлять жизненным циклом задачи.

4. Выполнять независимые операции последовательно. Представим, что нужно сделать два независимых API-запроса. При последовательном выполнении второй начнётся только после завершения первого.

Как правильно: запускать обе операции и ожидать их завершения вместе с помощью Task.WhenAll. Это подходит, если операции действительно независимы и безопасны для параллельного выполнения.

5. Игнорировать CancellationToken. Если не передавать сигнал отмены дальше по цепочке вызовов, ресурсоёмкие запросы к базе данных или HTTP-запросы могут продолжать выполняться даже после отключения клиента.

Как правильно: принимать CancellationToken и передавать его через всю цепочку асинхронных вызовов.

6. Считать, что async означает параллельное выполнение. async/await автоматически не создаёт новые потоки и не ускоряет вычислительно сложные операции. Асинхронность в первую очередь позволяет не блокировать поток во время ожидания.

Как правильно: использовать async для операций ввода-вывода (I/O-bound). Task.Run может подойти для некоторых CPU-bound задач, но его применение в обработчиках серверных запросов требует осторожности.

7. Использовать Task.WhenAll без ограничения параллелизма. Одновременный запуск тысяч запросов к базе данных или HTTP-запросов может исчерпать пулы соединений, перегрузить внешние сервисы и увеличить задержки.

Как правильно: ограничивать количество одновременно выполняемых операций с помощью SemaphoreSlim, Parallel.ForEachAsync или других механизмов управления конкурентностью.

Главное: async/await — это не просто способ повысить производительность. Это инструмент управления ресурсами, параллелизмом, отменой операций и обработкой ошибок.

Метод может быть асинхронным, но при этом замедлять приложение, снижать его надёжность и усложнять отладку.

👉 @KodBlog

Автоматическая регистрация зависимостей в ASP.NET Core с помощью Scrutor

Scrutor расширяет встроенный DI-контейнер ASP.NET Core и позволяет автоматически находить и регистрировать сервисы по заданным соглашениям (conventions).

👉 @KodBlog

BenchmarkDotNet в .NET Single-File приложениях

Бенчмарки — отличный сценарий использования одnofайловых приложений (Single-File Apps) в .NET.

В примере показано, как использовать BenchmarkDotNet в таком приложении. Самые важные настройки находятся в начале кода, а также стоит обратить внимание на атрибут [InProcess].

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

👉 @KodBlog

👉 @KodBlog

CQRS без Event Sourcing: используйте сильные стороны EF Core и Dapper

Чтобы получить преимущества CQRS, не обязательно внедрять полноценный Event Sourcing.

Достаточно разделить модели записи и чтения:

• EF Core — для бизнес-правил, доменных агрегатов и операций записи.
• Dapper — для быстрых SQL-запросов и чтения данных.

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

Прагматично, чисто и без лишней сложности.

👉 @KodBlog

Message Brokers гарантируют At-Least-Once, а не Exactly-Once

Что произойдёт, если ваш consumer обработает одно и то же событие дважды? Сможет ли система корректно справиться с повторной доставкой?

Брокеры сообщений часто используют семантику доставки At-Least-Once — событие будет доставлено как минимум один раз, но возможны дубликаты.

Поэтому обработчики событий должны быть идемпотентными (Idempotent): повторная обработка одного и того же события не должна приводить к повторным побочным эффектам.

Разберём, как проектировать идемпотентные обработчики событий и защищать систему от дублирующей обработки.

👉 @KodBlog

Зачем обрабатывать элементы по одному, если процессор может обрабатывать сразу 8?

В C# есть инструменты для использования SIMD (Single Instruction, Multiple Data) — технологии, которая позволяет выполнять одну операцию одновременно над несколькими элементами данных.

Для этого можно использовать Vector<T> и Hardware Intrinsics.

Что они дают?

Vector<T> — позволяет обрабатывать несколько значений одного типа за одну операцию.

Hardware Intrinsics — дают более низкоуровневый доступ к SIMD-инструкциям процессора, например AVX2 и AVX-512.

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

И всё это доступно прямо в C# — без необходимости переходить на C++.

👉 @KodBlog

Учитывают ли ваши C#-структуры кэш-линии процессора?

Неправильное расположение полей структуры приводит к неэффективному использованию памяти и дополнительным затратам на доступ к кэш-линии процессора.

Используйте [StructLayout(LayoutKind.Sequential, Pack = 1)], чтобы контролировать размещение полей в памяти.

👉 @KodBlog

Каждый раз, когда асинхронный метод возвращает Task<T>, при завершении операции выделяется память в куче.

Если ваш метод часто завершается синхронно (например, при попадании в кеш), используйте ValueTask<T>.

Это поможет избежать миллионов лишних выделений памяти (heap allocations).


👉 @KodBlog

Запускаете несколько реплик фонового воркера в Kubernetes?

Локальные блокировки (lock / Monitor) не работают между разными контейнерами.

Используйте распределённые блокировки Redis (Redis Distributed Locks) с fencing-токенами, чтобы предотвратить состояния гонки (race conditions) и избежать одновременного выполнения одной задачи несколькими воркерами.

👉 @KodBlog

Получаете случайные ошибки 502 Bad Gateway во время деплоя в Kubernetes?

Вероятно, ваше .NET-приложение завершает работу до того, как входящий трафик будет перенаправлен на другие экземпляры.

Разберитесь, как правильно настроить graceful shutdown и health probes в ASP.NET Core.

👉 @KodBlog