Как подключить локальный MCP сервер к GitHub Copilot

MCP (Model Context Protocol) описывает, как ИИ-агент взаимодействует с внешними инструментами. Это простой способ встроить ваши процессы в Copilot Chat.

Для этого поста я написал MCP-сервер, который запускается локально (пример на TypeScript. Поддержка .NET уже в превью).
Этот MCP сравнивает c помощью Git две ветки и помогает провести раннее код-ревью прямо в Copilot Chat.

Что сделаем

— Поднимем сервер с тремя функциями: quick_merge_summary, show_merge_diff, show_file_diff.
— Подключим его к Copilot через mcp.json.
— Запустим промпт и получим обзор пулл-реквеста.

Зачем это разработчику

— Подключайте готовые серверы, оборачивайте свои приложения, скрипты в MCP серверы для расширения возможностей Copilot или других ИИ агентов.
— Прокачиваете навыки работы с ИИ сегодня это требование к AI-ready developer.
— Все операции выполняются в привычном интерфейсе Copilot Chat.

Шаги

— Клонируйте репозиторий https://github.com/sigmade/Git-MCP-Server
— Выполните команды ниже

npm install
npm run build
npm run start

— В папке build появится index.js.

— В C:\Users\YourUserName\AppData\Roaming\Code\User создайте mcp.json и укажите путь к сбилженному файлу index.js.

— Откройте любой проект в VS Code с двумя ветками в моем случае это master и new-feature .

— Убедитесь что MCP стал доступен в VS Code, для этого в Copilot Chat в режиме Agent нажмите на кнопку Configure Tools... в выпадающем списке появится список доступных инструментов, найдите секцию MCP Server в ней должен отобразиться наш MCP - simple-merge-review а так же его функции quick_merge_summary, show_merge_diff, show_file_diff.

— В чат введите промпт например -

Из ветки new-feature в master будет создан пулл-реквест. Сделай предварительное код-ревью

Copilot сам поймет какой MCP сервер нужен и какие функции использовать, после чего соберет диффы и покажет изменения, улучшения и риски.

*Если вы используете Cursor возможно ему придется явно прописать в промпт какой MCP использовать.

Итог

MCP дает разработчику возможность подключать любые скрипты, API или внутренние сервисы к ИИ-агенту и использовать их в Copilot Chat для автоматизации рутины и расширения возможностей для работы с ИИ агентами

Чистая архитектура против многослойной

В своем недавнем посте я рассказывал, как структурирую свои приложения, используя всего три слоя: API, Core (бизнес-логика) и Infrastructure (работа с базой данных, кэшем и внешними сервисами).

Сегодня я хочу подробно остановиться на ключевом отличии многослойной архитектуры от чистой - инверсии зависимостей.

Многослойная архитектура

В многослойной архитектуре API вызывает методы класса Core (UseCase), а Core в свою очередь вызывает методы класса Infrastructure (Repository). Такое разделение уже помогает распределить обязанности, но Core все еще знает о конкретных классах из Infrastructure. Это усложняет изоляцию и тестирование доменной логики.

Чистая архитектура с инверсией зависимостей

В чистой архитектуре вызовы происходят через абстракции. Core зависит от интерфейсов, а конкретные классы подключаются только во время выполнения. Поток управления остается прежним, но тестировать становится намного проще - мы можем подставлять моки и проверять доменную логику в полной изоляции.

Этот принцип лежит в основе создания поддерживаемого кода, и о нем часто спрашивают на собеседованиях.

Итог

Инвертируя зависимости, вы делаете свой слой Core чистым и тестируемым. Это ускоряет разработку и снижает риски при изменении требований. Сделайте инверсию зависимостей фундаментальной частью своего инструментария, чтобы обеспечить гибкость и надежность вашего кода по мере его роста. Для более глубокого погружения в тему, рекомендую Архитектурные принципы и Распространенные архитектуры веб-приложений

Фича-флаги в .NET с IFeatureManager

IFeatureManager из пакета Microsoft.FeatureManagement управляет фича-флагами в .NET. Он позволяет выбирать нужную ветку логики во время работы приложения.

Где пригодится

— Временное включение или быстрое отключение фичи, например при релизе новой версии или хотфиксе
— Отключение проблемного функционала при сбоях
— A/B-тесты
— Временные сценарии, такие как акции

Как это устроено

Регистрируем Feature Management в DI, проверяем состояние флага через IFeatureManager и задаем значения в appsettings.json. При необходимости добавляем фильтры например, TimeWindow активирует флаг только в заданном интервале времени.

В итоге поведение приложения можно менять конфигурацией, без нового деплоя.

Такой подход экономит время, снижает риск ошибок при релизах и дает команде больше контроля над функциональностью прямо в продакшене.

Как из Visual Studio 2022 работать с файлами в корне решения

В Visual Studio 2022 неудобно работать с файлами и папками в корневой директории, где лежит .sln.

Solution Explorer (Обозреватель решения) показывает состав решения, а не реальную структуру репозитория - многие папки/файлы остаются вне обозревателя.

Это особенно заметно, когда нужно быстро править/добавить конфиги, документы или служебные каталоги (например, .github с copilot-instructions md - лишь один из частых кейсов).

Мы, конечно, можем вместо решения открыть сразу корневую папку. Однако чаще удобнее работать именно с открытым
Solution Explorer.

В VS Code это решено наличием полноценного File Explorer рядом с Solution Explorer.

В VS2022 аналог можно получить через расширение File Explorer от Mads Kristensen.

Что дает File Explorer в VS2022

— Полный доступ ко всем файлам и папкам в корне репозитория, а не только к проектам из решения.
— Меньше переключений между IDE и проводником Единое рабочее окно Solution Explorer + файловый эксплорер.

Как настроить

— Extensions - Manage Extensions - найдите File Explorer (Mads Kristensen).
— Установите и перезапустите Visual Studio.
— В Solution Explorer появится папка которая отображает содержимое корневой папки репозитория/решения

Если вы часто работаете с файлами в корне репозитория (конфиги, CI/CD, документацию, тот же .github), это расширение - must-have.

Пост на LinkedIn, Medium

Неочевидные факты из истории C#, которые стоит знать

C# - это гораздо больше, чем «еще один язык программирования».
За ним стоят годы умных экспериментов в Microsoft, которые изменили не только .NET, но и всю индустрию ПО.

Вот несколько ключевых моментов, показывающих, как C# стал настоящим инноватором:

1. 2002 - рождение C# и .NET

Главный архитектор: Андерс Хейлсберг (также создатель Turbo Pascal и Delphi).
C# 1.0 вышел вместе с .NET Framework 1.0.
Цель: создать современный, безопасный и простой язык - проще, чем C++, но с собственным взглядом Microsoft.

2. Начало 2000-х - исследовательский проект Cω (Comega)

Cω был не продуктом, а исследовательским проектом Microsoft Research.
Он объединял идеи Polyphonic C# и Xen, экспериментируя с работой с данными и конкурентностью.
Результат: Cω не стал реальным языком, но вдохновил на создание LINQ.

3. 2007 - LINQ и идеи функционального программирования

С выходом C# 3.0 Эрик Мейер привнёс идеи из функциональных языков вроде Haskell и ML.
Новые фичи: LINQ (from/where/select), лямбды, extension methods, var, анонимные типы, expression trees (используются в Entity Framework).
Эти идеи сделали C# выразительнее и позволили писать чище и мощнее.

4. 2012 - влияние F# и появление async/await

В C# 5.0 был перенесен и адаптирован async/await из F#, где уже были “async workflows”.
Это помогло уйти от старых, громоздких моделей асинхронности.

5. 2015–2021 - как C# повлиял на другие языки

Асинхронность (async/await):

Python 3.5 (2015)
JavaScript ES2017 (2017)
Kotlin 1.3 (2018)
Rust 1.39 (2019)
Swift 5.5 (2021)

Функциональный стиль (идеи LINQ):

Java Streams API (Java 8, 2014)

Вывод

C# не просто следовал трендам - он их задавал.
Он изменил то, как разработчики думают об асинхронности, данных и дизайне языков.

P.S. Интересный факт после публикации

После публикации этого поста в LinkedIn к нему оставил комментарии сам Don Syme - создатель и главный архитектор языка F#. Он подчеркнул важные моменты:

“Language integrated async programming was shipped first in F# in 2006 and was copied and adapted into C# in the following years.”

“The history of Generics, LINQ and async programming, iterators and more is covered tangentially in ‘The Early History of F#’
https://dl.acm.org/doi/abs/10.1145/3386325

There’s no corresponding peer reviewed paper on the history of C# unfortunately.”

Он также отметил, что важный вклад в C# в 2000-х внесли следующие люди:

Gavin Bierman - COmega
Cédric Fournet - COmega
Nick Benton - COmega
Erik Meijer - LINQ и многое другое
Todd Proebsting - iterators
Andrew Kennedy - generics
Claudio Russo - generics

Пост на LinkedIn