Перейти к содержимому
cd /languages
  • Долгоживущий .NET
  • Программирование
  • Поддержка AST и символов

Поддержка C# в Maguyva: более безопасный рефакторинг для кодовых баз .NET

Maguyva поддерживает C# с разбором AST и извлечением символов, чтобы ИИ-агенты могли работать в сервисах .NET, бизнес-логике с активным использованием LINQ, общих библиотеках и долгоживущих корпоративных репозиториях.

Что важно в зрелых кодовых базах .NET

Много команд, использующих ИИ-инструменты, живут в мире .NET, а не в новых проектах на JavaScript. У них есть API, worker-процессы, общие модели, внутренние библиотеки и годы бизнес-логики. Вопрос не в том, способен ли LLM генерировать синтаксис C#. Вопрос в том, способен ли он опираться на факты внутри репозитория, где одна неверная правка может отозваться эхом по сервисам, моделям и общим абстракциям.

Поэтому страница про C# должна быть конкретнее, чем просто «поддерживается».

Что Maguyva реально извлекает в C#

Maguyva нормализует импорты using, убирает из определений суффиксы nullable-типов и массивов вроде ? и [], а также трактует узлы вызова, похожие на конструкторы, как создание экземпляров, убирая при этом угловые скобки дженериков. Это полезные детали для C#-репозиториев с обилием классов, потому что они делают граф чище вокруг реальных доменных типов.

Конфигурация также отфильтровывает большую часть шума от BCL и LINQ. Это важнее, чем кажется. В зрелых кодовых базах .NET граф, в котором доминируют вызовы фреймворка, не особенно полезен. Полезен тот граф, где по-прежнему выделяются специфичные для репозитория контроллеры, сервисы, DTO и вспомогательные классы.

Полезные MCP-сценарии для кодовых баз .NET

На практике работа обычно начинается с:

  • find_symbol, когда вы знаете имя контроллера, сервиса, DTO или модели.
  • dependency_search перед изменением общего сервиса или типа, у которого может быть много входящих обращений.
  • get_task_context для запросов вроде «проследить этот запрос от контроллера до репозитория», когда путь охватывает несколько слоёв.

Когда эта страница полезна

Эта страница — для команд, которым нужна ИИ-помощь внутри настоящей кодовой базы .NET, а не в игрушечном проекте. Если окружающая система больше про JVM, чем про .NET, сравните с Java. Если ваш слой C# — лишь часть более крупной полиглотной системы, соседняя страница TypeScript обычно тоже актуальна.

Лучше всего подходит

  • > Репозитории ASP.NET, worker-сервисов и внутренних платформ, где смешаны веб-эндпоинты, фоновые задачи и общие библиотеки.
  • > Команды, поддерживающие зрелые системы на .NET, где LINQ, асинхронные потоки и абстракции фреймворка скрывают реальный путь выполнения.
  • > Команды, проверяющие, способен ли агент опираться на фактическую структуру многослойного кода .NET, прежде чем переписывать бизнес-логику.

Сценарии работы агента

  • > Проследить путь контроллер → сервис → репозиторий перед изменением бизнес-логики.
  • > Проверить, где по репозиторию создаются экземпляры модели, DTO или общей утилиты.
  • > Разобраться в окружающих паттернах LINQ или async, прежде чем позволить агенту что-либо переписывать.

Детали движка

  • > Префиксы `using` нормализуются в импортах, а суффиксы nullable или массивов, такие как `?` и `[]`, удаляются из определений символов.
  • > Создание экземпляров определяется по узлам вызова с удалением угловых скобок дженериков, чтобы вызовы, похожие на конструкторы, были понятнее в графе.
  • > Конфигурация явно отфильтровывает большие объёмы шума BCL и LINQ, чтобы сервисы и модели, специфичные для репозитория, было легче обнаружить.

Полезные точки входа MCP

  • find_symbol

    Используйте его, когда знаете имя контроллера, сервиса, DTO или общего типа, который собираетесь изменить.

  • dependency_search

    Используйте обход incoming перед изменением базового сервиса или модели, используемых по всему приложению.

  • get_task_context

    Полезно для запросов вроде «проследи этот запрос от контроллера до репозитория» в многослойных кодовых базах .NET.