Cli | The .NET Blog

dotnet new WinUI: Создавайте Windows-приложения без Visual Studio

Emiliano Montesdeoca — Wed, 27 May 2026 00:00:00 +0000

Раньше для разработки WinUI требовался Visual Studio. Это меняется: Microsoft опубликовала шаблоны проектов и элементов с открытым исходным кодом для WinUI, которые работают с dotnet new, интегрируя разработку Windows-приложений в стандартный рабочий процесс CLI.

Начало работы в три команды

# Установка шаблонов
dotnet new install Microsoft.WindowsAppSDK.WinUI.CSharp.Templates

# Создание приложения NavigationView
dotnet new winui-navview -n MyApp

# Запуск
cd MyApp
dotnet run

Никакого Visual Studio, никакой ручной настройки проекта. Приложение запускается через dotnet run.

Что включено

Пустой шаблон (dotnet new winui) — современная отправная точка с уже настроенной заголовочной панелью Fluent, обновлённой иконкой приложения с ресурсом .ico и правильными настройками светлого/тёмного режима по умолчанию. Лучше старого пустого шаблона, где нужно было самому настраивать основы.

Шаблон NavigationView (dotnet new winui-navview) — паттерн навигации «ведущий-детальный», полностью настроенный с NavigationView, современной заголовочной панелью и многостраничной структурой навигации. Следует стандартному силуэту Windows-приложений для приложений на основе навигации. Если вы строите что-то с боковой навигацией, начните отсюда.

Оба шаблона следуют силуэтам Windows-приложений — современным паттернам Fluent Design для макета, навигации и визуальной структуры — прямо из коробки.

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

Разработчики WinUI, использующие VS Code, Rider или инструменты командной строки, были в невыгодном положении. Существующие шаблоны Visual Studio нельзя было использовать вне VS — приходилось вручную воссоздавать структуру проекта и настраивать основы.

Эти шаблоны имеют открытый исходный код (см. WindowsAppSDK PR #6407), разработаны на основе отзывов сообщества и доступны прямо сейчас. Поддержка Visual Studio в разработке — эти же шаблоны в конечном счёте будут работать и там.

Для команд, которые хотят автоматизировать настройку проектов WinUI, интегрировать её в CI или просто использовать редактор, отличный от Visual Studio, это существенное улучшение.

Оригинальный пост: Introducing dotnet new WinUI templates

Cosmos DB Shell В Публичной Предварительной Версии — И В Нём Встроен MCP-Сервер

Emiliano Montesdeoca — Sun, 24 May 2026 00:00:00 +0000

Если вы когда-либо вынуждены были переключаться между вкладкой портала, примером SDK и незаконченным скриптом только для ответа на один вопрос о Cosmos DB, вы уже знаете трение, которое этот проект призван устранить.

Azure Cosmos DB Shell только что вошёл в публичную предварительную версию. Это CLI с открытым исходным кодом с bash-подобным синтаксисом и — часть, которая делает это интересным — встроенным MCP-сервером.

Что Отличает Его от Других CLI Баз Данных

CLI сам по себе полезен: знакомые команды, поддержка скриптов, интеграция CI/CD. Эта часть — минимальный стандарт для инструмента базы данных, ориентированного на разработчиков.

Интересная часть — интеграция MCP-сервера. Каждая команда, которую предоставляет CLI, становится доступной как MCP-инструмент, который ваши ИИ-агенты могут вызывать. Нет пользовательского API-слоя, нет кода интеграции для написания. Ваш агент может:

Навигировать по иерархиям баз данных с помощью cd, ls, pwd
Выполнять SQL-запросы с помощью query и получать структурированные результаты
Создавать и изменять элементы с помощью create item, update, rm
Управлять базами данных и контейнерами с помощью mkdb, mkcon, rmdb, rmcon
Инспектировать текущий контекст с помощью endpoint, pwd

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

Основа с Открытым Исходным Кодом Важна

Это не управляемый сервис “чёрного ящика”. Оболочка имеет открытый исходный код, что означает:

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

Для корпоративных команд, внедряющих инструменты ИИ, “можем ли мы точно видеть, как это работает” всё реже является необязательным требованием. Открытый исходный код здесь — значимое отличие.

Три Сценария, Которые Становятся Проще

Интеллектуальный анализ данных — подключите агента к оболочке, задавайте вопросы на естественном языке, получайте структурированные результаты запросов. Агент обрабатывает построение запроса; оболочка обрабатывает выполнение.

Автономное управление данными — рабочие процессы, которым необходимо создавать, обновлять или удалять данные в Cosmos DB, могут делать это через MCP-инструменты без необходимости пользовательской интеграции.

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

Интерфейс MCP делает эти сценарии компонуемыми с любой ИИ-платформой, поддерживающей MCP — не только с инструментами Microsoft.

С Чего Начать

Оболочка находится в публичной предварительной версии. Установите её, настройте подключение к Cosmos DB и включите MCP-сервер. После этого любой совместимый с MCP хост агента может обнаружить и использовать инструменты.

Оригинальный пост: Announcing the Public Preview of Azure Cosmos DB Shell: Open-Source Power Meets AI-Driven Database Automation

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, все подробности — в оригинальном анонсе.

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

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

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

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

Cli | The .NET Blog

dotnet new WinUI: Создавайте Windows-приложения без Visual Studio

Начало работы в три команды

Что включено

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

Cosmos DB Shell В Публичной Предварительной Версии — И В Нём Встроен MCP-Сервер

Что Отличает Его от Других CLI Баз Данных

Основа с Открытым Исходным Кодом Важна

Три Сценария, Которые Становятся Проще

С Чего Начать

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

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

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

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

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

Как получить

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

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

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

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

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

Подводя итог

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

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

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

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

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

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

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

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

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

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

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

Решение: --isolated

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

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

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

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

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

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

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

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

Поиск по теме

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

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

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

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

Подводя итог

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