Dotnet | The .NET Blog

SDD Conference 2026

Mon, 11 May 2026 00:00:00 +0000

SDD 2026 проходит с 11 по 15 мая 2026 года в Barbican Centre в Лондоне. Основная 3-дневная конференция — со вторника по четверг, с опциональными однодневными воркшопами в понедельник и пятницу.

С 78 сессиями и 14 воркшопами это одна из самых насыщенных конференций для разработчиков в Европе.

Темы

Архитектурное мышление
Функциональный код на C# 13
Serverless-дизайн
Семантический ИИ
Azure Kubernetes Services
Lean DevOps стратегии
Протокол контекста модели (MCP)
Агентный ИИ в .NET
Рефакторинг монолита
Быстрее программировать с LLM
Криптография в постквантовом мире
Local-First разработка

Спикеры

Программу мирового класса представляют Kevlin Henney, Neal Ford, Sander Hoogendoorn, Andrew Clymer, Jacqui Read, Christian Weyer, Jeff Prosise, Jules May, Oliver Sturm и Raju Gandhi.

Билеты и информация

98% участников SDD 2025 оценили общее впечатление как хорошее, очень хорошее или отличное.

Windows App Dev CLI v0.3: F5 из терминала и UI-автоматизация для агентов

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

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

Опыт F5 в Visual Studio великолепен. Но открывать VS только для запуска и отладки упакованного Windows-приложения — это лишнее, особенно в CI-пайплайне, автоматизированном воркфлоу или когда AI-агент прогоняет тесты.

Windows App Development CLI v0.3 только что вышел и решает это напрямую с двумя ключевыми функциями: winapp run и winapp ui.

winapp run: F5 из любого места

winapp run принимает папку распакованного приложения и манифест, выполняя всё то, что VS делает при отладочном запуске: регистрирует loose-пакет, запускает приложение и сохраняет LocalState между повторными деплоями.

# Собери приложение, затем запусти как упакованное
winapp run ./bin/Debug

Работает для WinUI, WPF, WinForms, Console, Avalonia и других. Режимы рассчитаны как на разработчиков, так и на автоматизированные воркфлоу:

--detach: Запускает и немедленно возвращает управление терминалу. Идеально для CI.
--unregister-on-exit: Удаляет зарегистрированный пакет при закрытии приложения.
--debug-output: Захватывает сообщения OutputDebugString и исключения в реальном времени.

Новый NuGet-пакет: dotnet run для упакованных приложений

Для .NET-разработчиков появился новый NuGet-пакет: Microsoft.Windows.SDK.BuildTools.WinApp. После установки dotnet run берёт на себя весь inner loop: сборка, подготовка loose-layout-пакета, регистрация в Windows и запуск — всё в один шаг.

winapp init
# или
dotnet add package Microsoft.Windows.SDK.BuildTools.WinApp

winapp ui: UI-автоматизация из командной строки

Это функция, открывающая агентные сценарии. winapp ui предоставляет полный доступ UI Automation к любому запущенному Windows-приложению — WPF, WinForms, Win32, Electron, WinUI3 — прямо из терминала.

Что можно делать:

Перечислить все окна верхнего уровня
Обходить полное дерево UI Automation любого окна
Искать элементы по имени, типу или ID автоматизации
Кликать, вызывать и устанавливать значения
Делать снимки экрана
Ждать появления элементов — идеально для синхронизации тестов

Сочетание winapp ui с winapp run создаёт полный воркфлоу build → запуск → проверка из терминала. Агент может запустить приложение, проверить состояние UI, программно взаимодействовать с ним и валидировать результат.

Другие нововведения

winapp unregister: Удаляет sideloaded-пакет после завершения работы.
winapp manifest add-alias: Добавляет алиас для запуска приложения по имени из терминала.
Автодополнение: Одна команда для настройки дополнения в PowerShell.

Как получить

winget install Microsoft.WinAppCli
# или
npm install -g @microsoft/winappcli

CLI находится в публичном превью. Полная документация — в репозитории на GitHub, все подробности — в оригинальном анонсе.

Хуки azd на Python, TypeScript и .NET: прощай, shell-скрипты

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

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

Если вы когда-нибудь вели проект полностью на .NET и всё равно писали Bash-скрипты для хуков azd — вы знаете эту боль. Зачем переходить к синтаксису shell в шаге pre-provisioning, когда весь остальной проект написан на C#?

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

Что такое хуки

Хуки — это скрипты, выполняемые в ключевых точках жизненного цикла azd — до провизионинга, после деплоя и не только. Они определяются в azure.yaml и позволяют внедрять пользовательскую логику без изменений в CLI.

Раньше поддерживались только Bash и PowerShell. Теперь можно использовать Python, JavaScript, TypeScript или .NET — остальное azd обрабатывает автоматически.

Как работает определение языка

Просто укажите хук на файл, и azd определит язык по расширению:

hooks:
 preprovision:
 run: ./hooks/setup.py
 postdeploy:
 run: ./hooks/seed.ts
 postprovision:
 run: ./hooks/migrate.cs

Дополнительная конфигурация не нужна. При неоднозначном расширении можно явно указать kind: python (или нужный язык).

Важные детали по языкам

Python

Разместите requirements.txt или pyproject.toml рядом со скриптом (или в родительской директории). azd автоматически создаёт виртуальное окружение, устанавливает зависимости и запускает скрипт.

JavaScript и TypeScript

Тот же принцип — package.json рядом со скриптом, и azd сначала выполнит npm install. Для TypeScript используется npx tsx без этапа компиляции и без tsconfig.json.

.NET

Два режима:

Режим проекта: если рядом со скриптом есть .csproj, azd автоматически выполнит dotnet restore и dotnet build.
Single-file режим: на .NET 10+ автономные .cs-файлы запускаются напрямую через dotnet run script.cs. Файл проекта не нужен.

Конфигурация по исполнителю

Каждый язык поддерживает опциональный блок config:

hooks:
 preprovision:
 run: ./hooks/setup.ts
 config:
 packageManager: pnpm
 postprovision:
 run: ./hooks/migrate.cs
 config:
 configuration: Release
 framework: net10.0

Почему это важно для .NET-разработчиков

Хуки были последним местом в проекте на базе azd, где приходилось менять язык. Теперь весь деплой-пайплайн — от кода приложения до lifecycle-хуков — может жить в одном языке. Можно переиспользовать существующие .NET-утилиты, ссылаться на общие библиотеки и забыть про поддержку shell-скриптов.

Итог

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

Хватит нянчить терминал: отсоединённый режим Aspire меняет рабочий процесс

Emiliano Montesdeoca — Fri, 17 Apr 2026 00:00:00 +0000

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

Каждый раз, когда вы запускаете Aspire AppHost, ваш терминал пропадает. Заблокирован. Занят, пока вы не нажмёте Ctrl+C. Нужно быстро выполнить команду? Откройте ещё одну вкладку. Хотите проверить логи? Ещё одна вкладка. Мелкое неудобство, которое быстро накапливается.

Aspire 13.2 решает эту проблему. James Newton-King описал все подробности, и, честно говоря, это одна из тех фич, которая сразу меняет подход к работе.

Отсоединённый режим: одна команда — терминал свободен

aspire start

Это сокращение для aspire run --detach. Ваш AppHost запускается в фоне, и терминал сразу возвращается к вам. Никаких лишних вкладок. Никаких мультиплексоров терминала. Просто ваш промпт, готовый к работе.

Управление запущенными процессами

Суть в том, что запуск в фоне полезен только тогда, когда вы можете управлять тем, что работает. Aspire 13.2 поставляется с полным набором CLI-команд именно для этого:

# List all running AppHosts
aspire ps

# Inspect the state of a specific AppHost
aspire describe

# Stream logs from a running AppHost
aspire logs

# Stop a specific AppHost
aspire stop

Это превращает Aspire CLI в полноценный менеджер процессов. Вы можете запускать несколько AppHost, проверять их статус, отслеживать логи и останавливать их — всё из одной сессии терминала.

Сочетание с изолированным режимом

Отсоединённый режим естественно сочетается с изолированным. Хотите запустить два экземпляра одного проекта в фоне без конфликтов портов?

aspire start --isolated
aspire start --isolated

Каждый получает случайные порты, отдельные секреты и собственный жизненный цикл. Используйте aspire ps, чтобы увидеть оба, aspire stop, чтобы остановить ненужный.

Почему это важно для агентов кода

Вот тут становится по-настоящему интересно. Агент кода, работающий в вашем терминале, теперь может:

Запустить приложение с помощью aspire start
Запросить его состояние через aspire describe
Проверить логи через aspire logs для диагностики проблем
Остановить его командой aspire stop по завершении

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

Команда Aspire серьёзно вложилась в это. Запуск aspire agent init настраивает файл навыков Aspire, который обучает агентов этим командам. Таким образом, инструменты вроде агента кода Copilot могут управлять вашими рабочими нагрузками Aspire из коробки.

Подводя итог

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

Прочитайте полный пост для всех подробностей и установите Aspire 13.2 командой aspire update --self.

Кластеризация пинов наконец появилась в .NET MAUI Maps — Одно свойство, ноль проблем

Emiliano Montesdeoca — Thu, 16 Apr 2026 00:00:00 +0000

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

Знаете тот момент, когда загружаешь карту с сотней пинов и всё превращается в нечитаемое пятно? Да, именно так работали .NET MAUI Maps до сих пор. Больше нет.

David Ortinau только что объявил, что .NET MAUI 11 Preview 3 поставляется с кластеризацией пинов из коробки на Android и iOS/Mac Catalyst. И лучшая часть — включить её невероятно просто.

Одно свойство, чтобы править всеми

<maps:Map IsClusteringEnabled="True" />

Вот и всё. Близлежащие пины группируются в кластеры со значком количества. Приближаете — они раскрываются. Отдаляете — сворачиваются. Поведение, которое пользователи ожидают от любой современной карты — и теперь вы получаете его одним свойством.

Независимые группы кластеризации

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

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

map.Pins.Add(new Pin
{
 Label = "Pike Place Coffee",
 Location = new Location(47.6097, -122.3331),
 ClusteringIdentifier = "coffee"
});

map.Pins.Add(new Pin
{
 Label = "Occidental Square",
 Location = new Location(47.6064, -122.3325),
 ClusteringIdentifier = "parks"
});

Пины с одинаковым идентификатором кластеризуются вместе. Разные идентификаторы формируют независимые кластеры, даже если пины расположены рядом. Нет идентификатора? Группа по умолчанию. Чисто и предсказуемо.

Обработка нажатий на кластер

Когда пользователь нажимает на кластер, вы получаете событие ClusterClicked со всем необходимым:

map.ClusterClicked += async (sender, e) =>
{
 string names = string.Join("\n", e.Pins.Select(p => p.Label));
 await DisplayAlert(
 $"Cluster ({e.Pins.Count} pins)",
 names,
 "OK");

 // Suppress default zoom-to-cluster behavior:
 // e.Handled = true;
};

Аргументы события предоставляют Pins (пины в кластере), Location (географический центр) и Handled (установите в true, если хотите переопределить стандартное поведение масштабирования). Просто, практично, именно то, что ожидаешь.

Детали платформ, которые стоит знать

На Android кластеризация использует собственный алгоритм на основе сетки, который пересчитывается при изменении масштаба — без внешних зависимостей. На iOS и Mac Catalyst используется нативная поддержка MKClusterAnnotation из MapKit, что означает плавные, нативные для платформы анимации.

Это один из тех случаев, когда команда MAUI приняла правильное решение — опираться на платформу там, где это имеет смысл.

Почему это важно

Кластеризация пинов была одной из самых запрашиваемых функций в .NET MAUI (issue #11811), и неспроста. Каждое приложение, показывающее местоположения на карте — отслеживание доставки, поиск магазинов, недвижимость — нуждается в этом. Раньше приходилось реализовывать самостоятельно или подключать стороннюю библиотеку. Теперь это встроено.

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

Начинаем

Установите .NET 11 Preview 3 и обновите рабочую нагрузку .NET MAUI. Пример Maps включает новую страницу Clustering, с которой можно поэкспериментировать прямо сейчас.

Создайте что-нибудь с этим — и дайте вашим картам наконец вздохнуть.

.NET Апрель 2026 Servicing — Патчи безопасности, которые стоит применить сегодня

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

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

Сервисные обновления за апрель 2026 для .NET и .NET Framework вышли, и на этот раз в них есть исправления безопасности, которые стоит применить как можно скорее. Исправлено шесть CVE, включая две уязвимости удалённого выполнения кода (RCE).

Что исправлено

Краткая сводка:

CVE	Тип	Затрагивает
CVE-2026-26171	Обход функций безопасности	.NET 10, 9, 8 + .NET Framework
CVE-2026-32178	Удалённое выполнение кода	.NET 10, 9, 8 + .NET Framework
CVE-2026-33116	Удалённое выполнение кода	.NET 10, 9, 8
CVE-2026-32203	Отказ в обслуживании	.NET 10, 9, 8 + .NET Framework
CVE-2026-23666	Отказ в обслуживании	.NET Framework 3.0–4.8.1
CVE-2026-32226	Отказ в обслуживании	.NET Framework 2.0–4.8.1

Две CVE с RCE (CVE-2026-32178 и CVE-2026-33116) затрагивают самый широкий спектр версий .NET и должны быть приоритетом.

Обновлённые версии

.NET 10: 10.0.6
.NET 9: 9.0.15
.NET 8: 8.0.26

Все доступны через обычные каналы — dotnet.microsoft.com, образы контейнеров на MCR и менеджеры пакетов Linux.

Что делать

Обновите свои проекты и пайплайны CI/CD до последних версий с патчами. Если вы используете контейнеры, загрузите последние образы. Если вы на .NET Framework, проверьте примечания к выпуску .NET Framework для соответствующих патчей.

Для тех, кто использует .NET 10 в продакшене (это текущий релиз), обновление до 10.0.6 обязательно. То же касается .NET 9.0.15 и .NET 8.0.26, если вы на этих LTS-версиях. Две уязвимости RCE — это не то, что можно откладывать.

Azure MCP Server 2.0 выпущен — Self-Hosted Agentic Cloud Automation здесь

Emiliano Montesdeoca — Sat, 11 Apr 2026 00:00:00 +0000

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

Если вы в последнее время создавали что-то с MCP и Azure, вы наверняка уже знаете, что локальный опыт работает хорошо. Подключите MCP сервер, позвольте вашему AI агенту общаться с ресурсами Azure, и двигайтесь дальше. Но в момент, когда нужно поделиться этой настройкой с командой? Вот тогда всё становится сложным.

Больше не нужно. Azure MCP Server только что достиг стабильности версии 2.0, и главная фишка — это ровно то, о чём просили enterprise команды: поддержка self-hosted удалённых MCP серверов.

Что такое Azure MCP Server?

Быстрое напоминание. Azure MCP Server реализует спецификацию Model Context Protocol и раскрывает возможности Azure в виде структурированных, обнаруживаемых инструментов, которые AI агенты могут вызывать. Думайте об этом как о стандартизированном мосте между вашим агентом и Azure — provisioning, развёртывание, мониторинг, диагностика, всё через один консистентный интерфейс.

Цифры говорят сами за себя: 276 MCP инструментов в 57 сервисах Azure. Это серьёзное покрытие.

Главное: self-hosted удалённые развёртывания

Вот в чём дело. Запуск MCP локально на вашей машине — это нормально для разработки и экспериментов. Но в реальном сценарии с командой вам нужно:

Общий доступ для разработчиков и внутренних систем агентов
Централизованная конфигурация (контекст тенанта, умолчания подписки, телеметрия)
Enterprise границы сети и политики
Интеграция в CI/CD pipelines

Azure MCP Server 2.0 решает все эти проблемы. Вы можете развернуть его как централизованно управляемый внутренний сервис с HTTP-транспортом, правильной аутентификацией и консистентным управлением.

Для аутентификации у вас есть два хороших варианта:

Managed Identity — при работе рядом с Microsoft Foundry
On-Behalf-Of (OBO) flow — OpenID Connect делегирование, которое вызывает Azure API, используя контекст вошедшего пользователя

Этот OBO flow особенно интересен для нас, .NET разработчиков. Это означает, что ваши agentic workflows могут работать с реальными разрешениями пользователя, а не с какой-то чрезмерно привилегированной сервисной учётной записью. Принцип наименьших привилегий, встроенный прямо туда.

Усиление безопасности

Это не просто выпуск фич — это ещё и выпуск безопасности. Релиз 2.0 добавляет:

Более сильную валидацию endpoints
Защиту от injection паттернов в инструментах, ориентированных на запросы
Более жёсткие элементы управления изоляцией для окружений разработки

Если вы собираетесь раскрывать MCP как общий сервис, эти меры защиты имеют большое значение. Большое.

Где вы можете его использовать?

История совместимости клиентов широкая. Azure MCP Server 2.0 работает с:

IDEs: VS Code, Visual Studio, IntelliJ, Eclipse, Cursor
CLI agents: GitHub Copilot CLI, Claude Code
Standalone: локальный сервер для простых настроек
Self-hosted remote: новая звезда версии 2.0

Плюс есть поддержка sovereign cloud для Azure US Government и Azure, управляемого 21Vianet, что критично для регулируемых развёртываний.

Почему это важно для .NET разработчиков

Если вы создаёте agentic приложения с .NET — будь то Semantic Kernel, Microsoft Agent Framework или ваша собственная оркестровка — Azure MCP Server 2.0 даёт вам production-ready способ дать вашим агентам взаимодействовать с инфраструктурой Azure. Нет пользовательских REST обёрток. Нет сервис-специфичных паттернов интеграции. Просто MCP.

Вместе с fluent API для MCP Apps, который вышел несколько дней назад, экосистема .NET MCP быстро растёт.

Начало работы

Выберите свой путь:

GitHub Repo — исходный код, документация, всё
Docker Image — контейнеризованное развёртывание
VS Code Extension — интеграция IDE
Self-hosting guide — главная фишка версии 2.0

В итоге

Azure MCP Server 2.0 — это ровно тот вид upgrade инфраструктуры, который не выглядит ослепительно на демо, но всё изменяет на практике. Self-hosted удалённый MCP с правильной аутентификацией, усилением безопасности и поддержкой sovereign cloud означает, что MCP готов для реальных команд, создающих реальные agentic workflows на Azure. Если вы ждали сигнала “enterprise-ready” — вот он.

.NET Aspire 13.2 хочет стать лучшим другом вашего ИИ-агента

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

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

Знаете тот момент, когда ваш ИИ-агент пишет отличный код, вы воодушевляетесь, а потом всё разваливается, когда он пытается это запустить? Конфликты портов, процессы-призраки, неправильные переменные окружения — внезапно ваш агент сжигает токены на устранение проблем при запуске вместо создания функциональности.

Команда Aspire только что опубликовала очень продуманный пост именно об этой проблеме, и их ответ убедителен: Aspire 13.2 спроектирован не только для людей, но и для ИИ-агентов.

Проблема реальна

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

Мы нагружаем их Markdown-инструкциями, кастомными навыками и промптами, чтобы направить, но они непредсказуемы, не компилируются и стоят токенов даже для парсинга. Команда Aspire попала в точку с ключевым инсайтом: агентам нужны компиляторы и структурированные API, а не больше Markdown.

Aspire как инфраструктура для агентов

Вот что Aspire 13.2 приносит для агентной разработки:

Весь ваш стек в типизированном коде. AppHost определяет полную топологию — API, фронтенд, базу данных, кэш — в компилируемом TypeScript или C#:

import { createBuilder } from './.modules/aspire.js';

const builder = await createBuilder();

const postgres = await builder.addPostgres("pg").addDatabase("catalog");
const cache = await builder.addRedis("cache");

const api = await builder
 .addNodeApp("api", "./api", "src/index.ts")
 .withHttpEndpoint({ env: "PORT" })
 .withReference(postgres)
 .withReference(cache);

await builder
 .addViteApp("frontend", "./frontend")
 .withReference(api)
 .waitFor(api);

await builder.build().run();

Агент может прочитать это, чтобы понять топологию приложения, добавить ресурсы, настроить связи и скомпилировать для проверки. Компилятор сразу скажет, если что-то не так. Никаких догадок, никаких проб и ошибок с конфигами.

Одна команда, чтобы править ими всеми. Вместо того чтобы агенты жонглировали docker compose up, npm run dev и скриптами запуска баз данных, всё сводится к aspire start. Все ресурсы запускаются в правильном порядке, на правильных портах, с правильной конфигурацией. Долгоживущие процессы тоже не вешают агента — Aspire управляет ими.

Изолированный режим для параллельных агентов. С --isolated каждый запуск Aspire получает собственные случайные порты и отдельные пользовательские секреты. Несколько агентов работают в git worktrees? Они не столкнутся. Это огромное преимущество для инструментов вроде фоновых агентов VS Code, которые создают параллельные среды.

Глаза агента через телеметрию. Вот где становится действительно мощно. Aspire CLI предоставляет полные данные OpenTelemetry во время разработки — трейсы, метрики, структурированные логи. Ваш агент не просто читает вывод консоли и надеется на лучшее. Он может отследить неудавшийся запрос через сервисы, профилировать медленные эндпоинты и точно определить, где что ломается. Это наблюдаемость продакшен-уровня в цикле разработки.

Аналогия с бамперами на боулинге

Команда Aspire использует отличную аналогию: думайте об Aspire как о бамперах на дорожке боулинга для ИИ-агентов. Если агент несовершенен (а он таким и будет), бамперы не дают ему закатывать шар в жёлоб. Определение стека предотвращает неправильную конфигурацию, компилятор ловит ошибки, CLI управляет процессами, а телеметрия обеспечивает обратную связь.

Комбинируйте это с чем-то вроде Playwright CLI, и ваш агент может реально использовать ваше приложение — кликать по флоу, проверять DOM, видеть поломки в телеметрии, исправлять код, перезапускать и тестировать снова. Построить, запустить, наблюдать, исправить. Это тот автономный цикл разработки, к которому мы стремились.

Начало работы

Новичок в Aspire? Установите CLI с get.aspire.dev и следуйте руководству по началу работы.

Уже используете Aspire? Выполните aspire update --self для получения 13.2, затем наведите ваш любимый кодирующий агент на репозиторий. Вы можете удивиться, насколько дальше он продвинется с ограничителями Aspire.

Подведём итоги

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

Читайте полный пост от команды Aspire со всеми деталями и демо-видео.

MCP Apps получили Fluent API — Создавайте богатые UI для AI-инструментов на .NET за три шага

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

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

MCP-инструменты отлично подходят для наделения AI-агентов возможностями. Но что, если вашему инструменту нужно показать что-то пользователю — дашборд, форму, интерактивную визуализацию? Именно для этого и существуют MCP Apps, и теперь их стало намного проще создавать.

Лилиан Касем из команды Azure SDK представила новый Fluent API конфигурации для MCP Apps на .NET Azure Functions — это такое улучшение опыта разработчика, что невольно задаёшься вопросом, почему так просто не было всегда.

Что такое MCP Apps?

MCP Apps расширяют Model Context Protocol, позволяя инструментам нести собственные UI-представления, статические ресурсы и средства управления безопасностью. Вместо простого возврата текста ваш MCP-инструмент может отрисовывать полноценные HTML-интерфейсы — интерактивные дашборды, визуализации данных, формы конфигурации — всё это вызывается AI-агентами и отображается пользователям через MCP-клиенты.

Проблема была в том, что ручная настройка всего этого требовала глубокого знания спецификации MCP: URI ui://, специальные MIME-типы, координация метаданных между инструментами и ресурсами. Не сложно, но утомительно.

Fluent API за три шага

Шаг 1: Определите свою функцию. Стандартный MCP-инструмент Azure Functions:

[Function(nameof(HelloApp))]
public string HelloApp(
 [McpToolTrigger("HelloApp", "A simple MCP App that says hello.")]
 ToolInvocationContext context)
{
 return "Hello from app";
}

Шаг 2: Преобразуйте его в MCP App. В стартапе вашей программы:

builder.ConfigureMcpTool("HelloApp")
 .AsMcpApp(app => app
 .WithView("assets/hello-app.html")
 .WithTitle("Hello App")
 .WithPermissions(McpAppPermissions.ClipboardWrite | McpAppPermissions.ClipboardRead)
 .WithCsp(csp =>
 {
 csp.AllowBaseUri("https://www.microsoft.com")
 .ConnectTo("https://www.microsoft.com");
 }));

Шаг 3: Добавьте HTML-представление. Создайте assets/hello-app.html с нужным вам интерфейсом.

Вот и всё. Fluent API берёт на себя всю сантехнику MCP-протокола — генерирует синтетическую ресурсную функцию, устанавливает правильный MIME-тип и внедряет метаданные, связывающие ваш инструмент с его представлением.

API спроектирован отлично

Несколько вещей, которые мне особенно нравятся:

Источники представлений гибкие. Можно отдавать HTML из файлов на диске или встраивать ресурсы прямо в сборку для автономных развёртываний:

app.WithView(McpViewSource.FromFile("assets/my-view.html"))
app.WithView(McpViewSource.FromEmbeddedResource("MyApp.Resources.view.html"))

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

.WithCsp(csp =>
{
 csp.ConnectTo("https://api.example.com")
 .LoadResourcesFrom("https://cdn.example.com")
 .AllowFrame("https://youtube.com");
})

Управление видимостью. Можно сделать инструмент видимым только для LLM, только для UI хоста или для обоих. Хотите инструмент, который только отрисовывает UI и не должен вызываться моделью? Легко:

.WithVisibility(McpVisibility.App) // UI-only, hidden from the model

Начало работы

Добавьте превью-пакет:

dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Mcp --version 1.5.0-preview.1

Если вы уже создаёте MCP-инструменты с Azure Functions, это просто обновление пакета. Быстрый старт MCP Apps — лучшее место для начала, если вы новичок в этой концепции.

Подводя итоги

MCP Apps — одно из самых захватывающих нововведений в пространстве AI-инструментов: инструменты, которые не просто делают что-то, но могут показывать что-то пользователям. Fluent API убирает сложность протокола и позволяет сосредоточиться на главном: логике вашего инструмента и его интерфейсе.

Прочитайте полный пост для полного справочника по API и примеров.

Изолированный режим Aspire устраняет кошмар конфликтов портов при параллельной разработке

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

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

Если вы когда-нибудь пытались запустить два экземпляра одного проекта одновременно, вы знаете эту боль. Порт 8080 уже используется. Порт 17370 занят. Убить что-то, перезапустить, жонглировать переменными окружения — настоящий убийца продуктивности.

Эта проблема не улучшается, а ухудшается. ИИ-агенты создают git worktrees для независимой работы. Фоновые агенты поднимают отдельные среды. Разработчики дважды клонируют один репозиторий для feature-веток. Каждый из этих сценариев упирается в одну и ту же стену: два экземпляра одного приложения борются за одни и те же порты.

Aspire 13.2 решает это одним флагом. James Newton-King из команды Aspire описал все детали, и это одна из тех фич «почему у нас этого не было раньше».

Решение: `--isolated`

aspire run --isolated

Вот и всё. Каждый запуск получает:

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

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

Реальные сценарии, где это сияет

Множественные checkout. У вас feature-ветка в одной директории и bugfix в другой:

# Terminal 1
cd ~/projects/my-app-feature
aspire run --isolated

# Terminal 2
cd ~/projects/my-app-bugfix
aspire run --isolated

Оба работают без конфликтов. Дашборд показывает, что где запущено.

Фоновые агенты в VS Code. Когда фоновый агент Copilot Chat создаёт git worktree для независимой работы с вашим кодом, ему может понадобиться запустить ваш Aspire AppHost. Без --isolated это конфликт портов с основным worktree. С ним оба экземпляра просто работают.

Навык Aspire, поставляемый с aspire agent init, автоматически инструктирует агентов использовать --isolated при работе в worktrees. Так что фоновый агент Copilot должен справляться с этим из коробки.

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

Как это работает под капотом

Когда вы передаёте --isolated, CLI генерирует уникальный ID экземпляра для запуска. Это управляет двумя поведениями:

Рандомизация портов — вместо привязки к предсказуемым портам, определённым в конфигурации AppHost, изолированный режим выбирает случайные доступные порты для всего — дашборда, эндпоинтов сервисов, всего. Service discovery автоматически подстраивается, чтобы сервисы находили друг друга независимо от назначенных портов.
Изоляция секретов — каждый изолированный запуск получает собственное хранилище пользовательских секретов, привязанное к ID экземпляра. Строки подключения и API-ключи одного запуска не утекают в другой.

Ваш код не нуждается в изменениях. Service discovery Aspire разрешает эндпоинты во время выполнения, так что всё подключается правильно независимо от назначения портов.

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

Используйте --isolated при запуске нескольких экземпляров одного AppHost одновременно — будь то параллельная разработка, автоматизированные тесты, ИИ-агенты или git worktrees. Для разработки с единственным экземпляром, где вы предпочитаете предсказуемые порты, обычный aspire run по-прежнему отлично работает.

Подведём итоги

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

Прочитайте полный пост для всех технических деталей и попробуйте с aspire update --self для получения 13.2.

Оценка модернизации GitHub Copilot — лучший инструмент миграции, который вы ещё не используете

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

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

Миграция устаревшего приложения .NET Framework на современный .NET — одна из тех задач, о которых все знают, что их нужно сделать, но никто не хочет начинать. Это никогда не просто «сменить целевой фреймворк». Это API, которые исчезли, пакеты, которых больше нет, модели хостинга, которые работают совершенно по-другому, и миллион мелких решений о том, что контейнеризировать, что переписать и что оставить как есть.

Джеффри Фриц только что опубликовал глубокий разбор оценки модернизации GitHub Copilot, и честно? Это лучший инструмент миграции для .NET, который я видел. Не из-за генерации кода — это уже стандарт. Из-за документа оценки, который он создаёт.

Это не просто движок предложений кода

Расширение VS Code следует модели Оценить → Спланировать → Выполнить. Фаза оценки анализирует всю кодовую базу и создаёт структурированный документ, фиксирующий всё: что нужно изменить, какие ресурсы Azure предоставить, какую модель развёртывания использовать. Всё последующее — инфраструктура как код, контейнеризация, манифесты развёртывания — вытекает из результатов оценки.

Оценка хранится в .github/modernize/assessment/ вашего проекта. Каждый запуск создаёт независимый отчёт, поэтому вы накапливаете историю и можете отслеживать, как меняется ваша позиция по миграции по мере исправления проблем.

Два способа начать

Рекомендованная оценка — быстрый путь. Выберите из курируемых доменов (Обновление Java/.NET, облачная готовность, безопасность) и получите значимые результаты без настройки конфигурации. Идеально для первого взгляда на состояние вашего приложения.

Пользовательская оценка — прицельный путь. Настройте точно, что анализировать: целевой compute (App Service, AKS, Container Apps), целевую ОС, анализ контейнеризации. Выберите несколько целей Azure для сравнения подходов к миграции бок о бок.

Это представление сравнения действительно полезно. Приложение с 3 обязательными проблемами для App Service может иметь 7 для AKS. Видеть оба варианта помогает принять решение по хостингу до того, как вы привяжетесь к пути миграции.

Разбивка проблем действенна

Каждая проблема сопровождается уровнем критичности:

Обязательная — необходимо исправить, иначе миграция провалится
Потенциальная — может повлиять на миграцию, требует человеческого суждения
Необязательная — рекомендуемые улучшения, не блокируют миграцию

И каждая проблема ссылается на затронутые файлы и номера строк, предоставляет подробное описание того, что не так и почему это важно для вашей целевой платформы, даёт конкретные шаги по устранению (не просто «исправьте это») и включает ссылки на официальную документацию.

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

Охваченные пути обновления

Для .NET конкретно:

.NET Framework → .NET 10
ASP.NET → ASP.NET Core

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

Для команд, управляющих несколькими приложениями, есть также CLI, поддерживающий пакетные оценки нескольких репозиториев — клонируйте все репо, оцените их все, получите отчёты по каждому приложению плюс агрегированное представление портфолио.

Моё мнение

Если вы сидите на устаревших приложениях .NET Framework (а давайте будем честны, большинство корпоративных команд именно так и делает), это тот самый инструмент, с которого стоит начать. Только документ оценки стоит потраченного времени — он превращает расплывчатое «нам бы модернизировать» в конкретный, приоритизированный список рабочих элементов с чёткими путями вперёд.

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

Подводя итоги

Оценка модернизации GitHub Copilot превращает миграцию .NET из пугающего, неопределённого проекта в структурированный, отслеживаемый процесс. Начните с рекомендованной оценки, чтобы увидеть текущее состояние, затем используйте пользовательские оценки для сравнения целей Azure и построения плана миграции.

Прочитайте полное руководство и установите расширение VS Code, чтобы попробовать на своей кодовой базе.

Подключите ваши MCP-серверы на Azure Functions к агентам Foundry — Вот как

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

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

Вот что мне нравится в экосистеме MCP: вы создаёте сервер один раз, и он работает везде. VS Code, Visual Studio, Cursor, ChatGPT — каждый MCP-клиент может обнаруживать и использовать ваши инструменты. Теперь Microsoft добавляет ещё одного потребителя в этот список: агенты Foundry.

Лили Ма из команды Azure SDK опубликовала практическое руководство по подключению MCP-серверов на Azure Functions к агентам Microsoft Foundry. Если у вас уже есть MCP-сервер, это чистая добавленная ценность — никакой перестройки не требуется.

Почему эта комбинация имеет смысл

Azure Functions даёт вам масштабируемую инфраструктуру, встроенную аутентификацию и бессерверную тарификацию для хостинга MCP-серверов. Microsoft Foundry даёт вам AI-агентов, которые могут рассуждать, планировать и выполнять действия. Соединение этих двух означает, что ваши пользовательские инструменты — запросы к базе данных, вызовы бизнес-API, выполнение логики валидации — становятся возможностями, которые корпоративные AI-агенты могут автономно обнаруживать и использовать.

Ключевой момент: ваш MCP-сервер остаётся прежним. Вы просто добавляете Foundry как ещё одного потребителя. Те же инструменты, которые работают в вашей конфигурации VS Code, теперь обеспечивают работу AI-агента, с которым взаимодействуют ваша команда или клиенты.

Варианты аутентификации

Здесь статья действительно приносит пользу. Четыре метода аутентификации в зависимости от вашего сценария:

Метод	Сценарий
На основе ключей (по умолчанию)	Разработка или серверы без аутентификации Entra
Microsoft Entra	Продакшн с управляемыми удостоверениями
Проброс OAuth-удостоверений	Продакшн, где каждый пользователь аутентифицируется отдельно
Без аутентификации	Разработка/тестирование или только публичные данные

Для продакшна рекомендуется Microsoft Entra с идентификацией агента. Проброс OAuth-удостоверений — для случаев, когда важен контекст пользователя: агент предлагает пользователям войти, и каждый запрос несёт собственный токен пользователя.

Настройка

Общий поток:

Разверните MCP-сервер на Azure Functions — доступны примеры для .NET, Python, TypeScript и Java
Включите встроенную MCP-аутентификацию на вашем function app
Получите URL эндпоинта — https://<FUNCTION_APP_NAME>.azurewebsites.net/runtime/webhooks/mcp
Добавьте MCP-сервер как инструмент в Foundry — перейдите к агенту в портале, добавьте новый MCP-инструмент, укажите эндпоинт и учётные данные

Затем протестируйте в песочнице Agent Builder, отправив запрос, который активирует один из ваших инструментов.

Моё мнение

История компонуемости здесь становится по-настоящему сильной. Создайте MCP-сервер один раз на .NET (или Python, TypeScript, Java), разверните на Azure Functions, и каждый MCP-совместимый клиент может его использовать — инструменты для кодирования, чат-приложения, а теперь и корпоративные AI-агенты. Это паттерн «напиши один раз, используй везде», который действительно работает.

Для .NET-разработчиков конкретно, расширение MCP для Azure Functions делает это простым. Вы определяете инструменты как Azure Functions, развёртываете — и у вас есть MCP-сервер продакшн-уровня со всей безопасностью и масштабированием, которые предоставляет Azure Functions.

Подводя итоги

Если у вас есть MCP-инструменты на Azure Functions, подключение к агентам Foundry — быстрый выигрыш: ваши пользовательские инструменты становятся корпоративными AI-возможностями с правильной аутентификацией и без изменений кода на сервере.

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

C# 15 получает типы-объединения — и это именно то, что мы просили

Emiliano Montesdeoca — Sun, 05 Apr 2026 00:00:00 +0000

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

Это та самая фича, которую я ждал. C# 15 вводит ключевое слово union — настоящие размеченные объединения с исчерпывающим сопоставлением с образцом, контролируемым компилятором. Если вы когда-нибудь завидовали размеченным объединениям F# или enum в Rust, вы точно знаете, почему это важно.

Билл Вагнер опубликовал подробный разбор в блоге .NET, и честно? Дизайн чистый, практичный и очень в духе C#. Давайте я покажу, что тут на самом деле есть и почему это более значимо, чем может показаться на первый взгляд.

Проблема, которую решают объединения

До C# 15 возврат «одного из нескольких возможных типов» из метода всегда был компромиссом:

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

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

Синтаксис красиво прост

public record class Cat(string Name);
public record class Dog(string Name);
public record class Bird(string Name);

public union Pet(Cat, Dog, Bird);

Одна строка. Pet может содержать Cat, Dog или Bird. Неявные преобразования генерируются автоматически:

Pet pet = new Dog("Rex");
Console.WriteLine(pet.Value); // Dog { Name = Rex }

А вот и магия — компилятор обеспечивает исчерпывающее сопоставление:

string name = pet switch
{
 Dog d => d.Name,
 Cat c => c.Name,
 Bird b => b.Name,
};

Дискард _ не нужен. Компилятор знает, что этот switch покрывает все возможные случаи. Если позже вы добавите четвёртый тип в объединение, каждое выражение switch, которое его не обрабатывает, выдаст предупреждение. Пропущенные случаи обнаруживаются на этапе сборки, а не в рантайме.

Где это становится практичным

Пример с Pet милый, но вот где объединения действительно сияют в реальном коде.

API-ответы, возвращающие разные формы

public union ApiResult<T>(T, ApiError, ValidationFailure);

Теперь каждый потребитель вынужден обрабатывать успех, ошибку и ошибку валидации. Больше никаких багов «забыл проверить случай ошибки».

Одно значение или коллекция

Паттерн OneOrMore<T> показывает, как объединения могут иметь тело со вспомогательными методами:

public union OneOrMore<T>(T, IEnumerable<T>)
{
 public IEnumerable<T> AsEnumerable() => Value switch
 {
 T single => [single],
 IEnumerable<T> multiple => multiple,
 null => []
 };
}

Вызывающий код передаёт удобную форму:

OneOrMore<string> tags = "dotnet";
OneOrMore<string> moreTags = new[] { "csharp", "unions", "preview" };

foreach (var tag in tags.AsEnumerable())
 Console.Write($"[{tag}] ");
// [dotnet]

Композиция несвязанных типов

Это убойная фича по сравнению с традиционными иерархиями. Можно объединять типы, не имеющие ничего общего — string и Exception, int и IEnumerable<T>. Общий предок не нужен.

Пользовательские объединения для существующих библиотек

Вот умное решение в дизайне: любой класс или struct с атрибутом [Union] распознаётся как тип-объединение, если он следует базовому паттерну (публичные конструкторы для типов-случаев и свойство Value). Библиотеки вроде OneOf, которые уже предоставляют типы, похожие на объединения, могут подключить поддержку компилятора без переписывания внутренней реализации.

Для чувствительных к производительности сценариев с типами-значениями библиотеки могут реализовать паттерн доступа без boxing через методы HasValue и TryGetValue.

Общая картина

Типы-объединения — часть более широкой истории исчерпывающей проверки в C#:

Типы-объединения — исчерпывающее сопоставление по замкнутому набору типов (доступно сейчас в preview)
Закрытые иерархии — модификатор closed предотвращает создание производных классов вне определяющей сборки (предложено)
Закрытые enum — предотвращает создание значений, отличных от объявленных членов (предложено)

Вместе эти три фичи дадут C# одну из самых полных систем типобезопасного сопоставления с образцом среди всех мейнстримных языков.

Попробуйте сегодня

Типы-объединения доступны в .NET 11 Preview 2:

Установите .NET 11 Preview SDK
Укажите net11.0 в качестве целевой платформы проекта
Установите <LangVersion>preview</LangVersion>

Одно замечание: в Preview 2 вам нужно объявить UnionAttribute и IUnion в проекте, так как их ещё нет в рантайме. Возьмите RuntimePolyfill.cs из репозитория документации, или добавьте это:

namespace System.Runtime.CompilerServices
{
 [AttributeUsage(AttributeTargets.Class | AttributeTargets.Struct,
 AllowMultiple = false)]
 public sealed class UnionAttribute : Attribute;

 public interface IUnion
 {
 object? Value { get; }
 }
}

Подводя итог

Типы-объединения — одна из тех фич, которые заставляют задуматься, как мы обходились без них. Исчерпывающее сопоставление, контролируемое компилятором, чистый синтаксис, поддержка дженериков и интеграция с существующим pattern matching — это всё, что мы просили, реализованное в стиле C#.

Попробуйте их в .NET 11 Preview 2, ломайте вещи и делитесь обратной связью на GitHub. Это preview, и команда C# активно слушает. Ваши граничные случаи и отзывы о дизайне повлияют на финальный релиз.

Полную языковую справку смотрите в документации по типам-объединениям и спецификации фичи.

Aspire 13.2 получает CLI для документации — и ваш ИИ-агент тоже может им пользоваться

Emiliano Montesdeoca — Sat, 04 Apr 2026 00:00:00 +0000

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

Знаете тот момент, когда вы погружены в Aspire AppHost, подключаете интеграции, и вам нужно проверить, какие именно параметры ожидает интеграция Redis? Вы переключаетесь Alt-Tab на браузер, ищете на aspire.dev, вглядываетесь в документацию API, возвращаетесь в редактор. Контекст потерян. Поток прерван.

Aspire 13.2 только что выпустил решение этой проблемы. CLI aspire docs позволяет искать, просматривать и читать официальную документацию Aspire прямо из терминала. А поскольку за ним стоят переиспользуемые сервисы, ИИ-агенты и навыки могут использовать те же самые команды для поиска документации вместо того, чтобы галлюцинировать несуществующие API.

Проблема, которую это действительно решает

David Pine точно подмечает в оригинальном посте: ИИ-агенты были ужасны в помощи разработчикам при создании приложений на Aspire. Они рекомендовали dotnet run вместо aspire run, ссылались на learn.microsoft.com для документации, которая живёт на aspire.dev, предлагали устаревшие NuGet-пакеты, и — моё любимое — галлюцинировали API, которых не существует.

Почему? Потому что Aspire был специфичен для .NET гораздо дольше, чем является полиглотом, а LLM работают на тренировочных данных, которые предшествуют последним возможностям. Когда вы даёте ИИ-агенту возможность реально искать актуальную документацию, он перестаёт угадывать и начинает быть полезным.

Три команды, ноль вкладок браузера

CLI освежающе прост:

Показать всю документацию

aspire docs list

Возвращает каждую страницу документации, доступную на aspire.dev. Нужен машиночитаемый вывод? Добавьте --format Json.

Поиск по теме

aspire docs search "redis"

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

Чтение полной страницы (или только одного раздела)

aspire docs get redis-integration

Выводит полную страницу в формате markdown в ваш терминал. Нужен только один раздел?

aspire docs get redis-integration --section "Add Redis resource"

Хирургическая точность. Никакого прокручивания 500 строк. Только нужная часть.

Аспект ИИ-агентов

Вот где становится интересно для нас, разработчиков, работающих с ИИ-инструментами. Те же команды aspire docs работают как инструменты для ИИ-агентов — через навыки, MCP-серверы или простые CLI-обёртки.

Вместо того чтобы ваш ИИ-ассистент придумывал API Aspire на основе устаревших тренировочных данных, он может вызвать aspire docs search "postgres", найти официальную документацию по интеграции, прочитать нужную страницу и дать вам документированный подход. Актуальная документация в реальном времени — а не то, что модель запомнила шесть месяцев назад.

Архитектура за этим — намеренная. Команда Aspire создала переиспользуемые сервисы (IDocsIndexService, IDocsSearchService, IDocsFetcher, IDocsCache) вместо одноразовой интеграции. Это значит, что один и тот же поисковый движок работает для людей в терминале, ИИ-агентов в редакторе и автоматизации в CI-пайплайне.

Реальные сценарии

Быстрые справки в терминале: Вы на три файла в глубину и вам нужны параметры конфигурации Redis. Две команды, девяносто секунд, обратно к работе:

aspire docs search "redis" --limit 1
aspire docs get redis-integration --section "Configuration"

Разработка с помощью ИИ: Ваш навык VS Code оборачивает команды CLI. Вы спрашиваете «Добавь базу данных PostgreSQL в мой AppHost», и агент сначала смотрит реальную документацию, а потом отвечает. Никаких галлюцинаций.

Валидация CI/CD: Ваш пайплайн программно проверяет конфигурации AppHost по официальной документации. Вывод --format Json чисто передаётся в jq и другие инструменты.

Пользовательские базы знаний: Создаёте свои ИИ-инструменты? Направляйте структурированный JSON-вывод напрямую в свою базу знаний:

aspire docs search "monitoring" --format Json | jq '[.[] | {slug, title, summary}]'

Никакого веб-скрейпинга. Никаких API-ключей. Те же структурированные данные, которые используются внутренне инструментами документации.

Документация всегда актуальна

Это то, что я ценю больше всего. CLI не скачивает снимок — он обращается к aspire.dev с кэшированием на основе ETag. В момент обновления документации ваш CLI и любой навык, построенный на его основе, отражает это. Никаких устаревших копий, никаких моментов «но в вики было написано…».

Подводя итог

aspire docs — это одна из тех маленьких функций, которая решает реальную проблему чисто и элегантно. Люди получают доступ к документации прямо в терминале. ИИ-агенты получают способ перестать угадывать и начать ссылаться на реальные документы. И всё это подкреплено одним и тем же источником истины.

Если вы разрабатываете на .NET Aspire и ещё не попробовали CLI, запустите aspire docs search "ваша-тема" и почувствуйте, как это работает. Затем подумайте о том, чтобы обернуть эти команды в свои ИИ-навыки или настройки автоматизации — ваши агенты скажут вам спасибо.

Ознакомьтесь с глубоким разбором David Pine о том, как создавались инструменты документации, и с официальной справкой CLI для всех деталей.

Microsoft Agent Framework Достиг 1.0 — Вот Что Действительно Важно для .NET-Разработчиков

Emiliano Montesdeoca — Fri, 03 Apr 2026 00:00:00 +0000

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

Если вы следили за путешествием Agent Framework с ранних дней Semantic Kernel и AutoGen, это событие значительное. Microsoft Agent Framework только что достиг версии 1.0 — готов к продакшену, стабильные API, обязательство долгосрочной поддержки. Он доступен и для .NET, и для Python, и действительно готов к реальным нагрузкам.

Давайте пробьёмся через шум анонса и сосредоточимся на том, что важно, если вы создаёте AI-приложения на .NET.

Коротко

Agent Framework 1.0 объединяет то, что раньше было Semantic Kernel и AutoGen, в единый SDK с открытым исходным кодом. Одна абстракция агента. Один движок оркестрации. Множество AI-провайдеров. Если вы метались между Semantic Kernel для корпоративных паттернов и AutoGen для исследовательских мульти-агентных рабочих процессов, можете остановиться. Теперь это единственный SDK.

Начать работу почти нечестно просто

Вот работающий агент на .NET:

// dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
using Azure.Identity;

var agent = new AIProjectClient(endpoint: "https://your-project.services.ai.azure.com")
 .GetResponsesClient("gpt-5.3")
 .AsAIAgent(
 name: "HaikuBot",
 instructions: "You are an upbeat assistant that writes beautifully."
 );

Console.WriteLine(await agent.RunAsync("Write a haiku about shipping 1.0."));

Вот и всё. Несколько строк — и у вас есть AI-агент, работающий через Azure Foundry. Эквивалент на Python столь же лаконичен. Добавляйте инструменты-функции, многоходовые диалоги и стриминг по мере необходимости — поверхность API масштабируется без странностей.

Мульти-агентная оркестрация — это серьёзно

Одиночные агенты подходят для демо, но продакшен-сценарии обычно требуют координации. Agent Framework 1.0 поставляется с проверенными в бою паттернами оркестрации прямо из Microsoft Research и AutoGen:

Последовательная — агенты обрабатывают по очереди (писатель → рецензент → редактор)
Параллельная — распределение по нескольким агентам параллельно, объединение результатов
Handoff — один агент делегирует другому на основе намерения
Групповой чат — несколько агентов обсуждают и сходятся к решению
Magentic-One — исследовательский мульти-агентный паттерн от MSR

Все поддерживают стриминг, чекпоинты, одобрения с участием человека и паузу/возобновление. Часть с чекпоинтами критически важна — долго работающие процессы переживают перезапуски. Для нас, .NET-разработчиков, строивших устойчивые рабочие процессы с Azure Functions, это знакомое ощущение.

Самые важные возможности

Вот мой список того, что стоит знать:

Middleware-хуки. Знаете, как ASP.NET Core имеет middleware-конвейеры? Тот же концепт, но для выполнения агентов. Перехватывайте каждый этап — добавляйте безопасность контента, логирование, политики соответствия — не трогая промпты агента. Именно так вы делаете агентов готовыми для enterprise.

Подключаемая память. История разговоров, персистентное key-value состояние, векторный поиск. Выбирайте бэкенд: Foundry Agent Service, Mem0, Redis, Neo4j или создайте свой. Память — это то, что превращает stateless-вызов LLM в агента, который действительно помнит контекст.

Декларативные YAML-агенты. Определяйте инструкции агента, инструменты, память и топологию оркестрации в версионируемых YAML-файлах. Загружайте и запускайте одним вызовом API. Это меняет правила игры для команд, которые хотят итерировать поведение агента без редеплоя кода.

Поддержка A2A и MCP. MCP (Model Context Protocol) позволяет агентам динамически обнаруживать и вызывать внешние инструменты. A2A (протокол Agent-to-Agent) обеспечивает кросс-рантайм взаимодействие — ваши .NET-агенты могут координироваться с агентами в других фреймворках. Поддержка A2A 1.0 появится в ближайшее время.

Превью-возможности, за которыми стоит следить

Некоторые возможности вышли в превью в 1.0 — функциональны, но API могут измениться:

DevUI — локальный отладчик в браузере для визуализации выполнения агента, потоков сообщений и вызовов инструментов в реальном времени. Представьте Application Insights, но для рассуждений агента.
GitHub Copilot SDK и Claude Code SDK — используйте Copilot или Claude как агентную обвязку прямо из кода оркестрации. Составляйте агента с возможностями программирования рядом с другими агентами в одном рабочем процессе.
Agent Harness — настраиваемый локальный рантайм, дающий агентам доступ к шеллу, файловой системе и циклам обмена сообщениями. Думайте о кодинг-агентах и паттернах автоматизации.
Skills — переиспользуемые пакеты доменных возможностей, дающие агентам структурированные способности из коробки.

Миграция с Semantic Kernel или AutoGen

Если у вас есть существующий код на Semantic Kernel или AutoGen, есть специальные помощники миграции, которые анализируют ваш код и генерируют пошаговые планы миграции. Руководство по миграции с Semantic Kernel и руководство по миграции с AutoGen проведут вас через всё.

Если вы были на RC-пакетах, обновление до 1.0 — это просто смена версии.

Подводя итог

Agent Framework 1.0 — это продакшен-веха, которую ждали корпоративные команды. Стабильные API, поддержка нескольких провайдеров, паттерны оркестрации, реально работающие в масштабе, и пути миграции как с Semantic Kernel, так и с AutoGen.

Фреймворк полностью открыт на GitHub, и вы можете начать прямо сейчас с dotnet add package Microsoft.Agents.AI. Посмотрите руководство по быстрому старту и примеры, чтобы попробовать на практике.

Если вы ждали сигнала «безопасно использовать в продакшене» — вот он.

azd теперь позволяет запускать и отлаживать ИИ-агенты локально — Что изменилось в марте 2026

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

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

Семь релизов за месяц. Именно столько выпустила команда Azure Developer CLI (azd) в марте 2026, и главная фича — та, которую я ждал: локальный цикл запуска и отладки для ИИ-агентов.

PC Chan опубликовала полный обзор, и хотя там много всего, позвольте мне отфильтровать то, что действительно важно для .NET-разработчиков, создающих приложения с ИИ.

Запуск и отладка ИИ-агентов без деплоя

Это главное. Новое расширение azure.ai.agents добавляет команды для полноценного inner-loop для ИИ-агентов:

azd ai agent run — запускает агент локально
azd ai agent invoke — отправляет сообщения (локально или в продакшн)
azd ai agent show — показывает статус контейнера и здоровье
azd ai agent monitor — стримит логи контейнера в реальном времени

Раньше тестирование ИИ-агента означало деплой в Microsoft Foundry при каждом изменении. Теперь можно итерировать локально, тестировать поведение агента и деплоить только когда готов.

GitHub Copilot настраивает ваш azd-проект

azd init теперь предлагает опцию “Set up with GitHub Copilot (Preview)”. Вместо ручного ответа на промпты, Copilot-агент генерирует конфигурацию за вас. Когда команда падает, azd предлагает ИИ-ассистированное устранение неполадок — всё не выходя из терминала.

Container App Jobs и улучшения деплоя

Container App Jobs: azd теперь деплоит Microsoft.App/jobs через существующую конфигурацию host: containerapp.
Настраиваемые таймауты деплоя: Новый флаг --timeout в azd deploy и поле deployTimeout в azure.yaml.
Фолбэк удалённой сборки: При неудаче ACR-сборки azd автоматически переключается на локальный Docker/Podman.
Локальная preflight-валидация: Bicep-параметры проверяются локально перед деплоем.

Улучшения DX

Автоматическое определение pnpm/yarn для JS/TS-проектов
Поддержка pyproject.toml для Python
Локальные каталоги шаблонов — azd init --template принимает пути файловой системы
Улучшенные сообщения об ошибках в режиме --no-prompt
Переменные окружения сборки — инжектируются во все подпроцессы сборки (.NET, Node.js, Java, Python)

Подведём итоги

Локальный цикл отладки ИИ-агентов — звезда этого релиза, но совокупность улучшений деплоя и DX делает azd более зрелым, чем когда-либо. Если вы деплоите .NET-приложения в Azure — особенно ИИ-агенты — это обновление стоит внимания.

Ознакомьтесь с полными заметками о выпуске.

Дашборд Aspire 13.2 теперь с API телеметрии — и это меняет всё

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

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

Если вы создавали распределённые приложения на .NET Aspire, вы уже знаете, что дашборд — лучшая часть всего опыта. Все ваши трейсы, логи и метрики в одном месте — без внешнего Jaeger, без настройки Seq, без моментов «дай проверю другой терминал».

Aspire 13.2 значительно всё улучшил. James Newton-King объявил об обновлении, и честно? Функции экспорта телеметрии и API сами по себе стоят обновления.

Экспорт телеметрии по-человечески

Вот сценарий, который мы все пережили: вы отлаживаете распределённую проблему, наконец воспроизводите её после двадцати минут настройки, и теперь нужно показать команде, что произошло. Раньше? Скриншоты. Копирование ID трейсов. Обычный хаос.

Aspire 13.2 добавляет диалог Управление логами и телеметрией, где можно:

Очистить всю телеметрию (полезно перед попыткой воспроизведения)
Экспортировать выбранную телеметрию в ZIP-файл в стандартном формате OTLP/JSON
Повторно импортировать этот ZIP в любой дашборд Aspire позже

Последний пункт — это убийственная фича. Вы воспроизводите баг, экспортируете телеметрию, прикрепляете к рабочему элементу, и ваш коллега может импортировать её в свой дашборд, чтобы увидеть именно то, что видели вы. Больше никаких «можешь воспроизвести у себя?»

Отдельные трейсы, спаны и логи также получили опцию «Export JSON» в контекстных меню. Нужно поделиться конкретным трейсом? Правый клик, копируете JSON, вставляете в описание PR. Готово.

API телеметрии — настоящий прорыв

Вот чему я больше всего рад. Дашборд теперь предоставляет HTTP API по пути /api/telemetry для программного запроса данных телеметрии. Доступные эндпоинты:

GET /api/telemetry/resources — список ресурсов с телеметрией
GET /api/telemetry/spans — запрос спанов с фильтрами
GET /api/telemetry/logs — запрос логов с фильтрами
GET /api/telemetry/traces — список трейсов
GET /api/telemetry/traces/{traceId} — все спаны конкретного трейса

Всё возвращается в формате OTLP JSON. Это питает новые CLI-команды aspire agent mcp и aspire otel, но реальное значение больше: теперь можно создавать инструменты, скрипты и интеграции с ИИ-агентами, которые напрямую запрашивают телеметрию вашего приложения.

Представьте ИИ-агента для кодинга, который может видеть ваши реальные распределённые трейсы во время отладки. Это уже не гипотетически — именно это делает возможным этот API.

Телеметрия GenAI становится практичной

Если вы создаёте приложения с ИИ на Semantic Kernel или Microsoft.Extensions.AI, вам понравится улучшенный визуализатор телеметрии GenAI. Aspire 13.2 добавляет:

Описания ИИ-инструментов отображаются как Markdown
Специальная кнопка GenAI на странице трейсов для быстрого доступа
Улучшенная обработка ошибок для обрезанного или нестандартного JSON GenAI
Навигация с подсветкой по клику между определениями инструментов

Пост упоминает, что VS Code Copilot chat, Copilot CLI и OpenCode поддерживают настройку OTEL_EXPORTER_OTLP_ENDPOINT. Направьте их на дашборд Aspire, и вы буквально сможете наблюдать, как ваши ИИ-агенты думают в реальном времени через телеметрию. Такой опыт отладки вы больше нигде не найдёте.

Подведём итоги

Aspire 13.2 превращает дашборд из «приятного UI для отладки» в «программируемую платформу наблюдаемости». Рабочий процесс экспорта/импорта сам по себе экономит реальное время при распределённой отладке, а API телеметрии открывает дверь к диагностике с помощью ИИ.

Если вы уже на Aspire — обновляйтесь. Если нет — это хороший повод попробовать aspire.dev.

Мартовское обновление Visual Studio позволяет создавать собственные агенты Copilot — и find_symbol меняет правила игры

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

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

Visual Studio только что получила самое значительное обновление Copilot. Mark Downie объявил о мартовском релизе, и заголовок — пользовательские агенты, но честно говоря, инструмент find_symbol может оказаться функцией, которая больше всего изменит ваш рабочий процесс.

Пользовательские агенты Copilot в вашем репозитории

Хотите, чтобы Copilot следовал стандартам кодирования вашей команды? Пользовательские агенты определяются как файлы .agent.md в .github/agents/. Каждый агент имеет полный доступ к workspace, пониманию кода, инструментам, вашей предпочтительной модели и MCP-соединениям.

Навыки агента: переиспользуемые наборы инструкций

Навыки автоматически подхватываются из .github/skills/ в вашем репозитории или ~/.copilot/skills/ в профиле.

find_symbol: навигация с поддержкой языка

Новый инструмент find_symbol даёт агентному режиму Copilot навигацию по символам на основе языковых сервисов. Вместо текстового поиска агент может находить все ссылки на символ и получать доступ к информации о типах и области видимости.

Для .NET-разработчиков это огромное улучшение — кодовые базы на C# с глубокими иерархиями типов получают огромную пользу.

Профилирование тестов с Copilot

В контекстном меню Test Explorer появился Profile with Copilot. Profiling Agent запускает тест и автоматически анализирует производительность.

Perf Tips во время отладки

Оптимизация производительности теперь происходит прямо во время отладки. Visual Studio показывает время выполнения inline. Увидели медленную строку? Кликните Perf Tip и попросите Copilot предложить оптимизации.

Исправление уязвимостей NuGet из Solution Explorer

При обнаружении уязвимости NuGet-пакета в Solution Explorer появляется ссылка Fix with GitHub Copilot.

Подведём итоги

Пользовательские агенты и навыки — заголовок, но find_symbol — скрытая жемчужина, которая фундаментально меняет точность Copilot при рефакторинге .NET-кода. Скачайте Visual Studio 2026 Insiders, чтобы всё попробовать.

KubeCon Europe 2026: Что на самом деле важно для .NET-разработчиков

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

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

Знаете это чувство, когда выходит огромный пост с анонсами и вы листаете его, думая «круто, но что это на самом деле меняет для меня»? Это я каждый сезон KubeCon.

Microsoft только что опубликовала свой полный обзор KubeCon Europe 2026 — написанный лично Бренданом Бёрнсом — и честно? Здесь настоящая суть. Не просто чеклисты фич, а операционные улучшения, которые меняют подход к управлению в продакшене.

Давайте разберём, что действительно важно для нас, .NET-разработчиков.

mTLS без налога service mesh

Вот в чём дело с service mesh: все хотят гарантий безопасности, никто не хочет операционной нагрузки. AKS наконец закрывает этот разрыв.

Azure Kubernetes Application Network даёт вам mutual TLS, авторизацию с учётом приложения и телеметрию трафика — без развёртывания полного mesh с тяжёлыми sidecar. В сочетании с Cilium mTLS в Advanced Container Networking Services вы получаете зашифрованную связь между подами с использованием сертификатов X.509 и SPIRE для управления идентификацией.

Что это значит на практике: ваши ASP.NET Core API общаются с фоновыми воркерами, ваши gRPC-сервисы вызывают друг друга — всё зашифровано и верифицировано на сетевом уровне, без единого изменения в коде приложения. Это серьёзно.

Для команд, мигрирующих с ingress-nginx, есть также Application Routing с Meshless Istio с полной поддержкой Kubernetes Gateway API. Без sidecar. На основе стандартов. Плюс инструменты ingress2gateway для постепенной миграции.

Наблюдаемость GPU — не как запоздалая мысль

Если вы запускаете AI-инференс рядом с .NET-сервисами (а давайте честно, кто сейчас не начинает?), вы наверняка столкнулись со слепым пятном мониторинга GPU. У вас были отличные дашборды CPU/памяти, а потом… ничего для GPU без ручной настройки экспортёров.

AKS теперь показывает метрики GPU нативно в управляемых Prometheus и Grafana. Тот же стек, те же дашборды, тот же пайплайн алертов. Без кастомных экспортёров, без сторонних агентов.

На сетевой стороне добавлена видимость по потокам для HTTP, gRPC и Kafka-трафика с Azure Monitor в один клик. IP, порты, ворклоуды, направление потока, решения по политикам — всё во встроенных дашбордах.

А вот то, от чего я посмотрел дважды: agentic container networking добавляет веб-интерфейс, где можно задавать вопросы на естественном языке о состоянии сети кластера. «Почему под X не достигает сервис Y?» → диагностика только для чтения из live-телеметрии. Реально полезно в 2 часа ночи.

Кросс-кластерная сеть без учёной степени

Мульти-кластерный Kubernetes исторически был опытом «принеси свой сетевой клей». Azure Kubernetes Fleet Manager теперь обеспечивает кросс-кластерную сеть через управляемый Cilium cluster mesh:

Единая связность между кластерами AKS
Глобальный реестр сервисов для кросс-кластерного обнаружения
Конфигурация управляется централизованно, а не повторяется для каждого кластера

Если вы запускаете .NET-микросервисы в нескольких регионах для отказоустойчивости или соответствия требованиям, это заменяет много хрупкого кастомного клея. Сервис A в West Europe может обнаружить и вызвать Сервис B в East US через mesh, с согласованными политиками маршрутизации и безопасности.

Обновления, не требующие смелости

Давайте честно — обновления Kubernetes в продакшене — это стресс. «Обновить и надеяться» было стратегией по умолчанию для слишком многих команд и главной причиной, по которой кластеры отстают по версиям.

Две новые возможности меняют это:

Blue-green обновления пулов агентов создают параллельный пул нод с новой конфигурацией. Валидируйте поведение, постепенно переключайте трафик и сохраняйте чистый путь отката. Больше никаких мутаций на месте на продакшн-нодах.

Откат пула агентов позволяет вернуть пул нод на предыдущую версию Kubernetes и образ ноды после неудачного обновления — без пересборки кластера.

Вместе они наконец дают операторам реальный контроль над жизненным циклом обновлений. Для .NET-команд это важно, потому что скорость платформы напрямую определяет, как быстро вы можете принять новые рантаймы, патчи безопасности и сетевые возможности.

AI-рабочие нагрузки становятся полноценными гражданами Kubernetes

Upstream-работа в open source не менее важна. Dynamic Resource Allocation (DRA) только что стала GA в Kubernetes 1.36, сделав планирование GPU настоящей первоклассной функцией вместо обходного пути.

Проекты, за которыми стоит следить:

Проект	Что делает
AI Runway	Общий Kubernetes API для инференса — деплой моделей без знания K8s, с обнаружением HuggingFace и оценкой стоимости
HolmesGPT	Агентный troubleshooting для cloud-native — теперь проект CNCF Sandbox
Dalec	Декларативная сборка образов контейнеров с генерацией SBOM — меньше CVE на этапе сборки

Направление ясно: ваш .NET API, слой оркестрации на Semantic Kernel и ваши рабочие нагрузки инференса должны работать на одной согласованной платформенной модели. Мы приближаемся.

С чего бы я начал на этой неделе

Если вы оцениваете эти изменения для своей команды, вот мой честный список приоритетов:

Наблюдаемость в первую очередь — включите метрики GPU и логи сетевых потоков в непродакшен-кластере. Посмотрите, что вы упускали.
Попробуйте blue-green обновления — протестируйте workflow отката перед следующим обновлением продакшен-кластера. Постройте доверие к процессу.
Пилотируйте сеть с учётом идентичности — выберите один внутренний путь сервиса и включите mTLS с Cilium. Измерьте оверхед (спойлер: минимальный).
Оцените Fleet Manager — если у вас больше двух кластеров, кросс-кластерная сеть окупается за счёт сокращения кастомного клея.

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

Подводя итог

Анонсы KubeCon могут быть ошеломляющими, но эта порция реально двигает стрелку для .NET-команд на AKS. Лучшая сетевая безопасность без оверхеда mesh, настоящая наблюдаемость GPU, более безопасные обновления и более прочные основы AI-инфраструктуры.

Если вы уже на AKS, сейчас отличный момент укрепить ваш операционный baseline. А если планируете перенести .NET-рабочие нагрузки на Kubernetes — платформа только что стала значительно более готовой к продакшену.

Foundry Agent Service вышел в GA: что действительно важно для .NET-разработчиков агентов

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

Будем честны — создать прототип ИИ-агента — это простая часть. Сложная часть — всё, что идёт после: вывести его в продакшен с правильной сетевой изоляцией, запустить оценки, которые действительно что-то значат, обеспечить соответствие требованиям и не сломать ничего в 2 часа ночи.

Foundry Agent Service только что вышел в GA, и этот релиз сфокусирован именно на этом разрыве «всё, что после».

Построен на Responses API

Вот главная новость: Foundry Agent Service нового поколения построен на OpenAI Responses API. Если вы уже работаете с этим wire-протоколом, миграция на Foundry — это минимальные изменения кода. Что вы получаете: корпоративную безопасность, приватную сеть, Entra RBAC, полную трассировку и оценку — поверх вашей существующей логики агента.

Архитектура намеренно открыта. Вы не привязаны к одному провайдеру моделей или одному фреймворку оркестрации. Используйте DeepSeek для планирования, OpenAI для генерации, LangGraph для оркестрации — рантайм обеспечивает слой согласованности.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

with (
 DefaultAzureCredential() as credential,
 AIProjectClient(endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=credential) as project_client,
 project_client.get_openai_client() as openai_client,
):
 agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
 )

 conversation = openai_client.conversations.create()
 response = openai_client.responses.create(
 conversation=conversation.id,
 input="What are best practices for building AI agents?",
 extra_body={
 "agent_reference": {"name": agent.name, "type": "agent_reference"}
 },
 )
 print(response.output_text)

Если вы переходите с пакета azure-ai-agents, агенты теперь являются операциями первого класса на AIProjectClient в azure-ai-projects. Удалите отдельную зависимость и используйте get_openai_client() для работы с ответами.

Приватная сеть: корпоративный блокер устранён

Это функция, которая разблокирует корпоративное внедрение. Foundry теперь поддерживает полную сквозную приватную сеть с BYO VNet:

Нет публичного исходящего трафика — трафик агента никогда не проходит через публичный интернет
Внедрение контейнеров/подсетей в вашу сеть для локальной коммуникации
Подключение инструментов включено — MCP-серверы, Azure AI Search, агенты данных Fabric — всё работает через приватные пути

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

Аутентификация MCP сделана правильно

Подключения к MCP-серверам теперь поддерживают полный спектр паттернов аутентификации:

Метод аутентификации	Когда использовать
На основе ключей	Простой общий доступ для внутренних инструментов организации
Entra Agent Identity	Сервис-к-сервису; агент аутентифицируется от своего имени
Entra Managed Identity	Изоляция на уровне проекта; без управления учётными данными
OAuth Identity Passthrough	Делегированный доступ пользователя; агент действует от имени пользователей

OAuth Identity Passthrough — самый интересный. Когда пользователям нужно предоставить агенту доступ к своим личным данным — их OneDrive, их организации Salesforce, SaaS API с пользовательской областью — агент действует от их имени через стандартные OAuth-потоки. Никакой общей системной идентификации, притворяющейся всеми.

Voice Live: речь-в-речь без сантехнических работ

Добавление голоса к агенту раньше означало объединение STT, LLM и TTS — три сервиса, три задержки, три поверхности биллинга, всё синхронизировано вручную. Voice Live сворачивает это в единый управляемый API с:

Семантическое определение голосовой активности и конца реплики (понимает смысл, а не просто тишину)
Серверное подавление шума и эхо-компенсация
Поддержка прерывания (пользователи могут прервать ответ)

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

Оценки: от галочки к непрерывному мониторингу

Здесь Foundry серьёзно подходит к качеству продакшена. Система оценки теперь имеет три уровня:

Готовые оценщики — связность, релевантность, обоснованность, качество поиска, безопасность. Подключите к датасету или живому трафику и получите оценки обратно.
Пользовательские оценщики — закодируйте свою бизнес-логику, стандарты тона и специфичные для домена правила соответствия.
Непрерывная оценка — Foundry сэмплирует живой продакшен-трафик, запускает набор оценщиков и отображает результаты через дашборды. Настройте алерты Azure Monitor на случай падения обоснованности или нарушения порогов безопасности.

Всё публикуется в Azure Monitor Application Insights. Качество агента, здоровье инфраструктуры, затраты и телеметрия приложения — всё в одном месте.

eval_object = openai_client.evals.create(
 name="Agent Quality Evaluation",
 data_source_config=DataSourceConfigCustom(
 type="custom",
 item_schema={
 "type": "object",
 "properties": {"query": {"type": "string"}},
 "required": ["query"],
 },
 include_sample_schema=True,
 ),
 testing_criteria=[
 {
 "type": "azure_ai_evaluator",
 "name": "fluency",
 "evaluator_name": "builtin.fluency",
 "initialization_parameters": {
 "deployment_name": os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"]
 },
 "data_mapping": {
 "query": "{{item.query}}",
 "response": "{{sample.output_text}}",
 },
 },
 ],
)

Шесть новых регионов для размещённых агентов

Размещённые агенты теперь доступны в East US, North Central US, Sweden Central, Southeast Asia, Japan East и других регионах. Это важно для требований к размещению данных и для снижения задержки, когда ваш агент работает рядом с источниками данных.

Почему это важно для .NET-разработчиков

Хотя примеры кода в анонсе GA написаны на Python, базовая инфраструктура не зависит от языка — и .NET SDK для azure-ai-projects следует тем же паттернам. Responses API, фреймворк оценки, приватная сеть, аутентификация MCP — всё это доступно из .NET.

Если вы ждали, пока ИИ-агенты перейдут от «классной демо» к «я реально могу отправить это на работе», этот GA-релиз — тот самый сигнал. Приватная сеть, правильная аутентификация, непрерывная оценка и продакшен-мониторинг — это были недостающие элементы.

Итог

Foundry Agent Service доступен сейчас. Установите SDK, откройте портал и начинайте строить. Руководство по быстрому старту проведёт вас от нуля до работающего агента за минуты.

Для полного технического погружения со всеми примерами кода ознакомьтесь с анонсом GA.

VS Code 1.112: что действительно важно для .NET-разработчиков

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

VS Code 1.112 только что приземлился, и честно? Этот релиз ощущается иначе, если вы проводите дни в мире .NET. В официальных заметках о релизе много всего, но позвольте мне сэкономить вам время и сосредоточиться на том, что действительно важно для нас.

Copilot CLI стал намного полезнее

Главная тема этого релиза — автономность агентов — предоставление Copilot больше пространства для работы без того, чтобы вы контролировали каждый шаг.

Управление сообщениями и очередь

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

Это огромное улучшение для длинных задач генерации dotnet, когда вы наблюдаете, как Copilot настраивает проект и думаете «ой, мне ещё нужен MassTransit туда».

Уровни разрешений

Вот что меня больше всего радует. Сессии Copilot CLI теперь поддерживают три уровня разрешений:

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

Если вы делаете что-то вроде создания нового ASP.NET Core API с Entity Framework, миграциями и Docker-настройкой — режим Автопилот означает, что вы описываете, что хотите, и идёте за кофе. Он разберётся.

Включить Автопилот можно через настройку chat.autopilot.enabled.

Предварительный просмотр изменений перед делегированием

Когда вы делегируете задачу Copilot CLI, он создаёт worktree. Раньше, если у вас были незакоммиченные изменения, приходилось проверять Source Control, чтобы увидеть, что будет затронуто. Теперь представление Chat показывает ожидающие изменения прямо перед тем, как вы решите, копировать, переместить или проигнорировать их.

Мелочь, но это спасает от того момента «подождите, что у меня было в staged?».

Отладка веб-приложений без выхода из VS Code

Встроенный браузер теперь поддерживает полную отладку. Вы можете ставить точки останова, пошагово проходить код и проверять переменные — всё внутри VS Code. Больше не нужно переключаться на Edge DevTools.

Появился новый тип отладки editor-browser, и если у вас уже есть конфигурации запуска для msedge или chrome, миграция так же проста, как изменение поля type в вашем launch.json:

{
 "type": "editor-browser",
 "request": "launch",
 "name": "Debug Blazor App",
 "url": "https://localhost:5001"
}

Для Blazor-разработчиков это переломный момент. Вы уже запускаете dotnet watch в терминале — теперь и отладка остаётся в том же окне.

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

Песочница для MCP-серверов

Это важнее, чем может показаться. Если вы используете MCP-серверы — может быть, настроили пользовательский для ваших Azure-ресурсов или запросов к базе данных — они работали с теми же правами, что и ваш процесс VS Code. То есть полный доступ к файловой системе, сети, всему.

Теперь их можно изолировать в песочнице. В вашем mcp.json:

{
 "servers": {
 "my-azure-tools": {
 "command": "node",
 "args": ["./mcp-server.js"],
 "sandboxEnabled": true
 }
 }
}

Когда изолированному серверу нужен доступ к чему-то, чего у него нет, VS Code запрашивает разрешение. Гораздо лучше подхода «надеемся, никто не сделает ничего странного».

Примечание: Песочница доступна на macOS и Linux на данный момент. Поддержка Windows на подходе — но удалённые сценарии вроде WSL уже работают.

Обнаружение кастомизаций в монорепозиториях

Если вы работаете в монорепозитории (и будем честны, многие корпоративные .NET-решения в итоге становятся таковыми), это решает реальную проблему.

Раньше, если вы открывали подпапку вашего репозитория, VS Code не находил ваш copilot-instructions.md, AGENTS.md или пользовательские скиллы, находящиеся в корне репозитория. Теперь с настройкой chat.useCustomizationsInParentRepositories он поднимается до корня .git и обнаруживает всё.

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

/troubleshoot для отладки агентов

Когда-нибудь настраивали пользовательские инструкции или скиллы и гадали, почему они не подхватываются? Новый скилл /troubleshoot читает отладочные логи агента и сообщает, что произошло — какие инструменты были использованы или пропущены, почему инструкции не загрузились и что вызывает медленные ответы.

Включите его с помощью:

{
 "github.copilot.chat.agentDebugLog.enabled": true,
 "github.copilot.chat.agentDebugLog.fileLogging.enabled": true
}

Затем просто введите /troubleshoot почему мой пользовательский скилл не загружается? в чат.

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

Поддержка изображений и бинарных файлов

Агенты теперь могут читать файлы изображений с диска и бинарные файлы нативно. Бинарные файлы представлены в формате hexdump, а выводы изображений (например, скриншоты из встроенного браузера) отображаются в карусельном виде.

Для .NET-разработчиков подумайте: вставьте скриншот UI-бага в чат, и агент поймёт, что не так, или пусть он проанализирует вывод рендеринга компонента Blazor.

Автоматические ссылки на символы

Небольшое улучшение качества жизни: когда вы копируете имя символа (класс, метод и т.д.) и вставляете его в чат, VS Code теперь автоматически преобразует его в ссылку #sym:Name. Это даёт агенту полный контекст об этом символе без необходимости вручную добавлять его.

Если вам нужен обычный текст, используйте Ctrl+Shift+V.

Плагины теперь можно включать/отключать

Раньше отключение MCP-сервера или плагина означало его удаление. Теперь их можно переключать — как глобально, так и для каждого рабочего пространства. Правый клик в представлении Extensions или Customizations — и готово.

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

Итог

VS Code 1.112 явно усиленно развивает агентный опыт — больше автономности, лучшая отладка, более строгая безопасность. Для .NET-разработчиков встроенная отладка браузера и улучшения Copilot CLI — это главные новшества.

Если вы ещё не пробовали запустить полную сессию Copilot CLI в режиме Автопилот для .NET-проекта, этот релиз — хорошее время для начала. Просто не забудьте настроить разрешения и дайте ему поработать.

Скачайте VS Code 1.112 или обновите изнутри VS Code через Help > Check for Updates.

Фоновые ответы в Microsoft Agent Framework: больше никакой тревоги из-за таймаутов

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

Если вы создавали что-либо с моделями рассуждения, такими как o3 или GPT-5.2, вы знаете эту боль. Ваш агент начинает обдумывать сложную задачу, клиент сидит и ждёт, и где-то между «всё нормально» и «он завис?» ваше соединение падает по таймауту. Вся работа? Потеряна.

Microsoft Agent Framework только что выпустил фоновые ответы — и честно говоря, это одна из тех функций, которая должна была существовать с первого дня.

Проблема с блокирующими вызовами

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

HTTP-соединения могут упасть по таймауту
Сетевые сбои убивают всю операцию
Ваш пользователь смотрит на спиннер, гадая, происходит ли что-нибудь

Фоновые ответы переворачивают этот подход.

Как работают continuation-токены

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

Процесс прост:

Отправьте запрос с AllowBackgroundResponses = true
Если агент поддерживает фоновую обработку, вы получаете continuation-токен
Опрашивайте по своему расписанию, пока токен не вернёт null — это значит, результат готов

Вот версия на .NET:

AIAgent agent = new AzureOpenAIClient(
 new Uri("https://<myresource>.openai.azure.com"),
 new DefaultAzureCredential())
 .GetResponsesClient("<deployment-name>")
 .AsAIAgent();

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();

AgentResponse response = await agent.RunAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options);

// Опрашиваем до завершения
while (response.ContinuationToken is not null)
{
 await Task.Delay(TimeSpan.FromSeconds(2));
 options.ContinuationToken = response.ContinuationToken;
 response = await agent.RunAsync(session, options);
}

Console.WriteLine(response.Text);

Если агент завершает немедленно (простые задачи, модели, не требующие фоновой обработки), continuation-токен не возвращается. Ваш код просто работает — никакой специальной обработки не нужно.

Стриминг с возобновлением: настоящая магия

Опрос подходит для сценариев «запустил и забыл», но что если вы хотите видеть прогресс в реальном времени? Фоновые ответы также поддерживают стриминг со встроенным возобновлением.

Каждое потоковое обновление несёт свой continuation-токен. Если соединение прерывается посреди потока, вы продолжаете ровно с того места, где остановились:

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();
AgentResponseUpdate? latestUpdate = null;

await foreach (var update in agent.RunStreamingAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options))
{
 Console.Write(update.Text);
 latestUpdate = update;
 break; // Симулируем разрыв сети
}

// Возобновляем ровно с того места, где остановились
options.ContinuationToken = latestUpdate?.ContinuationToken;
await foreach (var update in agent.RunStreamingAsync(session, options))
{
 Console.Write(update.Text);
}

Агент продолжает обработку на стороне сервера независимо от того, что происходит с вашим клиентом. Это встроенная отказоустойчивость без написания логики повторных попыток или circuit breaker’ов.

Когда это действительно использовать

Не каждый вызов агента нуждается в фоновых ответах. Для быстрых завершений вы добавляете сложность без причины. Но вот где они реально полезны:

Сложные задачи рассуждения — многоэтапный анализ, глубокие исследования, всё, что заставляет модель рассуждения действительно думать
Генерация длинного контента — детальные отчёты, многочастные документы, обширный анализ
Ненадёжные сети — мобильные клиенты, периферийные развёртывания, нестабильные корпоративные VPN
Асинхронные UX-паттерны — отправьте задачу, займитесь другим делом, вернитесь за результатами

Для .NET-разработчиков, создающих корпоративные приложения, последний пункт особенно интересен. Представьте Blazor-приложение, где пользователь запрашивает сложный отчёт — вы запускаете задачу агента, показываете индикатор прогресса и позволяете ему продолжить работу. Никакой WebSocket-гимнастики, никакой пользовательской инфраструктуры очередей, просто токен и цикл опроса.

Итог

Фоновые ответы уже доступны в .NET и Python через Microsoft Agent Framework. Если вы создаёте агентов, которые делают что-то сложнее простых вопросов-ответов, это стоит добавить в свой инструментарий. Паттерн с continuation-токенами сохраняет простоту, решая очень реальную продакшен-проблему.

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

Dotnet | The .NET Blog

SDD Conference 2026

Темы

Спикеры

Билеты и информация

Windows App Dev CLI v0.3: F5 из терминала и UI-автоматизация для агентов

winapp run: F5 из любого места

Новый NuGet-пакет: dotnet run для упакованных приложений

winapp ui: UI-автоматизация из командной строки

Другие нововведения

Как получить

Хуки azd на Python, TypeScript и .NET: прощай, shell-скрипты

Что такое хуки

Как работает определение языка

Важные детали по языкам

Python

JavaScript и TypeScript

.NET

Конфигурация по исполнителю

Почему это важно для .NET-разработчиков

Итог

Хватит нянчить терминал: отсоединённый режим Aspire меняет рабочий процесс

Отсоединённый режим: одна команда — терминал свободен

Управление запущенными процессами

Сочетание с изолированным режимом

Почему это важно для агентов кода

Подводя итог

Кластеризация пинов наконец появилась в .NET MAUI Maps — Одно свойство, ноль проблем

Одно свойство, чтобы править всеми

Независимые группы кластеризации

Обработка нажатий на кластер

Детали платформ, которые стоит знать

Почему это важно

Начинаем

.NET Апрель 2026 Servicing — Патчи безопасности, которые стоит применить сегодня

Что исправлено

Обновлённые версии

Что делать

Azure MCP Server 2.0 выпущен — Self-Hosted Agentic Cloud Automation здесь

Что такое Azure MCP Server?

Главное: self-hosted удалённые развёртывания

Усиление безопасности

Где вы можете его использовать?

Почему это важно для .NET разработчиков

Начало работы

В итоге

.NET Aspire 13.2 хочет стать лучшим другом вашего ИИ-агента

Проблема реальна

Aspire как инфраструктура для агентов

Аналогия с бамперами на боулинге

Начало работы

Подведём итоги

MCP Apps получили Fluent API — Создавайте богатые UI для AI-инструментов на .NET за три шага

Что такое MCP Apps?

Fluent API за три шага

API спроектирован отлично

Начало работы

Подводя итоги

Изолированный режим Aspire устраняет кошмар конфликтов портов при параллельной разработке

Решение: --isolated

Реальные сценарии, где это сияет

Как это работает под капотом

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

Подведём итоги

Оценка модернизации GitHub Copilot — лучший инструмент миграции, который вы ещё не используете

Это не просто движок предложений кода

Два способа начать

Разбивка проблем действенна

Охваченные пути обновления

Моё мнение

Подводя итоги

Подключите ваши MCP-серверы на Azure Functions к агентам Foundry — Вот как

Почему эта комбинация имеет смысл

Варианты аутентификации

Настройка

Моё мнение

Подводя итоги

C# 15 получает типы-объединения — и это именно то, что мы просили

Проблема, которую решают объединения

Синтаксис красиво прост

Решение: `--isolated`