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

😎 Три строки C# — и ваш AI-агент уже готов к хостингу в Azure Microsoft показала интеграцию .NET с Foundry Hosted Agents: существующий агент на Microsoft Agent Framework можно превратить в hosted agent практически без изменения логики. 🤩 Достаточно добавить пакет: dotnet add package Microsoft.Agents.AI.Foundry.Hosting --prerelease 🤩 И три строки: var builder = AgentHost.CreateBuilder(args); builder.Services.AddFoundryResponses(agent); builder.RegisterProtocol( "responses", endpoints => endpoints.MapFoundryResponses()); 🤩 Дальше: azd provision azd deploy Foundry берёт на себя инфраструктуру, масштабирование, состояние сессий, identity, endpoint и observability. При этом сам AIAgent практически не меняется — вы просто добавляете вокруг него hosting-слой. ⁠🔗 Источник: From dotnet run to Foundry Hosted Agent in 3 lines of C# 📍 Навигация: Вакансии • Задачи • Собесы 🐸Библиотека шарписта #async_news

🤩 EF Core: нормальный способ засевать базу В EF Core 9 появились UseSeeding() и UseAsyncSeeding(), а в актуальном EF Core 10 это уже рекомендуемый Microsoft способ для обычного заполнения базы начальными данными. optionsBuilder .UseSeeding((context, _) => { if (!context.Set<Role>().Any()) { context.Set<Role>().AddRange( new Role { Name = "Admin" }, new Role { Name = "User" }); context.SaveChanges(); } }); Плюс в том, что seed выполняется вместе с Migrate и dotnet ef database update, а EF защищает его механизмом блокировки миграций. 🤩 А HasData теперь лучше использовать для статических и детерминированных данных — например, фиксированного справочника. Для данных, зависящих от состояния БД, внешних API или требующих вычислений, Microsoft рекомендует UseSeeding. Если используете async-вариант, реализуйте и UseSeeding, и UseAsyncSeeding — EF tooling пока опирается на синхронный метод. 🔗 Источник 📍 Навигация: Вакансии • Задачи • Собесы 🐸Библиотека шарписта #sharp_view

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

👨‍💻 Ложная иммутабельность Часто новички в функциональном программировании думают, что сделали иммутабельный код. Берут список, вызывают ToList() или Select() и радуются новому списку. Но в C# это ловушка. Проблема в ссылочных типах. var copy = original.ToList() создаёт новый List, но все элементы внутри — те же самые объекты. Меняете свойство через copy, и оригинал тоже меняется. Правило трёх: 🤩 Records с init-only свойствами для value-like поведения 🤩 ImmutableList<T> из System.Collections.Immutable — настоящие неизменяемые коллекции 🤩 Struct только для маленьких типов 📍 Навигация: Вакансии • Задачи • Собесы 🐸Библиотека шарписта #sharp_view

📎 JsonSerializerOptions в каждом запросе это бомба замедленного действия Вы оптимизировали базу данных. Ничего не изменилось. Оптимизировали сетевые вызовы. Всё ещё медленно. Оказалось, приложение создаёт новый JsonSerializerOptions в каждом запросе. Это уничтожает встроенный кеш метаданных System.Text.Json и превращает JSON сериализацию в дорогую операцию, которая повторяется сотни раз в секунду под нагрузкой. 🤔 Почему это так дорого JsonSerializerOptions это не просто настройки. Это место, где System.Text.Json хранит кэшированные метаданные о том, как сериализовать и десериализовать типы. Каждый новый экземпляр JsonSerializerOptions начинает с пустого кеша. System.Text.Json должна заново анализировать тип, строить информацию о сериализации, кешировать её. Потом запрос закончился и всё выбросилось. Следующий запрос приходит. Новый экземпляр. Пустой кеш снова. Всё сначала. Microsoft так серьёзно относится к этому, что добавили анализатор CA1869, который явно предупреждает: не создавайте JsonSerializerOptions локально в горячих путях. 🤩 Ошибка выглядит безобидно: string ToJson(object value) { var options = new JsonSerializerOptions(JsonSerializerDefaults.Web) { WriteIndented = false }; return JsonSerializer.Serialize(value, options); } Под нагрузкой это выглядит как: — CPU растёт без видимых причин — Задержка становится нестабильной, p99 скачет — Профилер показывает JSON сериализацию как горячую точку — А вы не понимаете почему, если оптимизировали всё остальное 🤩 Создайте JsonSerializerOptions один раз при старте приложения и переиспользуйте везде: public static class JsonDefaults { public static readonly JsonSerializerOptions Web = new(JsonSerializerDefaults.Web) { WriteIndented = false, Converters = { new JsonStringEnumConverter() } }; } Используем кеш, никаких затрат return JsonSerializer.Serialize(payload, JsonDefaults.Web); Одна переменная, кеш остаётся тёплым, производительность стабильной. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #il_люминатор

🤩 F#: упрощённые иерархии интерфейсов с DIM Раньше при работе с C#-интерфейсами, где базовый слот закрыт через дефолтную реализацию интерфейсов, F# всё равно требовал явно реализовать оба интерфейса. Теперь достаточно реализовать только производный интерфейс. 🤩 Допустим, есть такие C#-интерфейсы: public interface IA { int M(); } public interface IB : IA { new int M(); int IA.M() => this.M() + 100; // DIM покрывает слот IA.M } 🤩 Раньше F# требовал реализовать и IA, и IB. Теперь достаточно IB: type C() = interface IB with member _.M() = 42 (C() 😆 IB).M() // 42 (C() 😆 IA).M() // 142 — DIM перенаправляет: this.M() + 100 Улучшение работает не только для простых случаев. Поддерживается ромбовидное наследование, дженерик-интерфейсы, свойства, события, структуры и объектные выражения. Для включения нужен флаг --langversion:preview. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #sharp_view

🤨 ConfigureAwait(false). Почему его любят в библиотеках При await .NET по умолчанию старается продолжить выполнение в захваченном контексте. Например, в UI-приложении это позволяет после await снова работать с UI-потоком. Но библиотеке обычно всё равно, в каком контексте продолжать работу. Поэтому там часто пишут: var data = await httpClient .GetStringAsync(url) .ConfigureAwait(false); ConfigureAwait(false) говорит: не нужно возвращать продолжение в исходный контекст. ✅ Это особенно важно для библиотек: они не должны предполагать, что вызывающий код использует конкретный UI или другой SynchronizationContext. Есть и классический сценарий с deadlock: var result = GetDataAsync().Result; Если GetDataAsync() после await пытается вернуться в занятый контекст, продолжение не может выполниться, а .Result не может завершиться. В ASP.NET Core собственного SynchronizationContext для запросов нет, поэтому классическая проблема с .Result и захватом контекста там не возникает по этой причине. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #il_люминатор

🈶 Паттерны and, or и not. Условия, которые читаются как фраза Проверки диапазонов в C# легко превращаются в цепочки сравнений с && и ||. Паттерны позволяют записать их компактнее. С C# 9 условия можно комбинировать прямо внутри pattern matching: string Grade(int score) => score switch { < 0 or > 100 => "некорректно", >= 90 => "отлично", >= 60 and < 90 => "нормально", _ => "плохо", }; not особенно удобен для проверок: if (value is not null) Process(value); if (obj is not string) return; Паттерны можно комбинировать и с проверкой свойств: bool IsAdultAdmin(User u) => u is { Age: >= 18, Role: "admin" }; Вместо нескольких if получаем одно выражение, где условие читается почти как обычная фраза. 💡 Особенно хорошо такой синтаксис работает там, где нужно описать форму данных или диапазон допустимых значений. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #sharp_view

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

✅ Visual Studio умеет превращать JSON в C#-классы за пару кликов Не нужен онлайн-конвертер. Копируете JSON и в Visual Studio выбираете: Edit → Paste Special → Paste JSON As Classes IDE сама сгенерирует классы, включая вложенные объекты и массивы. Особенно удобно, когда нужно быстро разобраться с ответом незнакомого API или сделать DTO для прототипа. 💡 А после генерации уже стоит привести классы в порядок: переименовать типы, добавить required/init, атрибуты сериализации и убрать лишнее. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #sharp_view