Перейти до вмісту
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 чи асинхронності, перш ніж дозволити агенту щось переписувати.

Деталі рушія

  • >Префікси `using` нормалізуються в імпортах, а суфікси нульованості чи масивів на кшталт `?` і `[]` видаляються з визначень символів.
  • >Інстанціювання використовує вузли викликів із видаленням дужок дженериків, що допомагає зберегти читабельність конструкторного використання в графі.
  • >Конфігурація явно відфільтровує велику кількість шуму BCL і LINQ, щоб специфічні для репозиторію сервіси та моделі було легше виявити.

Корисні точки входу MCP

  • find_symbol

    Використовуйте, коли знаєте назву контролера, сервісу, DTO чи спільного типу, до якого збираєтеся торкнутися.

  • dependency_search

    Використовуйте вхідний обхід перед редагуванням основного сервісу чи моделі, що використовується в усьому застосунку.

  • get_task_context

    Корисно для запитів на кшталт «простеж цей запит від контролера до репозиторію» в багатошарових кодових базах .NET.