Developer Tools | The .NET Blog

VS Code 1.119: OpenTelemetry для сеансов агентов, интеграция браузера и безопасность

Emiliano Montesdeoca — Fri, 15 May 2026 00:00:00 +0000

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

VS Code 1.119 вышел 6 мая 2026 года (с патчем безопасности 1.119.1 вскоре после). Релиз сфокусирован на наблюдаемости агентов, взаимодействии с браузером и сокращении прерываний.

Трассировка OpenTelemetry для сеансов агентов

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

"github.copilot.chat.otel.enabled": true,
"github.copilot.chat.otel.otlpEndpoint": "http://localhost:4318"

Трассы следуют семантическим соглашениям GenAI. Каждый запрос агента создаёт корневой спан invoke_agent с вложенными дочерними спанами: chat, execute_tool и execute_hook. Использование токенов сообщается по каждому запросу — включая счётчики чтения кэша и его создания.

Работает с локальным агентом, фоновым агентом Copilot CLI и агентом Claude. Любой бэкенд, совместимый с OTLP, принимает трассы — автономная панель управления Aspire хорошо подходит для локальной разработки.

Агенты теперь могут обращаться к вкладкам браузера

Агенты могут запрашивать доступ к вкладкам встроенного браузера — но не автоматически. Вы должны явно открыть общий доступ к вкладке через средство выбора контекста, перетаскивание или предложенный контекст. В браузере есть кнопка совместного использования для отзыва доступа. Когда агент пытается открыть новую вкладку на том же домене, что и уже открытая (не общая) вкладка, VS Code предлагает повторно использовать существующую.

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

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

Доверие и безопасность

Меньше прерываний: VS Code 1.119 сокращает запросы на сетевой доступ и записи во временные папки от агентов. Патч 1.119.1 устраняет конкретные проблемы безопасности — стоит обновиться, если вы ещё не сделали этого.

Быстрое переключение на предварительный просмотр Markdown

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

VS Code Agents (предварительный просмотр Insiders)

Переработанный интерфейс сеансов агентов — новый выбор репозитория (локальный/репозитории/удалённый), улучшения подсеансов, улучшения для веб и мобильных устройств, анимации прогресса — доступен в Insiders на insiders.vscode.dev/agents.

Полный список изменений: code.visualstudio.com/updates/v1_119.

Azure Data Studio прекратил работу: перенесите рабочий процесс Azure SQL в VS Code

Emiliano Montesdeoca — Sat, 09 May 2026 00:00:00 +0000

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

Azure Data Studio прекратил работу 6 февраля 2025 года, поддержка завершается 28 февраля 2026 года — рекомендуемая замена: VS Code с расширением MSSQL.

Что установить

Три вещи для начала:

Расширение MSSQL — найдите «SQL Server (mssql)» в Marketplace VS Code
Расширение SQL Database Projects — схема как код, валидация сборки, управляемая публикация
.NET 8 SDK — требуется системой сборки; отсутствующий SDK — самая частая проблема при первом запуске

Миграция подключений и настроек ADS

Расширение MSSQL включает ADS Migration Toolkit, который выполняет одноразовую миграцию в управляемом потоке: сохранённые подключения, группы подключений, настройки и сочетания клавиш импортируются автоматически.

Восстановление мышечной памяти F5

Пользователи ADS привыкли запускать запросы клавишей F5. Установите расширение MSSQL Database Management Keymap, чтобы вернуть сочетания клавиш в стиле ADS, включая F5.

SQL Database Projects: схема как код

Правая кнопка мыши на проекте → Опубликовать → настроить цель → просмотреть сгенерированный T-SQL-скрипт → развернуть. Предварительный просмотр скрипта перед развёртыванием — ключевая функция безопасности. Шаблоны элементов генерируют заготовки для таблиц, хранимых процедур и представлений — тот же рабочий процесс, что и в SSDT.

Частая проблема: несоответствие целевой платформы в файле .sqlproj вызовет ошибки сборки, если проект был создан для другой версии SQL Server.

Schema Compare и Schema Designer

Расширение также включает Schema Compare (сравнение проекта с развёрнутой базой данных) и Schema Designer (визуальное редактирование схемы без написания DDL вручную).

Разработчики Microsoft Fabric

Настройка идентична, но начните с портала Fabric и сначала подключите базу данных к Git, прежде чем открывать её в VS Code. У Microsoft есть специальное руководство: Azure Data Studio to VS Code — What it means for SQL database in Fabric developers.

Итог

Миграция — это одноразовый управляемый процесс, а не ручная пересборка. Установите три инструмента, запустите ADS Migration Toolkit, восстановите сочетания клавиш — и вернётесь к обычной работе менее чем за 10 минут.

Смотрите полную статью с пошаговыми скриншотами и инструкцией для Fabric.

Azure MCP Server Теперь .mcpb — Установка без Какого-либо Runtime

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

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

Знаете, что раздражало в настройке MCP-серверов? Нужен был runtime. Node.js для npm-версии, Python для pip/uvx, .NET SDK для dotnet-варианта.

Azure MCP Server только что изменил это. Теперь он доступен как .mcpb — MCP Bundle — и настройка выполняется перетаскиванием.

Что такое MCP Bundle?

Думайте о нём как о расширении VS Code (.vsix) или расширении браузера (.crx), но для MCP-серверов. Файл .mcpb — это автономный ZIP-архив с бинарным файлом сервера и всеми его зависимостями.

Как установить

1. Скачайте bundle для вашей платформы

Перейдите на страницу GitHub Releases и скачайте файл .mcpb для вашей ОС и архитектуры.

2. Установите в Claude Desktop

Самый простой способ: перетащите файл .mcpb в окно Claude Desktop на странице настроек расширений (☰ → Файл → Настройки → Расширения). Проверьте детали сервера, нажмите «Установить», подтвердите.

3. Аутентифицируйтесь в Azure

az login

Всё. Azure MCP Server использует ваши существующие учётные данные Azure.

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

Доступ к 100+ инструментам сервисов Azure прямо из вашего ИИ-клиента:

Запрашивать и управлять Cosmos DB, Storage, Key Vault, App Service, Foundry
Генерировать команды az CLI для любых задач
Создавать шаблоны Bicep и Terraform

С чего начать

Загрузка: GitHub Releases
Репозиторий: aka.ms/azmcp
Документация: aka.ms/azmcp/docs

Смотрите полный пост.

VS Code 1.118: Copilot CLI получает имена сессий, значки модели и TypeScript 7.0 Nightly

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

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

Visual Studio Code 1.118 — небольшой сфокусированный релиз, в основном с улучшениями Copilot CLI.

Copilot CLI: сессии получают настоящие имена

API заголовков сессий SDK Copilot CLI теперь используются как источник истины для имён сессий. Вместо автоматически сгенерированных меток сессии показывают реальное имя из SDK.

Быстрое переключение между сессиями

В приложение Agents теперь добавлены Ctrl+1, Ctrl+2 и т.д. для быстрого переключения между сессиями.

Значки модели в чате

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

Автоматический выбор модели в Copilot CLI

Функция автоматического выбора модели теперь работает и в агенте Copilot CLI.

Подключение TypeScript 7.0 Nightly

Теперь можно включить тестирование ночных сборок TypeScript 7.0 прямо из настроек VS Code. TypeScript 7.0 — значительный релиз (бета вышла несколько дней назад).

Смотрите полные примечания к релизу.

Foundry Toolboxes: Единый эндпоинт для всех инструментов агентов

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

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

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

Microsoft Foundry только что выпустила Toolboxes в Public Preview — прямой ответ на эту проблему.

Что такое Toolbox?

Toolbox — это именованный, многократно используемый набор инструментов, который определяется один раз в Foundry и предоставляется через единый MCP-совместимый эндпоинт. Любая среда выполнения агента, говорящая на MCP, может его потреблять — никакой привязки к Foundry Agents.

Обещание простое: build once, consume anywhere. Определить инструменты, настроить аутентификацию централизованно (OAuth passthrough, управляемые удостоверения Entra), опубликовать эндпоинт. Каждый агент, которому нужны эти инструменты, подключается к эндпоинту и получает их все.

Четыре столпа (два доступны сегодня)

Столп	Статус	Что делает
Discover	Скоро	Находить одобренные инструменты без ручного поиска
Build	Доступен	Собирать инструменты в многократно используемый bundle
Consume	Доступен	Единый MCP-эндпоинт предоставляет все инструменты
Govern	Скоро	Централизованная аутентификация + observability для всех вызовов

Практический пример

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
import os

client = AIProjectClient(
 endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

toolbox_version = client.beta.toolboxes.create_toolbox_version(
 toolbox_name="customer-feedback-triaging-toolbox",
 description="Поиск по документации и ответы на GitHub-issues.",
 tools=[
 {"type": "web_search", "description": "Поиск в публичной документации"},
 {"type": "azure_ai_search", "index_name": "internal-docs"},
 {"type": "mcp_server", "server_url": "https://your-github-mcp-server.com"}
 ]
)

После публикации Foundry предоставляет единый эндпоинт. Одно подключение — все инструменты.

Нет привязки к Foundry Agents

Toolboxes создаются и управляются в Foundry, но поверхность потребления — открытый протокол MCP. Их можно использовать из кастомных агентов (Microsoft Agent Framework, LangGraph), GitHub Copilot и других MCP-совместимых IDE.

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

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

Итог

Пока рано — Public Preview, сначала Python SDK, Discover и Govern ещё впереди. Но модель надёжная, а MCP-нативный дизайн означает, что она работает с инструментами, которые уже строятся. Подробности в официальном анонсе.

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. Поддержка нескольких языков для хуков доступна прямо сейчас — подробная документация в официальном посте.

VS Code 1.117: Агенты получают собственные ветки Git, и я полностью за

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

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

Грань между «ИИ-ассистентом» и «ИИ-тиммейтом» продолжает стираться. VS Code 1.117 только что вышел, и полные заметки о релизе насыщены, но суть ясна: агенты становятся полноценными участниками вашего рабочего процесса разработки.

Вот что действительно важно.

Режим Autopilot наконец запоминает ваши настройки

Раньше приходилось заново включать Autopilot каждый раз при запуске новой сессии. Раздражало. Теперь режим разрешений сохраняется между сессиями, и вы можете настроить значение по умолчанию.

Agent Host поддерживает три конфигурации сессии:

Default — инструменты запрашивают подтверждение перед запуском
Bypass — автоматически одобряет всё
Autopilot — полностью автономный, сам отвечает на свои вопросы и продолжает работу

Если вы создаёте новый .NET-проект с миграциями, Docker и CI — установите Autopilot один раз и забудьте. Эта настройка сохранится.

Worktree и git-изоляция для сессий агентов

Это главное. Сессии агентов теперь поддерживают полную изоляцию worktree и git. Это значит, что когда агент работает над задачей, он получает собственную ветку и рабочую директорию. Ваша основная ветка остаётся нетронутой.

Ещё лучше — Copilot CLI генерирует осмысленные имена веток для этих worktree-сессий. Никаких больше agent-session-abc123. Вы получаете название, которое действительно описывает, чем занимается агент.

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

Субагенты и команды агентов

Agent Host Protocol теперь поддерживает субагентов. Агент может запускать других агентов для обработки частей задачи. Считайте это делегированием — ваш главный агент координирует, а специализированные агенты занимаются отдельными частями.

Это пока на ранней стадии, но потенциал для .NET-рабочих процессов очевиден. Представьте: один агент обрабатывает ваши миграции EF Core, пока другой настраивает интеграционные тесты. Мы ещё не совсем там, но поддержка протокола появляется сейчас — значит, инструменты подтянутся быстро.

Вывод терминала автоматически включается, когда агенты отправляют ввод

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

Если вы когда-нибудь наблюдали, как агент запускает dotnet build, терпит неудачу, а потом делает ещё один round-trip, чтобы увидеть ошибку — это трение исчезло. Он видит вывод мгновенно и реагирует.

Приложение Agents на macOS обновляется автоматически

Автономное приложение Agents на macOS теперь обновляется самостоятельно. Больше не нужно вручную скачивать новые версии. Оно просто остаётся актуальным.

Мелочи, которые стоит знать

Подсказки package.json теперь показывают и установленную версию, и последнюю доступную. Полезно, если вы управляете npm-инструментами наряду с .NET-проектами.
Изображения в комментариях JSDoc корректно отображаются в подсказках и автодополнении.
Сессии Copilot CLI теперь показывают, были ли они созданы в VS Code или извне — удобно, когда переключаетесь между терминалами.
Copilot CLI, Claude Code и Gemini CLI распознаются как типы оболочек. Редактор знает, что вы запускаете.

Итог

VS Code 1.117 — это не броский набор фич. Это инфраструктура. Изоляция worktree, постоянные разрешения, протоколы субагентов — это строительные блоки для рабочего процесса, в котором агенты выполняют реальные параллельные задачи, не затрагивая ваш код.

Если вы разрабатываете на .NET и ещё не погрузились в агентный рабочий процесс, честно говоря, сейчас самое время начать.

Docker Sandbox позволяет агентам Copilot рефакторить ваш код без риска для машины

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

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

Если вы использовали агентный режим Copilot для чего-то большего, чем мелкие правки, вы знаете эту боль. Каждая запись файла, каждая команда в терминале — ещё один запрос на разрешение. А теперь представьте это на 50 проектах. Совсем не весело.

Команда Azure опубликовала пост о Docker Sandbox для агентов GitHub Copilot, и, честно говоря, это одно из самых практичных улучшений в агентном инструментарии, которое я видел. Система использует микро-ВМ, чтобы дать Copilot полностью изолированную среду, где он может делать всё что угодно — устанавливать пакеты, запускать сборки, выполнять тесты — не затрагивая вашу хост-систему.

Что Docker Sandbox реально даёт

Основная идея проста: запустить легковесную микро-ВМ с полноценным окружением Linux, синхронизировать в неё ваше рабочее пространство и позволить агенту Copilot свободно работать внутри. Когда он закончит, изменения синхронизируются обратно.

Вот что делает это чем-то большим, чем просто «запустить что-то в контейнере»:

Двусторонняя синхронизация рабочего пространства с сохранением абсолютных путей. Структура вашего проекта выглядит идентично внутри песочницы. Никаких ошибок сборки из-за путей.
Приватный Docker-демон работает внутри микро-ВМ. Агент может собирать и запускать контейнеры, не монтируя Docker-сокет вашего хоста. Это серьёзное преимущество для безопасности.
HTTP/HTTPS-фильтрующие прокси контролируют, к чему агент может обращаться в сети. Вы решаете, какие реестры и эндпоинты разрешены. Атаки на цепочку поставок через вредоносный npm install внутри песочницы? Заблокированы.
Режим YOLO — да, именно так они его называют. Агент работает без запросов на разрешения, потому что буквально не может повредить ваш хост. Каждое деструктивное действие изолировано.

Почему разработчикам .NET стоит обратить внимание

Подумайте о работе по модернизации, с которой сейчас сталкивается так много команд. У вас есть решение на .NET Framework с 30 проектами, и его нужно перенести на .NET 9. Это сотни изменений в файлах — файлы проектов, обновления пространств имён, замена API, миграция NuGet.

С Docker Sandbox вы можете направить агента Copilot на проект, позволить ему свободно рефакторить внутри микро-ВМ, запустить dotnet build и dotnet test для валидации и принять только те изменения, которые реально работают. Никакого риска, что он случайно разрушит вашу локальную среду разработки во время экспериментов.

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

Вопрос безопасности имеет значение

Вот что большинство людей упускает: когда вы позволяете ИИ-агенту выполнять произвольные команды, вы доверяете ему всю вашу машину. Docker Sandbox переворачивает эту модель. Агент получает полную автономию внутри одноразовой среды. Сетевой прокси гарантирует, что он может загружать только из одобренных источников. Ваша хостовая файловая система, Docker-демон и учётные данные остаются нетронутыми.

Для команд с требованиями комплаенса — а это большинство корпоративных .NET-компаний — это разница между «мы не можем использовать агентный ИИ» и «мы можем внедрить его безопасно».

Итог

Docker Sandbox решает фундаментальное противоречие агентного программирования: агентам нужна свобода, чтобы быть полезными, но свобода на вашей хост-машине опасна. Микро-ВМ дают вам и то, и другое. Если вы планируете масштабный рефакторинг или модернизацию .NET, стоит настроить это прямо сейчас. Сочетание интеллекта Copilot в работе с кодом и безопасной среды выполнения — это именно то, чего ждали продакшн-команды.

Хватит нянчить терминал: отсоединённый режим 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.

Инструменты Azure MCP теперь встроены в Visual Studio 2022 — Расширение не требуется

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

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

Если вы использовали инструменты Azure MCP в Visual Studio через отдельное расширение, вы знаете этот ритуал — установить VSIX, перезапустить, надеяться, что ничего не сломается, разбираться с несовместимостью версий. Это трение осталось в прошлом.

Yun Jung Choi объявила, что инструменты Azure MCP теперь поставляются непосредственно в составе рабочей нагрузки разработки Azure в Visual Studio 2022. Без расширения. Без VSIX. Без танцев с перезапуском.

Что это означает на практике

Начиная с Visual Studio 2022 версии 17.14.30, Azure MCP Server включён в рабочую нагрузку разработки Azure. Если эта рабочая нагрузка уже установлена, достаточно включить его в GitHub Copilot Chat — и всё готово.

Более 230 инструментов для 45 сервисов Azure — доступны прямо из окна чата. Просмотр учётных записей хранилища, развёртывание приложения ASP.NET Core, диагностика проблем App Service, запросы к Log Analytics — всё это без открытия вкладки браузера.

Почему это важнее, чем кажется

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

Единый путь обновления через Visual Studio Installer
Никакого расхождения версий между расширением и IDE
Всегда актуально — MCP Server обновляется с регулярными релизами VS

Для команд, стандартизирующих на Azure, это очень важно. Устанавливаете рабочую нагрузку один раз, включаете инструменты, и они доступны в каждой сессии.

Что можно делать с помощью этих инструментов

Инструменты охватывают полный жизненный цикл разработки через Copilot Chat:

Изучать — спрашивайте о сервисах Azure, лучших практиках, архитектурных паттернах
Проектировать и разрабатывать — получайте рекомендации по сервисам, настраивайте код приложения
Развёртывать — выделяйте ресурсы и развёртывайте прямо из IDE
Устранять неполадки — запрашивайте логи, проверяйте состояние ресурсов, диагностируйте проблемы в продакшене

Быстрый пример — введите это в Copilot Chat:

List my storage accounts in my current subscription.

Copilot вызывает инструменты Azure MCP за кулисами, запрашивает ваши подписки и возвращает отформатированный список с именами, расположениями и SKU. Портал не нужен.

Как включить

Обновите Visual Studio 2022 до версии 17.14.30 или выше
Убедитесь, что установлена рабочая нагрузка Azure development
Откройте GitHub Copilot Chat
Нажмите кнопку Select tools (значок с двумя гаечными ключами)
Включите Azure MCP Server

Вот и всё. Настройка сохраняется между сессиями.

Одно замечание

Инструменты отключены по умолчанию — нужно включить их вручную. И инструменты, специфичные для VS 2026, недоступны в VS 2022. Доступность инструментов также зависит от разрешений вашей подписки Azure, как и в портале.

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

Это часть чёткого тренда: MCP становится стандартным способом предоставления облачных инструментов в IDE для разработчиков. Мы уже видели стабильный релиз Azure MCP Server 2.0 и интеграции MCP в VS Code и других редакторах. Встраивание в систему рабочих нагрузок Visual Studio — естественное развитие.

Для нас, .NET-разработчиков, которые живут в Visual Studio, это устраняет ещё одну причину переключаться на портал Azure. И честно говоря, чем меньше переключений между вкладками, тем лучше.

azd update — Одна команда для всех ваших пакетных менеджеров

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

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

Знаете это сообщение «Доступна новая версия azd», которое появляется каждые несколько недель? То самое, которое вы закрываете, потому что не помните, устанавливали ли вы azd через winget, Homebrew или тот curl-скрипт, который запустили полгода назад? Так вот, это наконец-то исправлено.

Microsoft выпустила azd update — единую команду, которая обновляет Azure Developer CLI до последней версии независимо от того, как вы её изначально установили. Windows, macOS, Linux — неважно. Одна команда.

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

azd update

Вот и всё. Если хотите ранний доступ к новым возможностям, можно переключиться на ежедневную Insiders-сборку:

azd update --channel daily
azd update --channel stable

Команда определяет текущий метод установки и использует подходящий механизм обновления под капотом. Больше никаких «подожди, я на этой машине winget или choco использовал?»

Небольшой нюанс

azd update доступна начиная с версии 1.23.x. Если у вас более старая версия, придётся выполнить последнее ручное обновление через исходный метод установки. После этого azd update берёт всё на себя.

Проверьте текущую версию командой azd version. Если нужна чистая установка, документация по установке вам поможет.

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

Это небольшое улучшение качества жизни, но для тех из нас, кто ежедневно использует azd для деплоя ИИ-агентов и Aspire-приложений в Azure, быть на последней версии означает меньше моментов «этот баг уже был исправлен в последнем релизе». На одну заботу меньше.

Читайте полный анонс и подробный разбор Джона Галланта для дополнительного контекста.

.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 со всеми деталями и демо-видео.

VS Code 1.116 — Приложение Agents Получает Навигацию с Клавиатуры и Автодополнение Контекста Файлов

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

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

VS Code 1.116 — это апрельский релиз 2026 года, и хотя он легче некоторых недавних обновлений, изменения целенаправленны и значимы — особенно если вы ежедневно используете приложение Agents.

Вот что появилось, на основе официальных заметок о релизе.

Улучшения приложения Agents

Приложение Agents продолжает развиваться с доработками юзабилити, которые реально влияют на повседневные рабочие процессы:

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

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

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

Разрешение ссылок CSS `@import`

Приятно для фронтенд-разработчиков: VS Code теперь разрешает CSS @import-ссылки, использующие пути node_modules. Вы можете переходить через Ctrl+клик по импортам вроде @import "some-module/style.css" при использовании бандлеров. Мелочь, но убирает точку трения в CSS-рабочих процессах.

Заключение

VS Code 1.116 — это про совершенствование: сделать приложение Agents более удобным для навигации, более доступным и более дружелюбным к клавиатуре. Если вы проводите значительное время в приложении Agents (а я подозреваю, что многие из нас так и делают), эти изменения накапливаются.

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

Изолированный режим 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.

Та Самая Настройка Плавающих Окон в Visual Studio, О Которой Вы Не Знали (Но Должны)

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

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

Если вы используете несколько мониторов с Visual Studio (а честно говоря, кто сейчас не использует?), вы наверняка сталкивались с раздражающей проблемой: плавающие окна инструментов исчезают при сворачивании основной IDE, они всегда остаются поверх всего остального и не отображаются отдельными кнопками в панели задач. Это работает для некоторых рабочих процессов, но для мультимониторных конфигураций — это расстраивает.

Мадс Кристенсен из команды Visual Studio поделился малоизвестной настройкой, которая полностью меняет поведение плавающих окон. Один выпадающий список. Вот и всё.

Настройка

Tools > Options > Environment > Windows > Floating Windows

Выпадающий список “These floating windows are owned by the main window” имеет три варианта:

None — полная независимость. Каждое плавающее окно получает собственную запись в панели задач и ведёт себя как обычное окно Windows.
Tool Windows (по умолчанию) — документы свободно плавают, окна инструментов привязаны к IDE.
Documents and Tool Windows — классическое поведение Visual Studio, всё привязано к главному окну.

Почему “None” — лучший выбор для мультимониторных настроек

Установите None, и внезапно все ваши плавающие окна инструментов и документов начинают вести себя как настоящие приложения Windows. Они появляются в панели задач, остаются видимыми при сворачивании основного окна Visual Studio и перестают навязчиво выходить на передний план.

Совместите это с PowerToys FancyZones — и это полностью меняет игру. Создайте пользовательские макеты на своих мониторах, расположите Solution Explorer в одной зоне, отладчик в другой, а файлы кода где угодно. Всё остаётся на месте, всё доступно независимо, и ваше рабочее пространство ощущается организованным, а не хаотичным.

Быстрые рекомендации

Продвинутые пользователи с несколькими мониторами: Установите None, используйте в паре с FancyZones
Иногда используете плавающие окна: Tool Windows (по умолчанию) — хороший компромисс
Традиционный рабочий процесс: Documents and Tool Windows сохраняет классическое поведение

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

Заключение

Это одна из тех настроек из серии «не могу поверить, что я этого не знал». Если плавающие окна в Visual Studio когда-либо вас раздражали, идите и измените эту настройку прямо сейчас.

Прочитайте полный пост для подробностей и скриншотов.

VS Code 1.115 — Уведомления фонового терминала, режим SSH-агента и другое

Emiliano Montesdeoca — Mon, 06 Apr 2026 00:00:00 +0000

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

VS Code 1.115 только что вышел, и хотя это более лёгкий релиз в плане основных функций, улучшения, связанные с агентами, действительно полезны, если вы ежедневно работаете с AI-ассистентами для написания кода.

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

Фоновые терминалы общаются с агентами

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

Почему это важно? Если вы использовали режим агента Copilot для запуска команд сборки или тестовых наборов в фоне, вы знаете боль от “оно уже закончилось?” — фоновые терминалы по сути работали по принципу “запустил и забыл”. Теперь агент получает уведомление, когда ваш dotnet build или dotnet test завершается, видит вывод и может соответственно реагировать. Небольшое изменение, которое делает рабочие процессы на основе агентов значительно надёжнее.

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

Удалённый хостинг агентов через SSH

VS Code теперь поддерживает подключение к удалённым машинам по SSH с автоматической установкой CLI и запуском в режиме хоста агентов. Это означает, что ваши сессии AI-агентов могут напрямую работать с удалёнными окружениями — полезно для .NET-разработчиков, которые собирают и тестируют на Linux-серверах или облачных виртуальных машинах.

Отслеживание изменений в сессиях агентов

Изменения файлов, сделанные во время сессий агентов, теперь отслеживаются и восстанавливаются, с поддержкой diff, отмены/повтора и восстановления состояния. Если агент вносит изменения в ваш код и что-то идёт не так, вы можете точно увидеть, что изменилось, и откатить это. Спокойствие при том, что агенты модифицируют вашу кодовую базу.

Распознавание вкладок браузера и другие улучшения

Ещё несколько улучшений качества жизни:

Отслеживание вкладок браузера — чат теперь может отслеживать и ссылаться на вкладки браузера, открытые во время сессии, чтобы агенты могли ссылаться на веб-страницы, которые вы просматриваете
Вставка файлов в терминал — вставляйте файлы (включая изображения) в терминал с помощью Ctrl+V, перетаскивания или правого клика
Покрытие тестами в миникарте — индикаторы покрытия тестами теперь отображаются в миникарте для быстрого визуального обзора
Масштабирование щипком на Mac — встроенный браузер поддерживает жесты масштабирования щипком
Права Copilot в Сессиях — строка состояния показывает информацию об использовании в представлении Сессий
Фавиконы в Перейти к файлу — открытые веб-страницы показывают фавиконы в списке быстрого выбора

Подводя итог

VS Code 1.115 — это инкрементальный релиз, но улучшения агентов — уведомления фонового терминала, хостинг агентов через SSH и отслеживание изменений — в сумме дают заметно более гладкий опыт разработки с помощью ИИ. Если вы используете режим агента Copilot для .NET-проектов, это именно те улучшения качества жизни, которые уменьшают ежедневное трение.

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

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 для всех деталей.

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 — особенно ИИ-агенты — это обновление стоит внимания.

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

Azure DevOps наконец-то исправил Markdown-редактор, на который все жаловались

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

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

Если вы используете Azure Boards, вы наверняка сталкивались с этим: читаете описание рабочего элемента, может проверяете критерии приёмки, и случайно делаете двойной клик. Бум — вы в режиме редактирования. Вы ничего не хотели редактировать. Просто читали.

Dan Hellem объявил об исправлении, и это одно из тех изменений, которые звучат мелко, но реально убирают трение из повседневного рабочего процесса.

Что изменилось

Markdown-редактор для текстовых полей рабочих элементов теперь открывается в режиме просмотра по умолчанию. Можно читать контент и взаимодействовать с ним — переходить по ссылкам, проверять форматирование — не беспокоясь о случайном входе в режим редактирования.

Когда действительно хотите редактировать, нажмите на иконку редактирования вверху поля. Закончили — явно вернитесь в режим просмотра. Просто, намеренно, предсказуемо.

Почему это важнее, чем кажется

Тред обратной связи от сообщества был длинным. Поведение двойного клика для редактирования было введено с Markdown-редактором в июле 2025, и жалобы начались почти сразу.

Для команд, которые делают планирование спринтов, уточнение бэклога или код-ревью в Azure Boards, такое микро-трение накапливается.

Статус развёртывания

Уже раскатывается для части пользователей и расширится на всех в ближайшие две-три недели.

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

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

Bookmark Studio добавляет слотовую навигацию и обмен закладками в Visual Studio

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

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

Закладки в Visual Studio всегда были… нормальными. Ставишь одну, переходишь к следующей, забываешь какая есть какая. Работают, но никогда не были чем-то, что назвали бы мощным.

Mads Kristensen только что выпустил Bookmark Studio — экспериментальное расширение, которое заполняет именно те пробелы, с которыми вы, вероятно, сталкивались.

Слотовая навигация

Закладки можно назначить на слоты 1–9 и перейти к ним напрямую через Alt+Shift+1 по Alt+Shift+9. Новые закладки автоматически получают следующий свободный слот.

Менеджер закладок

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

Организация с метками, цветами и папками

Закладки могут иметь метки, цвета и группироваться в папки. Метаданные сохраняются по solution.

Экспорт и обмен

Bookmark Studio позволяет экспортировать закладки как текст, Markdown или CSV.

Закладки, следующие за кодом

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

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

Bookmark Studio ничего не переизобретает. Берёт функцию, которая годами была «достаточной», и делает её действительно полезной. Скачайте из Visual Studio Marketplace.

Мартовское обновление 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, чтобы всё попробовать.

С ноутбука в продакшен: развёртывание ИИ-агентов в Microsoft Foundry двумя командами

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

Вы знаете тот разрыв между «работает на моей машине» и «развёрнуто и обслуживает трафик»? Для ИИ-агентов этот разрыв был болезненно широким. Нужно подготовить ресурсы, развернуть модели, настроить идентификацию, организовать мониторинг — и это до того, как кто-либо сможет реально вызвать вашего агента.

Azure Developer CLI только что превратил это в дело двух команд.

Новый рабочий процесс `azd ai agent`

Давайте пройдём по тому, как это реально выглядит. У вас есть проект ИИ-агента — допустим, агент-консьерж для отеля. Он работает локально. Вы хотите запустить его на Microsoft Foundry.

azd ai agent init
azd up

Вот и всё. Две команды. azd ai agent init генерирует инфраструктуру как код в вашем репозитории, а azd up разворачивает всё в Azure и публикует вашего агента. Вы получаете прямую ссылку на вашего агента в портале Foundry.

Что происходит под капотом

Команда init генерирует реальные, проверяемые шаблоны Bicep в вашем репозитории:

Foundry Resource (контейнер верхнего уровня)
Foundry Project (где живёт ваш агент)
Конфигурация развёртывания модели (GPT-4o и т.д.)
Managed identity с правильными назначениями ролей RBAC
azure.yaml для карты сервисов
agent.yaml с метаданными агента и переменными окружения

Ключевой момент: всё это принадлежит вам. Это версионированный Bicep в вашем репозитории. Вы можете его проверить, настроить и закоммитить рядом с кодом вашего агента. Никаких магических чёрных ящиков.

Внутренний цикл разработки

Что мне действительно нравится — это история локальной разработки. Когда вы итерируете над логикой агента, вы не хотите перезапускать развёртывание при каждом изменении промпта:

azd ai agent run

Это запускает вашего агента локально. Комбинируйте с azd ai agent invoke для отправки тестовых промптов, и у вас есть быстрый цикл обратной связи. Редактируете код, перезапускаете, вызываете, повторяете.

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

Мониторинг в реальном времени

Вот функция, которая меня купила. После развёртывания агента:

azd ai agent monitor --follow

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

Полный набор команд

Вот краткий справочник:

Команда	Что делает
`azd ai agent init`	Генерирует проект агента Foundry с IaC
`azd up`	Разворачивает Azure-ресурсы и публикует агента
`azd ai agent invoke`	Отправляет промпты удалённому или локальному агенту
`azd ai agent run`	Запускает агента локально для разработки
`azd ai agent monitor`	Транслирует логи от опубликованного агента в реальном времени
`azd ai agent show`	Проверяет состояние и здоровье агента
`azd down`	Удаляет все Azure-ресурсы

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

Хотя пример в анонсе написан на Python, история инфраструктуры не зависит от языка. Ваш .NET-агент получает тот же Bicep-шаблон, ту же настройку managed identity, тот же пайплайн мониторинга. И если вы уже используете azd для своих .NET Aspire-приложений или развёртываний Azure, это вписывается прямо в ваш существующий рабочий процесс.

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

Итог

azd ai agent доступен сейчас. Если вы откладывали развёртывание своих ИИ-агентов, потому что настройка инфраструктуры казалась слишком трудоёмкой, попробуйте это. Ознакомьтесь с полным руководством для полной пошаговой инструкции, включая интеграцию с фронтенд-чат-приложением.