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

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

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

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

Много команд, использующих AI-инструменты, живут в мире .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 для запросов вроде «проследить этот запрос от контроллера до репозитория», когда путь охватывает несколько слоёв.

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

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