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

Деталі рушія

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

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

  • find_symbol

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

  • dependency_search

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

  • get_task_context

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