Псевдопеременные в отладчике Visual Studio для C#

В Visual Studio есть специальные псевдопеременные, которые показывают полезную информацию в окне Watch или Immediate. Их можно вводить как обычные переменные, но они не связаны с именами переменных в коде.

Основные псевдопеременные:

1. $exception

Оценивает текущее выброшенное исключение. Переменная доступна в момент выбрасывания исключения, а также в блоке catch, если исключение перехвачено. Это полезно в случаях, когда вы не добавили параметр Exception в предложение catch. Вы также можете увидеть исключение в окне Locals.

2. $returnvalue

Показывает и возвращает значение метода, из которого только что вышли. Это полезно, если вы не присваиваете возвращаемое значение какой-то переменной (а, например, сразу используете return). Заметьте, однако, что значение будет доступно только сразу после выхода из метода:

- на следующей строке, если вы поставили там точку останова, либо перескочили (F10) через вызов метода;
- при выходе из метода (на строке с закрывающей скобкой после return), если вы проходите по коду самого метода.
Кроме того, возвращаемое значение автоматически показывается в окнах Locals и Autos.

3. $user

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

4. $threadSmallObjectHeapBytes

Отображает общее количество байт, выделенных в куче малых объектов (Small Object Heap) текущим потоком. (.NET 6+)

5. $threadUserOldHeapBytes

Отображает общее количество байт, выделенных в Пользовательской Куче Старшего поколения (User Old Heap) текущим потоком. User Old Heap = Large Object Heap + Pinned Object Heap (.NET 6+)

6. $1, $2, …, $n

Отображают по порядку объекты, для которых создан Object ID при отладке.

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

Источник: тык

👉 @KodBlog

В .NET 10 появился DATAS — механизм, который динамически подстраивает размер кучи под реальную нагрузку. Для Server GC это может заметно сократить потребление памяти, но в некоторых случаях снизить пропускную способность, поэтому стоит проверить метрики и при необходимости подстроить или отключить DATAS.

Механизм вычисляет Gen0-бюджет по Live Data Size (BCD), держит целевой throughput control point (по умолчанию 2%) и уменьшает кучу при снижении нагрузки. В статье описаны ограничения (одна куча на старте, влияние на startup и Gen2) и способы настройки.

Автор также разбирает формулу BCD (m ≈ 15000/√LDS), параметры GCDGen0GrowthPercent и GCDGen0GrowthMinFactor, и показывает, что включение DATAS снижает % pause time и общий размер кучи. Для диагностики доступны события SizeAdaptationTuning.

👉 @KodBlog

Roslyn можно использовать просто как библиотеку для анализа и генерации кода. Например, можно написать консольное приложение, которое загрузит solution, найдет нужные паттерны и перепишет код. В то время как Roslyn Analyzers привязаны к одному проекту, сам Roslyn как библиотека позволяет анализировать весь solution целиком.

Создадим консольное приложение и добавим нужные пакеты NuGet:

dotnet new console
dotnet add package Microsoft.Build.Locator
dotnet add package Microsoft.CodeAnalysis.CSharp
dotnet add package Microsoft.CodeAnalysis.CSharp.Workspaces
dotnet add package Microsoft.CodeAnalysis.Workspaces.Common
dotnet add package Microsoft.CodeAnalysis.Workspaces.MSBuild

Вот пример, как создать рабочее пространство Roslyn из решения:

using Microsoft.CodeAnalysis;
using Microsoft.CodeAnalysis.MSBuild;

// Находим сборки MSBuild в вашей системе
Microsoft.Build.Locator.MSBuildLocator.RegisterDefaults();

// Возможно надо восстановить NuGet-пакеты решения перед тем, как открыть его в Roslyn.
// Зависимости могут потребоваться для корректного анализа.

// Создаём рабочее пространство Roslyn и загружаем решение
var ws = MSBuildWorkspace.Create();
var solution = 
 await ws.OpenSolutionAsync(@"my_solution.sln");

Теперь можно работать с решением. Вот несколько примеров.

Анализируем синтаксические деревья:

foreach (var proj in solution.Projects)
{
  foreach (var doc in proj.Documents)
  {
    var syntree = await doc.GetSyntaxTreeAsync();
    var semanticModel = await doc.GetSemanticModelAsync();
    // Анализируем дерево
    // Можно использовать CSharpSyntaxWalker для обхода
  }
}

Получаем все ссылки на символ:

var comp = 
 await solution.Projects.First().GetCompilationAsync();
var symbol = 
 comp.GetSpecialType(SpecialType.System_String);
var refs = 
 await SymbolFinder.FindReferencesAsync(symbol, solution);

Переименовываем символ

var symbol = comp
 .GetSymbolsWithName(s => s == "MyMethod")
 .Single();
var newSolution = await Renamer
 .RenameSymbolAsync(
  solution, 
  symbol, 
  new SymbolRenameOptions()
  { 
    RenameOverloads = true 
  },
  "MyMethod2");
ws.TryApplyChanges(newSolution);

Обновляем документ с помощью DocumentEditor

foreach (var proj in solution.Projects)
{
  foreach (var doc in proj.Documents)
  {
    var editor = 
     await DocumentEditor.CreateAsync(doc);

    // Изменяем
    foreach(var emptyStatement in
     editor
      .OriginalRoot
      .DescendantNodes()
      .OfType<EmptyStatementSyntax>())
    {
      editor.RemoveNode(emptyStatement);
    }

    // Применяем изменения
    var newDoc = editor.GetChangedDocument();
    if (!ws.TryApplyChanges(newDoc.Project.Solution))
    {
      Console.WriteLine("Failed!");
    }
  }
}

Обновляем документ с помощью CSharpSyntaxRewriter:

foreach (var proj in solution.Projects)
{
  foreach (var doc in proj.Documents)
  {
    // Изменяем
    var root = await doc.GetSyntaxRootAsync();
    if(root is null)
      continue;

    var newRoot = 
     new CustomRewriter().Visit(root);
    var newDoc = 
     doc.WithSyntaxRoot(newRoot);

    // Применяем изменения
    if (!ws.TryApplyChanges(newDoc.Project.Solution))
    {
      Console.WriteLine("Failed!");
    }
  }
}

internal sealed class CustomRewriter : 
 CSharpSyntaxRewriter
{
  public override SyntaxNode? 
   VisitIfStatement(IfStatementSyntax node)
    => node.WithLeadingTrivia(
     SyntaxFactory
      .ParseLeadingTrivia("/* comment */"));
}

Выберите любое «подопытное» решение, введите его путь вместо my_solution.sln, вставьте любой из примеров и можете пройти его в отладчике пошагово, чтобы посмотреть, как работает анализатор.

👉 @KodBlog

👉 @KodBlog

0% разработчиков видят здесь проблему — пока не становится поздно.

Обычная выборка в EF Core с SELECT ... WHERE Id IN (...) выглядит безобидно. Всё работает… пока не перестаёт.

У каждой базы данных есть лимит на количество параметров в IN:

Oracle — 1000

SQL Server — несколько тысяч

Postgres / MySQL — ~64 000+

Если вы грузите тысячи ID через WHERE Id IN (...), вы всего в одном неудачном запросе от:

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

Что делать вместо этого:
✅Делите ID на батчи и выполняйте несколько запросов
✅Используйте временные таблицы или table-valued параметры для массовых выборок
✅Всегда профилируйте запросы — не думайте, что они «и так потянут»

👉 @KodBlog

Изучаем CollectionsMarshal для Dictionary (.NET)

В отличие от ConcurrentDictionary, обычный Dictionary не имеет метода GetOrAdd.
Он нужен, чтобы добавить пару ключ–значение, если ключа ещё нет, или вернуть существующее значение, если он уже есть.

Наивная реализация выглядит так:

public static TValue GetOrAdd<TKey, TValue>(this Dictionary<TKey, TValue> dict, TKey key, TValue value)
    where TKey : notnull
{
    if (dict.TryGetValue(key, out var result))
        return result;

    dict[key] = value;
    return value;
}

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

Более быстрый вариант с CollectionsMarshal

Метод CollectionsMarshal.GetValueRefOrAddDefault возвращает ссылку на значение по ключу и флаг, существует ли ключ.
Так как возвращается именно ref, значение можно менять напрямую:

public static TValue GetOrAdd<TKey, TValue>(this Dictionary<TKey, TValue> dict, TKey key, TValue value)
    where TKey : notnull
{
    ref var dictionaryValue = ref CollectionsMarshal.GetValueRefOrAddDefault(dict, key, out var exists);
    if (exists)
        return dictionaryValue;

    dictionaryValue = value;
    return value;
}

Обновление значения с GetValueRefOrNullRef

CollectionsMarshal также предлагает метод GetValueRefOrNullRef, который позволяет обновить значение, если ключ уже существует:

public static bool TryUpdate<TKey, TValue>(this Dictionary<TKey, TValue> dict, TKey key, TValue value)
    where TKey : notnull
{
    ref var dictionaryValue = ref CollectionsMarshal.GetValueRefOrNullRef(dict, key);
    if (!Unsafe.IsNullRef(ref dictionaryValue))
    {
        dictionaryValue = value;
        return true;
    }

    return false;
}

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

👉 @KodBlog

Скрытая цена энтерпрайз-архитектуры на .NET

Ад адской отладки.

За 13+ лет в .NET-кодовых базах — одно и то же:

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

IUserService → вызывает → IUserRepository
IUserRepository → оборачивает → IUserDataAccess
IUserDataAccess → дергает → IUserQueryBuilder
IUserQueryBuilder → наконец-то стучится → в базу

Чтобы поменять одно правило валидации → проходишь 5 слоев.
Чтобы починить баг → открываешь 7 файлов.

И оправдание всегда одно и то же:
«А вдруг нам придется заменить Entity Framework?»
«А вдруг мы поменяем базу?»
«А вдруг нам понадобится несколько реализаций?»

А вдруг то, а вдруг это.

Реальность такая:
99% этих "вдруг" никогда не происходят.

Я не видел ни одного проекта, где реально сменили ORM.
Зато видел десятки разработчиков, теряющих часы в лабиринтах абстракций.

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

Итог?
Ты больше времени тратишь на навигацию, чем на разработку.

Хорошие абстракции прячут сложность.
Плохие → создают её.

А в большинстве энтерпрайз-.NET-проектов второго типа слишком много.

👉 @KodBlog

Используй C# для работы с файлами Excel
(полностью бесплатно, кстати)

Если на машине установлен Excel (или Office 365, если уж на то пошло), то в системе уже есть встроенные библиотеки для программной работы со всеми приложениями Office.

Что удивительно, поиск в Google или даже через ИИ выдает устаревшие результаты, которые могут быть неактуальны. А лучший ответ от Perplexity ссылается на коммерческое решение, что чересчур для моих задач сегодня.

Но даже в 2025 году есть простой и понятный способ управлять Office из кода.

А LINQPad — идеальная среда для такого демо.

Добавь NuGet-ссылку на http://Microsoft.Office.Interop.Excel

Посмотри этот пример кода, чтобы понять, как:

- открыть книгу
- прочитать листы
- прочитать ячейки

Код создает невидимый процесс Excel для чтения и записи данных в таблицу. Минус в том, что Excel должен быть установлен на машине, поэтому этот способ не подходит для headless-автоматизации.

👉 @KodBlog

С EF Core можно делать забавные штуки.

Конфигурация сущности с:

- CHECK-ограничением Price > 0
- контролем точности столбца Price
- уникальным индексом на Name

Дальше генерим EF-миграцию и накатываем всё в базу.

Источник: читать

👉 @KodBlog

Бенчмарк: чтение таблиц из C#

ClosedXML vs EPPlus
(FOSS против коммерческого решения)

Не стоит слишком углубляться в это.

LINQPad делает бенчмаркинг кода через BenchmarkDotNet до безумия простым.

Исходная таблица: 1000 строк и 2 колонки.
Колонка A: int
Колонка B: string

ClosedXML примерно на 29% быстрее в этом тесте.

С субъективной стороны — ClosedXML, на мой взгляд, проще в использовании.

👉 @KodBlog

Узнайте все о протоколе HTTP

Всё про самый используемый протокол в интернете. 😎

✓ Все коды состояния с пояснениями
✓ Заголовки и методы с примерами
✓ Инструменты для тестирования HTTP
✓ Понятная инфа про HTTP/3

→ https://http.dev

👉 @KodBlog

Сохрани себе нервы, когда работаешь с базой данных.

Всегда оборачивай UPDATE или DELETE в транзакцию с откатом — так ты защитишься от случайных косяков.

Лично я первым делом пишу:

begin transaction

rollback transaction

Теперь, если что-то пойдёт не так, изменения сразу откатятся при rollback.
Можно спокойно шлифовать запрос, не боясь напортачить.

Когда всё готово и уверен в результате = либо выделяешь нужный SQL и запускаешь напрямую,
либо просто меняешь rollback transaction на commit transaction.

👉 @KodBlog

Code Coverage теперь доступен в Visual Studio Community и Professional

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

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

Отличный ход Microsoft 👍

👉 @KodBlog

В .NET считается хорошей практикой задавать размер List<T> при создании. И у меня есть бенчмарк, который это подтверждает.

Если добавить в список 10 миллионов элементов, то версия с заранее заданной емкостью работает примерно на 60% быстрее, чем список, созданный через конструктор по умолчанию.

Проблема на поверхности простая:

- List<T> внутри использует обычный массив
- по умолчанию Capacity = 0

То есть новый экземпляр List<T> всегда стартует с нуля.

Что происходит, когда список заполняется? Создается новый массив!
Когда элементы добавляются, а внутренний массив уже заполнен:

a) создается новый массив (всплеск использования памяти)
b) старые данные копируются в новый массив (лишние операции)

Получается довольно неприятный цикл.

Избежать этого можно, если создавать List<T> сразу с емкостью, примерно соответствующей ожидаемому количеству элементов.

Бенчмарк — добавление 10 миллионов элементов в список.

Тестировались три варианта:

- Capacity = 10_000_000 (равен ожидаемому количеству)
- Capacity = 5_000_000 (половина ожидаемого)
- Capacity = 0 (по умолчанию)

Если за базовую точку взять Capacity = 0:

- при Capacity = 50% — прирост скорости 48%
- при Capacity = 100% — прирост скорости 53%

👉 @KodBlog

Майкрософт выпустил второй и последний релиз-кандидат .NET 10, который поставляется с лицензией go-live и поэтому уже может использоваться в production. Этот выпуск .NET 10 добавляет главным образом улучшения и исправления уже имеющегося функционала и поддерживается в новом выпуске Visual Studio 2026 Insiders, а также в Visual Studio Code с C# Dev Kit.

Окончательный релиз .NET 10 с C# 14 состоится 11 ноября.

https://devblogs.microsoft.com/dotnet/dotnet-10-rc-2/

👉 @KodBlog

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

1. Проверка зависимостей на старте

Одна из типичных проблем .NET-приложений — когда сервис вроде бы создаётся без ошибок, но позже падает из-за недопустимых значений времени жизни или отсутствующих зависимостей. Такое можно ловить заранее.

Как делает новичок:

builder.Services.AddScoped<IMyService, MyService>();
// Без проверки

Ошибка проявится только при первом же запросе.

Как делает опытный:

var builder = Program.CreateHostBuilder(args);
builder.Services.AddScoped<IMyService, MyService>();
builder.Host.UseDefaultServiceProvider((context, options) =>
{
    options.ValidateOnBuild = true;
    options.ValidateScopes = true;
});

Эти настройки заставляют контейнер проверить конфигурацию при сборке приложения. ValidateScopes выявляет, например, внедрение scoped-сервиса в singleton, а ValidateOnBuild — пробует создать сервисы ещё до запуска. Ошибки проявятся сразу, а не в проде.

2. Осознанное использование областей действия

Многие просто лепят всё в Transient, не задумываясь, что это вообще значит. А время жизни сервисов — это не синтаксис, это логика памяти приложения.

Типичный пример:

builder.Services.AddTransient<UserSession>();

Без понимания, когда объект должен жить и когда исчезать.

Что знает опытный разработчик:

- Transient – новый экземпляр каждый раз,
- Scoped – один экземпляр на запрос/скоуп DI,
- Singleton – один экземпляр на всё время жизни приложения.

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

using var scope = serviceProvider.CreateScope();
var scopedService = scope.ServiceProvider.GetRequiredService<IScopedThing>();

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

3. DateTimeOffset вместо DateTime

Новички часто спотыкаются на часовых поясах и летнем времени. Всё вроде работает... пока не перестаёт.

Плохой вариант:

var orderTime = DateTime.Now; // локальное время

В другом часовом поясе это может поехать.

Хороший вариант:

var orderTime = DateTimeOffset.Now;

DateTimeOffset хранит не только момент времени, но и смещение. Это идеально для логов, транзакций и расписаний. Храните в UTC, показывайте пользователю в его часовом поясе.

4. Алиасы для пространств имён и типов

Длинные неймспейсы и вложенные типы быстро превращают код в кашу. Но немногие используют алиасы.

До:

System.Collections.Generic.Dictionary<System.Tuple<string, int>, List<MyNamespace.Models.ComplexThing>> myMap;

После:

using ComplexMap = System.Collections.Generic.Dictionary<(string, int), List<ComplexThing>>;

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

👉 @KodBlog

Новичок в C#: «Когда стоит использовать static-класс?»

NPC-ответ: «Когда тебе не нужен экземпляр».

Формально верно, но бесполезно. Такой ответ помогает только самооценке того, кто его дал.

На практике всё проще и понятнее:

Используй обычный класс, когда хочешь смоделировать систему, чтобы её было легче понять и использовать.
Система это набор связанных данных и операций над ними.
Например, табло очков (scoreboard): у него есть данные (очки, имена, время), и есть поведение (обновить счёт, сбросить, вывести). Ценность в целостности системы, а не в отдельном поле.

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

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

Честно говоря, можно было бы даже сказать, что static-классы должны быть дефолтом, а instance использовать только тогда, когда действительно есть повод включать ООП.

👉 @KodBlog

Встраивать бизнес-логику прямо в SQL-запросы?

Это верный способ превратить код в нечто нетестируемое и хрупкое.

Представь, ты делаешь поиск по инвойсам. Нужно фильтровать по:

- номеру инвойса
- имени клиента
- email
- статусу заказа
- названию продукта

И всё это в любых комбинациях.

Самое быстрое, но грязное решение — напихать всю эту логику прямо в SQL-запрос.
И вот теперь все твои бизнес-правила оказались заперты внутри базы.
Тестировать их без реальной базы уже не выйдет.

Альтернатива — Specification Pattern.

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

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

Создаёшь класс спецификации, который описывает критерии поиска.

Он принимает фильтры и строит выражение (например, LINQ).

Потом передаёшь эту спецификацию в репозиторий или обработчик запросов.

Этот подход отлично подходит для фильтрации и сложных запросов.

Результат:

- тесты запускаются быстрее
- бизнес-логика понятнее
- код запросов проще поддерживать

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

👉 @KodBlog

👉 @KodBlog

На Хабре вышла статья о том, как с помощью EF Core и PostgreSQL избежать deadlock и oversell при работе со стоками. Автор разбирает подход с сортировкой обновлений по ключам, использованием ExecuteUpdateAsync, повторными попытками (retry), триггерами, очередями и батчами.

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

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

👉 @KodBlog

В превью C# 14 появились partial-конструкторы и partial-события.

Каждый из них должен состоять ровно из одного объявления-определения и одного объявления-реализации.

Реализация partial-события обязана содержать add и remove аксессоры.

👉 @KodBlog