Ты можешь ловить уязвимости в коде ещё на этапе сборки.

Вот простой способ сделать это в .NET буквально за пару минут.

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

Статический анализ кода позволяет это сделать.

Вот пример ошибки при билде, где меня предупреждают, что мой код для хеширования пароля небезопасен. 👇

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

Если хочешь посмотреть, как настроить это с нуля, загляни в статью

Имей в виду, что такой подход не поймает абсолютно все проблемы.

Если хочешь пойти глубже, посмотри в сторону более мощных инструментов вроде SonarQube.

@KodBlog

Разрабатывать приложения под Windows и добавлять туда AI-функции вроде распознавания изображений, генерации текста и прочего бывает долго и муторно, если настраивать модели и писать всё с нуля.

Поэтому Microsoft выложила в открытый доступ инструмент AI Dev Gallery. Он сделан специально для Windows-разработчиков и помогает быстро подключать модели и интегрировать разные AI-возможности.

Там есть больше 25 интерактивных примеров, которые покрывают работу с изображениями, текстом, голосом и другими задачами. Модели можно сразу просматривать и скачивать с Hugging Face и GitHub.

Каждый пример включает полный исходник на C#, и его можно экспортировать в самостоятельный проект Visual Studio одним кликом, чтобы дальше спокойно дорабатывать.

Установить можно через Microsoft Store или клонировать репозиторий и собрать проект в Visual Studio 2022 или новеe

👉 @KodBlog

Не делайте вот так в EF-запросах

Как решить проблему N+1 ⬇️

Оптимизация производительности:

Запрос внутри цикла:

Если выполнять запрос внутри цикла, будет происходить множество обращений к базе. Это создаёт лишние roundtrip-и и сильно просаживает производительность, особенно при больших выборках или большом количестве итераций.

Запрос вне цикла:

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

👉 @KodBlog

Когда работаешь с Entity Framework Core, важно понимать, как работает слежение за изменениями (change tracking). Это влияет и на производительность, и на корректность данных. Я знал про метод AsNoTracking(), но во время code review наткнулся на менее известную, но очень полезную альтернативу: AsNoTrackingWithIdentityResolution().

Разберёмся, чем этот метод отличается и когда его стоит применять.

Коротко: что делает AsNoTracking()?

Прежде чем перейти к AsNoTrackingWithIdentityResolution, напомним, что делает AsNoTracking(). По умолчанию EF Core отслеживает все полученные сущности в change tracker. Это позволяет:

- автоматически фиксировать изменения объектов
- выполнять обновления без явного Attach
- обеспечивать identity resolution (один объект в памяти на одну запись в базе)

Но отслеживание имеет накладные расходы. Если запрос read-only и обновлять данные не нужно, то AsNoTracking() повышает производительность, отключая tracking целиком.

// Без отслеживания — быстрее для read-only сценариев

var customers = await context.Customers
    .AsNoTracking()
    .ToListAsync();

Хотя AsNoTracking() ускоряет работу, он создаёт тонкий, но важный побочный эффект: дублирующиеся сущности. Так как change tracker не занимается identity resolution, в памяти могут появляться несколько экземпляров одной и той же сущности.

Пример:

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

Если несколько заказов принадлежат одному и тому же пользователю, EF создаст отдельные экземпляры Customer для каждого заказа. В итоге это приводит к:

- лишнему потреблению памяти
- проблемам при сравнении объектов
- потере целостности графа объектов

Появляется AsNoTrackingWithIdentityResolution()

AsNoTrackingWithIdentityResolution() решает эту проблему и даёт баланс между:

- отсутствием tracking (производительность)
- сохранением identity resolution (один объект на сущность)

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

// Теперь несколько заказов с одним Customer будут ссылаться на один экземпляр

Как работает AsNoTrackingWithIdentityResolution():

- EF не добавляет сущности в change tracker
- во время материализации создаётся временная identity map
- сущности с одинаковым ключом указывают на один объект
- identity map удаляется после выполнения запроса

То есть мы получаем identity resolution при выполнении запроса, но без постоянных затрат tracking.

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

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

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

✔️ Default Tracking если:

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

✔️ AsNoTracking если:

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

✔️ AsNoTrackingWithIdentityResolution если:

- read-only запрос с Include/Join
- важна целостность графа объектов
- результаты содержат повторяющиеся сущности
- нужно сравнение объектов по ссылке

👉 @KodBlog

👉 @KodBlog

На Reddit обсуждают, каких возможностей не хватает C# и .NET. Автор поста поделился своим списком пожеланий, сформированным за годы работы с языком.

Среди предложений:

• статическое наследование как способ переиспользования логики без необходимости создавать экземпляры классов
• ключевое слово для гарантированного использования структур без распределения в куче
• принудительное инлайнинг методов, а не лишь намек компилятору
• ручной контроль над GC, похожий на подход Unity, чтобы критичный код не зависел от решений рантайма
• возможность создавать классы, которые полностью живут в unmanaged-памяти
• компактные ключевые слова для базовых типов, которые в .NET выглядят излишне громоздко

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

Какие функции вы хотели бы видеть в C# и dotnet? 🤔

👉 @KodBlog

Отличная опенсорсная альтернатива Postman

Называется Requestly, и что самое безумное — она полностью open source и доступна как десктоп-приложение и как браузерное расширение.

Качай под свою ОС или устанавливай в браузер и просто начинай тестировать API. Очень просто, аккуратно и без тяжелой настройки 😏

Исходники: github.com/requestly/requestly

👉 @KodBlog

Как работают B-tree наглядно

👉 @KodBlog

Понимание, почему Type.FullName может возвращать null в .NET

Недавно коллега спросил интересную вещь: почему Type.FullName в некоторых случаях возвращает null? Хотя кажется, что метод должен всегда отдавать строку, сигнатура намекает на исключения:

public abstract string? FullName { get; }

На первый взгляд это может показаться странным, но есть конкретные ситуации, когда рантайм .NET просто не может сформировать валидное полное имя типа. Ниже два основных случая, когда Type.FullName возвращает null.

1. Открытые дженерики

Если создать дженерик с несвязанными (unbound) параметрами:

var list = typeof(IList<>);
var dict = typeof(IDictionary<,>);
var listOfDictionaries = list.MakeGenericType(dict); // IList<IDictionary<,>>
Assert.Null(listOfDictionaries.FullName);

Здесь тип неполный, его параметры не конкретизированы, поэтому нормальное FullName создать невозможно.

2. Function Pointers

Функциональные указатели, появившиеся в C# 9, тоже отдают null в FullName:

var functionPointerType = typeof(delegate*<int, void>);
Assert.Null(functionPointerType.FullName);

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

👉 @KodBlog

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

Задача была вроде обычная: API конвертации валют + кэш. Но при большом количестве параллельных запросов возникал риск cache stampede. Он попытался решить это через lock, но метод был async. А lock с async-await не работает. Логично: никто не гарантирует, какой поток завершит выполнение.

Правильный вариант в таких случаях — асинхронные примитивы синхронизации вроде SemaphoreSlim, Semaphore, Mutex или Monitor.

Два базовых правила при работе с таким кодом:

1. Использовать timeout
2. Освобождать блокировку в try-finally

И напоследок хороший вопрос:

как реализовать блокировку на уровне базы данных?

🚬

Кому интересно — ответ

👉 @KodBlog

Вот упрощённая схема потока service discovery в .NET Aspire

1. Определить API-сервис
2. Frontend ссылается на API-сервис
3. Внедрить URL API в настройки приложения
4. Создать HTTP-клиент
5. Получить URL из настроек приложения
6. https://api-service

А вот и полная картина

👉 @KodBlog

VS Code выкатывает новую фичу в терминале, и это просто имба.

Если нужно выполнить команду, но ты не помнишь синтаксис или точный аргумент, больше не надо гуглить или вспоминать по памяти. Достаточно нажать Ctrl+i прямо в терминале. Вылезет компактное окно с чатом.

Дальше всё просто: пишешь нормальным человеческим языком, что хочешь сделать. VS Code сам определит нужную команду и выполнит её.

👉 @KodBlog

Используем insteadOf в Git для Замены HTTPS-адресов на SSH

При работе с Git-репозиториями вы часто сталкиваетесь с URL-адресами в формате HTTPS, особенно при клонировании из GitHub, GitLab или других хостинг-провайдеров. Однако, если вы предпочитаете использовать SSH для аутентификации (что часто удобнее с аутентификацией по ключам), ручное изменение URL-адресов может быть утомительным. Кроме того, это может быть ещё сложнее при работе с субмодулями.

Конфигурационная опция Git insteadOf предлагает элегантное решение, автоматически переписывая URL-адреса «на лету»:

git config --global url."[email protected]:".insteadOf "https://github.com/"
git config --global url."[email protected]:".insteadOf "https://gitlab.com/"
git config --global url."[email protected]:".insteadOf "https://bitbucket.org/"

Вы также можете настроить более конкретную проверку и выбрать только определённые репозитории или сервисы. Например, если вы хотите заменить HTTPS-адреса некоторых репозиториев, вы можете сделать следующее:

git config --global url."[email protected]:username/".insteadOf "https://github.com/username/"

После настройки Git будет автоматически переписывать URL:

# Следующая команда
git clone https://github.com/user/repo.git

# Станет эквивалентной
git clone [email protected]:user/repo.git

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

Ещё один вариант использования insteadOf — добавление аутентификации к URL. Например, если вы хотите использовать определённого пользователя для всех запросов Git, вы можете сделать следующее:

git config --global url."https://<token>@github.com/".insteadOf "https://github.com/"

👉 @KodBlog

Удаление пробелов в .NET: что быстрее

На Хабре вышло сравнение разных способов убрать пробелы из строки в .NET: Replace, Regex, Split+Concat, StringBuilder, буферы и stackalloc. Тестировали на .NET 3.1, .NET 8 и .NET 10.

Результаты:

- stackalloc и буферный подход оказались самыми быстрыми
- StringBuilder почти не отстаёт
- Split+Concat работает шустро, но жрет память
- у Regex в .NET 10 заметно выросла производительность

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

Подробнее тут: habr.com/ru/companies/skbkontur/articles/970178/

👉 @KodBlog

Один разработчик поделился экспериментом: он пересмотрел видео tsoding про работу с PPM-форматом и повторил всё на C#. При этом отметил, что реализация на C выглядит куда компактнее, но сама идея остаётся простой и понятной.

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

Для динамики он сгенерировал 60 изображений, а затем собрал их в видео через ffmpeg. На каждом шаге узор немного смещался, и в результате получилась анимация движущейся шахматной сетки.

Классная мини-задача. Очень советую.

Производительность не была для меня целью, поэтому я не обращал на это внимания.

👉 @KodBlog

Как сделать API-эндпоинты быстрее в 426 раз
(подсказка: дело не в кешe)

Когда разработчики видят медленный API, первая реакция: лечить всё кешем.

Но это ошибка в базовом понимании:
кеш не фиксит тормоза, если корень проблемы в кривых запросах к базе.

Поэтому первый шаг к масштабируемой системе — пофиксить её, а не обклеить кешами.

Небольшой эксперимент:

есть веб-API с одним эндпоинтом /products

До оптимизации:

Обработано запросов: 378
Средний RPS: 11.01
Средняя длительность запроса: ~4 секунды

После оптимизации:

Обработано запросов: 140 331
Средний RPS: 4 689.36
Средняя длительность запроса: 10.69 мс

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

👉 @KodBlog

Использование выражений коллекций для своих типов

В C# 12 появились выражения коллекций — упрощённый синтаксис для инициализации коллекций:

int[] numbers = [1, 2, 3, 4, 5];
List<string> names = ["Alice", "Bob", "Charlie"];

Такой синтаксис отлично работает со стандартными коллекциями, но что делать с собственными типами? Здесь пригодится атрибут CollectionBuilderAttribute, который позволяет подключить этот новый синтаксис к пользовательским коллекциям.

Пользовательские коллекции

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

public class MyCollection<T>
{
private readonly List<T> _items;

public MyCollection(ReadOnlySpan<T> items) =>
_items = [.. items];

public IEnumerator<T> GetEnumerator()
=> _items.GetEnumerator();

// другие члены…
}

Раньше вы не могли использовать выражения коллекций с таким типом. Приходилось писать по-старинке:

var myCol =
new MyCollection<int>(new[] { 1, 2, 3, 4, 5 });

Или так (что сути почти не меняет):

var myCol =
new MyCollection<int>([1, 2, 3, 4, 5]);

Не особо изящно.

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

[CollectionBuilder(typeof(MyCollectionBuilder),
nameof(MyCollectionBuilder.Create))]
public class MyCollection<T>
{
//…
}

public static class MyCollectionBuilder
{
public static MyCollection<T>
Create<T>(ReadOnlySpan<T> items)
=> new([..items]);
}
Теперь можно писать так:
MyCollection<int> myCol = [1, 2, 3, 4, 5];

Компилятор сам вызовет метод Create и передаст ему элементы.

Как это работает

Атрибут принимает два параметра:

Тип построителя — класс, в котором находится фабричный метод (typeof(MyCollectionBuilder));

Имя метода — имя статического метода, создающего объект коллекции ("Create").

Метод построителя должен:

- быть статическим;
- принимать ReadOnlySpan<T> (предпочтительно) или T[];
- возвращать экземпляр вашей коллекции;
- иметь параметры типов, совпадающие с параметрами коллекции.

Замечание: коллекция должна иметь «тип итерации», то есть метод GetEnumerator(), который возвращает IEnumerator или IEnumerator<T>. Можно реализовать IEnumerable / IEnumerable<T>, либо просто добавить метод GetEnumerator() вручную.

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

👉 @KodBlog

Вот моё любимое правило в .editorconfig:

-> Правила именования для async-методов и полей

Задайте понятные правила именования для приватных полей, async-методов, интерфейсов и так далее.

Зачем? это убирает путаницу при работе с async-API и делает намерения очевидными.

Если кто не в курсе:

.editorconfig — это обычный текстовый конфиг, который сообщает вашему редактору или IDE, как форматировать и оформлять код, чтобы весь проект выглядел одинаково, независимо от личных настроек каждого разработчика.

Он работает во многих языках и IDE (Visual Studio, VS Code, JetBrains Rider и прочих), а в .NET особенно полезен, потому что встроен в Roslyn-анализаторы и настройки стиля кода.

👉 @KodBlog