Библиотека шарписта | C#, F#, .NET, ASP.NET

👨‍💻 Строим AI-агентов на .NET Microsoft выпустила третью часть серии «Building Blocks for AI» — на этот раз про Microsoft Agent Framework. Что это и зачем Обычный чат-бот принимает запрос и возвращает ответ. Агент идёт дальше: он сам решает, какие инструменты использовать, вызывает их, оценивает результат и продолжает работу. Вам не нужно писать «если пользователь спросит о погоде — вызови функцию X». Модель разбирается сама. Фреймворк строится поверх IChatClient из Microsoft Extensions for AI (MEAI) и поддерживает Azure OpenAI, OpenAI, GitHub Models, Foundry Local и Ollama. Первый агент Установка:

dotnet add package Microsoft.Agents.AI

Простейший агент:

AIAgent agent = new AzureOpenAIClient(
    new Uri(endpoint),
    new DefaultAzureCredential())
    .GetChatClient(deploymentName)
    .AsAIAgent(
        instructions: "You are good at telling jokes.",
        name: "Joker");

Console.WriteLine(await agent.RunAsync("Tell me a joke about a pirate."));

Метод .AsAIAgent() это аналог .AsIChatClient(), только оборачивает клиент в агента с поддержкой сессий, инструментов и памяти. Стриминг тоже работает из коробки через RunStreamingAsync. Инструменты Агенты вызывают функции сами, без явных условий в коде. Главное добавить атрибуты [Description], чтобы модель понимала, когда и как использовать инструмент:

[Description("Get the weather for a given location.")]
static string GetWeather(
    [Description("The location to get the weather for.")] string location)
    => $"The weather in {location} is cloudy with a high of 15°C.";

AIAgent agent = ...AsAIAgent(
    instructions: "You are a helpful assistant",
    tools: [AIFunctionFactory.Create(GetWeather)]);

Спрашиваем «What is the weather in Amsterdam?» и агент сам вызывает GetWeather("Amsterdam") и подставляет результат в ответ. Многоходовые разговоры Сессия сохраняет историю между вызовами:

AgentSession session = await agent.CreateSessionAsync();

await agent.RunAsync("Tell me a joke about a pirate.", session);
await agent.RunAsync("Now add emojis and tell it as a parrot.", session);

Сессию можно сериализовать и восстановить:

JsonElement state = await agent.SerializeSessionAsync(session);
var restored = await agent.DeserializeSessionAsync(state);

Память между сессиями AIContextProvider позволяет агенту извлекать и помнить факты о пользователе между сессиями. Провайдер работает в два этапа: StoreAIContextAsync запускается после каждого взаимодействия — здесь агент учится из разговора (например, извлекает имя пользователя). ProvideAIContextAsync запускается до — здесь агент получает накопленный контекст перед ответом. Провайдеры стекуются: один хранит имя, другой — предпочтения, третий — подтягивает документы из VectorData. Граф-воркфлоу и мульти-агенты Для сложных задач можно соединять агентов через граф: WorkflowBuilder связывает исполнителей рёбрами: Писатель-критик — агент пишет, второй проверяет, если не ок — отправляет обратно:

WorkflowBuilder builder = new(writerAgent);
builder
    .AddEdge(writerAgent, criticAgent)
    .AddEdge(criticAgent, writerAgent, condition: result => !result.IsApproved)
    .WithOutputFrom(criticAgent, condition: result => result.IsApproved);

Помимо этого доступны параллельное выполнение (fan-out / fan-in), условная маршрутизация, вложенные воркфлоу и циклы с лимитом итераций. Human-in-the-loop Для чувствительных операций: запись в БД, финансовые транзакции, отправка сообщений; агент может запрашивать подтверждение человека перед вызовом инструмента. Механизм встроен через FunctionApprovalRequestContent и FunctionApprovalResponseContent из MEAI. Теперь Microsoft Agent Framework — это единый SDK с понятными абстракциями поверх уже знакомого IChatClient. ➡️ Блог разработчиков 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #sharp_view

📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #garbage_collector

👍 Дружеское напоминание В C# 14 появился более чистый способ писать методы расширения. Да, тот самый отдельный синтаксис extension:

extension(string text)
{
    public int WordCount()
    {
        return text.Split(' ').Length;
    }
}

Меньше шаблонного кода. Не нужно каждый раз создавать статический класс и писать this в параметре. Обязательно к использованию в новых проектах! 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #sharp_view

🦾 Почему ваши AI-продукты на базе LLM ломаются (и как это чинить)? Выкатили ИИ-фичу в прод, а она галлюцинирует, падает или выдает мусор? Приглашаем на открытый вебинар, где разберем реальную боль внедрения LLM-агентов и научимся делать так, чтобы «всё работало». 🗓️ Когда: 7 мая в 19:00 МСК ⏱️ Формат: 60 минут мяса + 30 минут ответов на ваши вопросы 🧑🏻‍💻 Кто вещает: Эмиль Сатаев — Backend Platform Developer (8+ лет в разработке). Человек, который своими руками внедряет LLM и агентные системы в реальные коммерческие сервисы. 🎁 Главный бонус для онлайна: Только участникам прямого эфира подарим уникальный промокод на скидку 10.000 ₽ на большой курс AgentOps. 👉 Занять место на вебинаре

🛠 CQRS: что это и зачем оно вам Мы часто упоминаем CQRS в контексте архитектуры. Пора разобраться, что за ним стоит и когда его стоит применять. Что такое CQRS CQRS расшифровывается как Command Query Responsibility Segregation. Суть простая: операции чтения и записи разделяются на два независимых потока. Query — читает данные, ничего не меняет. Command — меняет состояние, ничего не возвращает (кроме подтверждения). В классическом подходе один репозиторий или сервис отвечает и за чтение, и за запись. Это удобно, пока система небольшая. Когда нагрузка растёт или модели чтения и записи начинают расходиться, появляются проблемы. Какую боль решает CQRS Представьте интернет-магазин. Команда на оформление заказа PlaceOrderCommand обновляет остатки, создаёт запись заказа и запускает цепочку событий. А запрос на страницу каталога GetProductsQuery просто возвращает список товаров с ценами. Если один и тот же объект обслуживает оба сценария, вы получаете: • модель данных, которая пытается угодить всем сразу • сложные запросы с JOIN там, где нужна простая выборка • трудности с масштабированием — читать нужно в 10 раз чаще, чем писать CQRS позволяет разделить эти ответственности явно. Как это выглядит на практике Допустим, у нас есть приложение на C# с заказами. Для удобства используем MediatR — библиотеку, которая берёт на себя маршрутизацию команд и запросов. Сначала определяем интерфейсы:

public interface ICommand : IRequest { }
public interface IQuery<TResult> : IRequest<TResult> { }

Команда на создание заказа:

public record PlaceOrderCommand(string UserId, string ProductId, int Quantity) : ICommand;

public class PlaceOrderCommandHandler : IRequestHandler<PlaceOrderCommand>
{
    private readonly IOrderRepository _repo;

    public PlaceOrderCommandHandler(IOrderRepository repo) => _repo = repo;

    public async Task Handle(PlaceOrderCommand command, CancellationToken ct)
    {
        var order = Order.Create(command.UserId, command.ProductId, command.Quantity);
        await _repo.SaveAsync(order, ct);
    }
}

Запрос на получение заказов пользователя:

public record GetUserOrdersQuery(string UserId) : IQuery<IReadOnlyList<OrderDto>>;

public class GetUserOrdersQueryHandler : IRequestHandler<GetUserOrdersQuery, IReadOnlyList<OrderDto>>
{
    private readonly IOrderReadRepository _readRepo;

    public GetUserOrdersQueryHandler(IOrderReadRepository readRepo) => _readRepo = readRepo;

    public async Task<IReadOnlyList<OrderDto>> Handle(GetUserOrdersQuery query, CancellationToken ct)
        => await _readRepo.GetByUserIdAsync(query.UserId, ct);
}

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

// Команда
await _mediator.Send(new PlaceOrderCommand(userId, productId, quantity));

// Запрос
var orders = await _mediator.Send(new GetUserOrdersQuery(userId));

Обратите внимание: PlaceOrderCommandHandler работает с доменной моделью Order, а GetUserOrdersQueryHandler возвращает OrderDto — упрощённую структуру специально для отображения. Это ключевой момент. IOrderRepository и IOrderReadRepository — два разных интерфейса. Первый смотрит в основную базу и знает о доменных правилах. Второй может работать с read-replica или отдельной проекцией данных. Для чтения можно подключить read-replica или отдельную схему, оптимизированную под конкретные запросы. Запись при этом идёт в основное хранилище, а синхронизация происходит через события. Когда применять CQRS оправдан, если: • нагрузка на чтение и запись сильно различается • модели чтения и записи расходятся, например, вам нужны агрегированные данные на фронте, но нормализованное хранилище на бэке • вы строите систему с событийной архитектурой или Event Sourcing CQRS не нужен, если: • у вас простой CRUD без сложной логики • команда небольшая и накладные расходы на поддержку двух моделей не оправданы Если вы чувствуете, что один репозиторий тащит на себе слишком много, это сигнал задуматься о разделении. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #il_люминатор

💬 Дайджест недели Кто куда, а админ на шашлыки. — hh.ru + Госуслуги + трудовая — VSTest убирает зависимость от Newtonsoft.Json — Как настроить JsonSerializerOptions — SkiaSharp 4.0 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #async_news

💡 sealed в C#: зачем закрывать классы Модификатор sealed существует в языке давно, но в современных версиях .NET он приобрёл дополнительный вес за счёт оптимизаций JIT-компилятора. Что делает sealed sealed запрещает наследование. Если класс помечен как sealed, от него нельзя унаследоваться. Можно применять и к отдельным методам с override, тогда этот метод нельзя переопределить дальше по цепочке.

public sealed class PaymentConfiguration
{
    public string ApiKey { get; set; }
    public int TimeoutInSeconds { get; set; }
}

// Ошибка компиляции: нельзя наследоваться от sealed-типа
public class GatewayX : PaymentConfiguration { }

Почему это влияет на производительность Когда класс открыт для наследования, JIT не может знать наверняка, какой именно метод будет вызван в рантайме. Поэтому он генерирует косвенный вызов через vtable.

; Открытый класс — несколько обращений к памяти перед вызовом
mov eax, [edx]
mov eax, [eax+0x28]
call dword ptr [eax+0x10]

Для sealed-класса JIT точно знает, какой метод будет вызван. Он убирает обращение к vtable, встраивает тело метода прямо в место вызова и оставляет минимум инструкций:

; Sealed-класс — только проверка на null и возврат
cmp [edx], dl
ret

Дополнительно ускоряются операторы is и as, потому что среде не нужно проходить по всему дереву наследования. Когда sealed не подойдёт Entity Framework создаёт прокси-классы в рантайме для ленивой загрузки. Если сущность sealed, фреймворк не сможет её расширить:

// EF не сможет создать прокси для sealed-класса
public class Order
{
    public int Id { get; set; }
    public virtual ICollection<OrderItem> Items { get; set; }
}

Аналогичная проблема с библиотеками для мокирования (Moq, NSubstitute). Они создают наследников в рантайме, и sealed ломает это:

public sealed class IntegrationService
{
    public bool SendData(string data) => true;
}

// Moq выбросит исключение: нельзя наследоваться от sealed-типа
var mock = new Mock<IntegrationService>();

Архитекторы рекомендуют подход "sealed by default": закрывать все классы сразу, а наследование открывать только когда оно действительно нужно. Это защищает дизайн от случайных расширений и даёт прирост производительности без дополнительных усилий. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #il_люминатор

📉 Кандидатов мало, а собесы становятся сложнее Казалось бы, в кризис найма логично снижать барьеры. Но Яндекс и Сбер делают ровно наоборот: добавляют этапы, запускают ИИ-скрининг, вводят психологические тесты и проверку культурного фита. Поиск работы даже для сильных специалистов теперь занимает 6–9 месяцев, а воронка найма растёт. ➡️ Разбираем на цифрах и фактах 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта

🛠 yield return под капотом Многие используют yield return, но не задумываются что происходит внутри. Компилятор перестраивает весь метод в конечный автомат. Что делает компилятор Вот простой метод:

public IEnumerable<int> GetNumbers()
{
    yield return 1;
    yield return 2;
    yield return 3;
}

Компилятор создаёт отдельный класс с полем _state. Каждый yield return становится отдельным состоянием в switch:

public bool MoveNext()
{
    switch (_state)
    {
        case 0: _state = 1; _current = 1; return true;
        case 1: _state = 2; _current = 2; return true;
        case 2: _state = 3; _current = 3; return true;
        default: return false;
    }
}

foreach под капотом вызывает MoveNext() на каждой итерации. Локальные переменные метода становятся полями этого класса — так состояние и сохраняется между вызовами. Главное свойство — ленивость Код выполняется только при вызове MoveNext(). Поэтому можно работать с бесконечными последовательностями:

public IEnumerable<int> Infinite()
{
    int i = 0;
    while (true) yield return i++;
}

Infinite().Take(5); // {0, 1, 2, 3, 4} — не зависнет

Практически При загрузке данных из БД yield return позволяет начать обработку до того, как все данные загрузятся:

public IEnumerable<Order> GetOrders(IDataReader reader)
{
    while (reader.Read())
        yield return new Order { Id = reader.GetInt32(0) };
}

Каждый объект создаётся только при переходе к следующей итерации, а не все сразу в памяти. При каждом вызове метода создаётся новый объект сгенерированного класса в куче. При частых вызовах это влияет на аллокации. async/await работает по той же схеме — это два применения одного паттерна трансформации кода. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #il_люминатор

✏️ Пятничный вопрос с собеса

Чем SelectMany отличается от Select в LINQ

Оба метода принимают функцию-проекцию. Оба работают с коллекциями. Но результат — принципиально разный.

var data = new List<List<int>>
{
    new() { 1, 2, 3 },
    new() { 4, 5, 6 }
};

var a = data.Select(x => x);      // ???
var b = data.SelectMany(x => x);  // ???

Подсказка: посмотрите на тип возвращаемого значения 👀 Ответ: спрятали не только под спойлер

🧑‍💻 SkiaSharp 4.0: движок обновлён, новый сопровождающий, переменные шрифты Вышел первый превью SkiaSharp 4.0. Библиотека существует 10 лет и лежит в основе кроссплатформенной 2D-графики в .NET: её используют .NET MAUI, WebAssembly, WinUI 3. Это первый крупный мейджор за долгое время. Что поменялось в движке Главное обновление — переход на Skia milestone 147. Это 2,5 года апстрим-изменений, которые достаются автоматически без правки кода. Качество изображений. Mipmap-шарпенинг включён по умолчанию, уменьшенные изображения стали чётче. Кодеки теперь читают Exif-метаданные и автоматически применяют поворот фото. Большие битмапы, которые не влезают в лимиты текстур GPU, тайлятся автоматически. Цвет. Поправлены передаточные функции для Rec.709, HLG и PQ. Для тех, кто работает с видео или профессиональной цветокоррекцией, это важно. Производительность. Незначительный прирост по всем операциям рендеринга. Более заметные улучшения в noise-шейдерах и canvas-операциях. Безопасность. Обновлены нативные зависимости, включены современные митигации компилятора на всех платформах. Новые возможности Переменные шрифты. Полная поддержка OpenType variable fonts через SkiaSharp и HarfBuzz. Можно получить доступные оси, задать их значения и создавать варианты шрифта по весу, ширине, наклону или кастомным осям. Палитры цветных шрифтов. Поддержка OpenType CPAL для эмодзи и иконочных шрифтов. Можно переключать палитры или переопределять цвет отдельных глифов. SKPathBuilder. Новый способ строить пути. SKPath теперь иммутабелен, а SKPathBuilder предоставляет привычный API с MoveTo, LineTo, CubicTo и фабриками фигур. Старые методы SKPath сохранены для обратной совместимости. Новые платформы. Добавлены нативные сборки для Linux Bionic и Tizen x64/arm64. Uno Platform стала сопровождающим Вместе с релизом объявили, что Uno Platform становится co-maintainer SkiaSharp. Они используют библиотеку в собственном рендер-пайплайне и уже сделали значимые вклады: обновления движка Skia, полная реализация API переменных шрифтов, фикс краша с typeface на Android API 36, поддержка генератора биндингов на Linux, интерактивная Wasm-галерея. Для тех, кто зависит от SkiaSharp в продакшне: библиотека теперь поддерживается двумя организациями, что ускорит обновления и тришаж. ➡️ Интерактивная галерея с примерами и шейдер-плейграунд. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #async_news

📎 JsonSerializerOptions: дефолты vs продакшен в .NET 10 System.Text.Json работает из коробки, но умолчания выбирались для удобства, а не безопасности. Разбираем пять настроек, которые стоит менять перед релизом. • Дублирующиеся ключи

{"role":"user","role":"admin"}

По умолчанию десериализатор молча возьмёт admin. Именно это эксплуатировал CVE-2022-25757: шлюз видел одно значение, бэкенд — другое. Фикс: AllowDuplicateProperties = false. • Неизвестные поля Поля, которых нет в модели, тихо выбрасываются. Переименовали свойство в DTO и забыли обновить клиент — данные исчезают без ошибки. Фикс: UnmappedMemberHandling = JsonUnmappedMemberHandling.Disallow. • required компилятора ≠ required для десериализатора C# 11 следит, чтобы объект нельзя было создать без обязательных полей. Десериализатор работает через рефлексию и обходит этот контроль — запишет null туда, где поля нет в JSON. Баг всплывёт на три слоя глубже в виде NullReferenceException. Фикс: RespectRequiredConstructorParameters = true. • Регистр не важен — по умолчанию ASP.NET Core включает PropertyNameCaseInsensitive = true в веб-дефолтах. IsAdmin, isadmin и ISADMIN — одно и то же. Если рядом есть middleware с проверкой строк по сырому JSON — они уже видят разные вещи. Фикс: PropertyNameCaseInsensitive = false. • Nullable-аннотации игнорируются string Name говорит, что поле не может быть null. Десериализатор это не соблюдает — запишет null без предупреждений. Фикс: RespectNullableAnnotations = true. В .NET 10 всё это одна строка:

var options = JsonSerializerOptions.Strict;

Для ASP.NET Core пайплайна JsonOptions.SerializerOptions не заменяется целиком, флаги выставляются вручную:

builder.Services.Configure<JsonOptions>(o =>
{
    var s = o.SerializerOptions;
    s.AllowDuplicateProperties             = false;
    s.UnmappedMemberHandling               = JsonUnmappedMemberHandling.Disallow;
    s.PropertyNameCaseInsensitive          = false;
    s.RespectNullableAnnotations           = true;
    s.RespectRequiredConstructorParameters = true;
});

Для прямых вызовов JsonSerializer.Deserialize вне MVC-пайплайна — передавайте JsonSerializerOptions.Strict напрямую. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #il_люминатор

🌟 VSTest убирает зависимость от Newtonsoft.Json Начиная с .NET 11 Preview 4 и Visual Studio 18.8, VSTest больше не будет тянуть Newtonsoft.Json. Вместо него на .NET будет использоваться System.Text.Json, на .NET Framework будет`JSONite`. Почему Все версии Newtonsoft.Json ниже 13.0.0 теперь помечены как уязвимые на NuGet.org. Это часть более широкой работы по удалению Newtonsoft.Json из .NET SDK. Что не меняется Формат сообщений VSTest остаётся прежним. Сериализация идентична независимо от используемой библиотеки. Старые тестовые хосты совместимы с обновлённой платформой и наоборот. Производительность сериализации не ухудшилась. Кого затронет Большинство проектов изменений не почувствуют. Проблемы возникнут в трёх случаях. 1. Ошибка сборки — если тестовый проект использует типы Newtonsoft.Json (JObject, JsonConvert) без явной ссылки на пакет. Раньше пакет «протекал» через VSTest. Теперь нет. Решение — добавить зависимость:

<PackageReference Include="Newtonsoft.Json" Version="13.0.3" />

2. Ошибка в рантайме — если пакет подключён с <ExcludeAssets>runtime</ExcludeAssets> и проект рассчитывал на копию из VSTest. Тест упадёт с FileNotFoundException. Решение — убрать <ExcludeAssets>runtime</ExcludeAssets>. 3. Ошибка загрузки адаптера — если тестовый адаптер или data collector использует Newtonsoft.Json без явной зависимости. Среди известных адаптеров таких случаев пока не обнаружено. Превью-пакеты уже доступны на NuGet как Microsoft.TestPlatform.* версии 1.0.0-alpha-stj. ➡️ Источник 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #async_news

🙂 Больше памяти — больше проблем Автор книг по исходникам Quake и Doom собрал ретро-машину 1997 года. Материнка, HDD — дорого. А вот 384 МБ SDRAM обошлись всего в $60. Почему бы не взять с запасом? Запустил Quake. Pentium MMX 233MHz выдаёт стабильные 44 fps. Всё отлично, пишет статью, уходит на месяц. Возвращается, запускает тот же бенчмарк и результат: 33 fps. Перебрал всё: видеокарты, драйверы, переустановка системы. Ничего не помогает. Случайно попробовал вытащить одну планку — 33 fps. Вытащил ещё одну — 44. Вернул обратно и опять 33. Оказалось, чипсет материнской платы кешировал только ограниченный объём RAM через L2-кеш. Всё, что сверх лимита — работало напрямую, без кеша вообще. А Windows 95 загружается «сверху вниз» по адресному пространству, то есть некешируемая зона задействовалась сразу при старте. ➡️ Источник 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #entry_point

😕 Подборка вакансий для шарпистов Разработчик C# — от 365 000 ₽, удалёнка/гибрид в Москве, Санкт-Петербурге, или Казани C# Developer (WinForms + SQL) — от 350 000 ₽, офис в Санкт-Петербурге C#/. NET-разработчик — удалёнка ➡️ Еще больше топовых вакансий — в нашем канале C# Jobs 🐸 Библиотека шарписта

🔥 4 привычки кодеров Вот сколько общаюсь с разработчиками, постоянно слышу убеждение, что есть какой-то правильный способ писать софт. Все ищут секретную архитектуру, вылизывают паттерны, чтобы хоба и тимлид заплакал от счастья от твоего идеального кода. но, я собрал 4 привычки адептов «чистого кода», (которые обычно все практикуют) 🤡 • Бесконечный рефакторинг рабочего кода. Кажется, что так ты делаешь продукт лучше. Итог: жестко падаешь в перфекционизм. Переписываешь функцию по три раза, а бизнес ждет релиз. Закрываешь вкладку и в голове абсолютная пустота, время потрачено, а новых фичей ноль. • Упарывание в сложную архитектуру Сеньоры на ютубе обещают золотые горы, если внедрить микросервисы куда угодно. Итог: получаешь красивый overengineering-проект для мамы и 0 запущенных продуктов в срок, пока конкуренты клепают MVP на коленке. • Душные споры на ревью Неплохо, но как итог: ты пишешь полотна текста и тратишь часы на поиск глупой придирки к стилю, потому что банально фокус сместился с реальной задачи на эго. • Ручная микро-оптимизация Классика для тех, кто любит алгоритмы из универа. Итог: убиваешь дни жизни и выжимаешь миллисекунды, хотя бизнесу нужен был просто грязный, но рабочий скрипт еще вчера. Проблема в том, что ни один из этих путей не дает самого главного - скорости и проверки гипотез. Реальному рынку плевать на твой идеальный код за 3 дня. Бизнес предпочтет код от ИИ-агента за 5 минут, который уже завтра начнет приносить деньги. Хочешь обкатанный на нас лично и 100х учениках метод, как перестать кодить руками и начать делегировать задачи автономным системам? 👉 Заходи сюда, но у нас осталось всего 4 места, набор идет до завтрашнего дня. P. S. Если интересно еще что-нибудь почитать от меня, то заходите в «Азбуку Айтишника», там я рассказываю об айти-базе, также у меня там есть бесплатный гайд на 15 глав по ии-агентам

⭐️ C# превращает лямбду в метод Лямбда-функция в C# это чуть больше, чем кусок кода. Компилятор переписывает ваш код, и если понять как именно, многое встаёт на своё место. Простой случай Когда лямбда не захватывает никаких переменных, компилятор просто превращает её в обычный метод:

public class LambdaDemo2
{
    private System.Timers.Timer? _timer;

    private void HiddenMethodForLambda(
        object? sender, System.Timers.ElapsedEventArgs args)
    {
        Console.WriteLine("Выполнено");
    }

    public void InitTimer()
    {
        _timer = new System.Timers.Timer(1000);
        _timer.Elapsed += HiddenMethodForLambda;
        _timer.Enabled = true;
    }
}

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

public void InitTimer()
{
    int aVariable = 5;
    _timer = new System.Timers.Timer(1000);
    _timer.Elapsed += (sender, args) => Console.WriteLine(aVariable);
    _timer.Enabled = true;
}

Здесь уже один метод не поможет: нужно где-то хранить aVariable так, чтобы к ней имели доступ сразу два места — InitTimer и лямбда. В .NET для этого используют классы. Компилятор генерирует вспомогательный класс и переносит туда локальную переменную:

public class LambdaDemo4
{
    private System.Timers.Timer? _timer;

    private class HiddenClassForLambda
    {
        public int aVariable;

        public void HiddenMethodForLambda(
            object? sender, System.Timers.ElapsedEventArgs args)
        {
            Console.WriteLine(aVariable);
        }
    }

    public void InitTimer()
    {
        var hiddenObject = new HiddenClassForLambda();
        hiddenObject.aVariable = 5;
        _timer = new System.Timers.Timer(1000);
        _timer.Elapsed += hiddenObject.HiddenMethodForLambda;
        _timer.Enabled = true;
    }
}

Локальная переменная стала полем класса. Метод InitTimer и лямбда теперь обращаются к одному объекту hiddenObject. Когда лямбда захватывает переменную, способ доступа к ней меняется. То, что выглядело как работа с локальной переменной, после компиляции становится обращением к полю объекта в куче. Если в одном методе объявить несколько лямбд, захватывающих общие переменные, компилятор поместит их всех в один класс — чтобы они могли использовать одни и те же поля. Это объясняет, почему захват переменных в лямбдах влияет на выделение памяти и время жизни объектов: захваченная переменная живёт столько, сколько живёт объект-носитель, а не до конца метода. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #il_люминатор

Уровень кортизола явно будет пониже, если пройти наш курс по разработке ИИ-агентов. Но нужно успевать, ведь осталось всего пару мест, а набор закроется уже завтра. 🔗 Успеть на обучение 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #garbage_collector

💡 Версионирование API в .NET 10 вместе с OpenAPI Когда API растёт, рано или поздно встаёт вопрос: как добавить новые возможности и не сломать тех, кто уже использует старую версию? Стандартный ответ — версионирование. В .NET 10 появился удобный способ совместить версионирование с OpenAPI-документацией без лишнего кода. Зачем нужно версионирование Без версионирования любое изменение контракта API потенциально ломает клиентов. Версионирование позволяет выпускать новые версии параллельно со старыми, пока клиенты не перейдут самостоятельно. Популярные стратегии: - По URL: /api/v1/users - По query string: /api/users?api-version=1.0 - По заголовку: X-API-Version: 1.0 Что изменилось в .NET 10 С .NET 9 Microsoft.AspNetCore.OpenApi стал стандартным инструментом для генерации OpenAPI вместо Swashbuckle.AspNetCore. Но удобной интеграции с версионированием не было. В .NET 10 вышел пакет Asp.Versioning.OpenApi версии 10 — первый, который официально поддерживает и .NET 10, и новую OpenAPI-библиотеку от Microsoft. Как подключить: Minimal APIs Установите пакеты:

Asp.Versioning.Http@10.0.0
Asp.Versioning.Mvc.ApiExplorer@10.0.0
Asp.Versioning.OpenApi@10.0.0-rc.1

Настройка:

builder.Services.AddApiVersioning()
    .AddApiExplorer(options =>
    {
        options.GroupNameFormat = "'v'VVV";
    })
    .AddOpenApi();

app.MapOpenApi().WithDocumentPerVersion();

Регистрация эндпоинтов:

var usersApi = app.NewVersionedApi("Users");

var v1 = usersApi.MapGroup("api/users").HasApiVersion("1.0");
var v2 = usersApi.MapGroup("api/users").HasApiVersion("2.0");

v1.MapGet("", () => TypedResults.Ok(new[]
{
    new UserV1(1, "John Doe"),
}));

v2.MapGet("", () => TypedResults.Ok(new[]
{
    new UserV2(1, "John Doe", new DateOnly(1990, 1, 1)),
}));

После запуска OpenAPI-документы доступны по адресам /openapi/v1.json и /openapi/v2.json. Как подключить контроллеры Пакеты:

Asp.Versioning.Mvc@10.0.0
Asp.Versioning.Mvc.ApiExplorer@10.0.0
Asp.Versioning.OpenApi@10.0.0-rc.1

Настройка идентична Minimal APIs, только добавляется .AddMvc():

builder.Services.AddApiVersioning()
    .AddApiExplorer(options =>
    {
        options.GroupNameFormat = "'v'VVV";
    })
    .AddMvc()
    .AddOpenApi();

Контроллеры с версиями:

[ApiController]
[Route("api/users")]
[ApiVersion("1.0")]
public class UsersV1Controller : ControllerBase
{
    [HttpGet]
    public ActionResult<UserV1[]> Get() =>
        Ok(new[] { new UserV1(1, "John Doe") });
}

[ApiController]
[Route("api/users")]
[ApiVersion("2.0")]
public class UsersV2Controller : ControllerBase
{
    [HttpGet]
    public ActionResult<UserV2[]> Get() =>
        Ok(new[] { new UserV2(1, "John Doe", new DateOnly(1990, 1, 1)) });
}

Визуализация: SwaggerUI и Scalar Оба инструмента умеют показывать версионированные документы. SwaggerUI подключается через Swashbuckle.AspNetCore.SwaggerUI, Scalar через Scalar.AspNetCore. SwaggerUI:

app.UseSwaggerUI(options =>
{
    foreach (var desc in app.DescribeApiVersions().Reverse())
    {
        options.SwaggerEndpoint(
            $"/openapi/{desc.GroupName}.json",
            desc.GroupName.ToUpperInvariant());
    }
});

Scalar:

app.MapScalarApiReference(options =>
{
    var descriptions = app.DescribeApiVersions();
    for (var i = 0; i < descriptions.Count; i++)
    {
        var desc = descriptions[i];
        options.AddDocument(desc.GroupName, desc.GroupName,
            isDefault: i == descriptions.Count - 1);
    }
});

SwaggerUI откроется по /swagger, Scalar по /scalar. Что изменилось по сравнению с v8 В старой версии Asp.Versioning.OpenApi v8 нужно было вызывать AddOpenApi() отдельно для каждой версии:

// v8
builder.Services.AddOpenApi("v1");
builder.Services.AddOpenApi("v2");

Теперь достаточно одного вызова, а WithDocumentPerVersion() берёт на себя генерацию отдельного документа для каждой версии автоматически. ➡️ Блог разработчиков 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #il_люминатор