Обычно рефакторинг представляется тяжелой работой над ошибками. Монотонное исправление ошибок прошлого вручную. Но если наши действия можно свести к алгоритму преобразований над A, чтобы получить B, то почему бы не автоматизировать этот процесс? Таких кейсов может быть очень много — инверсия зависимостей (как пример архитектурных измений), добавление аттрибутов, внедрение аспектов (пример добавления сквозной функциональности) и разнообразные компоновки кода в классы и методы, а также переход к новой версии API — в этой статье рассмотрим этот случай подробно. Все проекты используют API. API модулей, компонентов, фреймворков, операционной системы, публичные API сервисов — в большинстве случаев эти API представлены в виде интерфейсов. Но все вокруг меняется, меняются и API. Появляются новые версии, появляются obsolete методы. Было бы классно иметь возможность автоматически переходить на новую версию без накладных расходов на рефакторинг проекта.  Veeam предоставляет своим разработчикам все инструменты, которые сам разработчик посчитает необходимыми. И у меня есть лучшее, что может пригодиться для рефакторинга — ReSharper. Но…  В 2015 у ReSharper был issue. В начале 2016 у issue RSRP-451569 сменился статус на Submitted. Также в 2016 запрос обновили. Проверила на последнем обновлении — нужной функциональности нет, нет ни подсказок от решарпера, ни специального аттрибута в JetBrains.Annotations. Вместо того, чтобы ждать пока эта функциональность появится у ReSharper, я решила сделать эту задачу своими силами.  Первое что приходит в голову при работе над рефакторингом .NET кода — это IntelliSense. Но его API, на мой взгляд, довольно сложный и запутанный, к тому же сильно завязан на Visual Studio. Потом мне под руку попалась такая вещь как DTE (EnvDTE) — Development Tools Environment, по сути, это интерфейс ко всем возможностям студии, которые доступны через UI или командную строку, с его помощью можно автоматизировать любую последовательность действий, которую можно совершить в Visual Studio. Но DTE — штука неудобная, она постоянно требует контекст действия, т.е. эмулировать целого программиста. Тривиальные действия, вроде поиска определения метода, давались с трудом. В процессе преодоления трудностей работы с DTE, мне попалось видео доклада Александра Кугушева: Доклад меня заинтересовал, я попробовала и поняла, что решать такого рода задачи с помощью Roslyn намного более естественно. А еще не забываем про полезный Syntax Visualizer, который поможет понять как устроен ваш код на уровне языка.  Так я выбрала своим инструментом .NET Compiler Platform "Roslyn".  Рассмотрим эту задачу на искусственном примере. Пусть мы имеем интерфейс API с устаревшими методами, маркируем их аттрибутом  с указанием в сообщении, на какой метод его следует заменить  и его неразмеченную аттрибутами реализацию  Пример использования нашего интерфейса, поскольку здесь мы обращаемся к IAppService, то получаем предупреждение компилятора, что метод устарел. А здесь мы используем уже экземпляр реализации этого интерфейса и никакого предупреждения уже не получим. Исправляем ситуацию Использование Roslyn влечет за собой использование декларативного программирования и функционального подхода, а здесь главное задаться Главной Целью и тщательно ее описать. У нас Главная Цель — заменить все устаревшие методы на их новые аналоги. Описываем.  Алгоритм рефакторинга готов, за исключением отсутствия в нем технических моментов работы с тремя столпами .NET кода — Document, Syntax Tree, Semantic Model. Это всё сильно напоминает лямбды. В них мы и будем выражать нашу Главную Цель. Инфраструктура
Инфраструктурой для нашего решения служат Document, Syntax Tree, Semantic Model.  недостающие данные возьмем извне, понадобится полный путь к солюшену, в котором лежит проект с API и проекты, в котором он используется — при небольшой доработке можно размещать их в разных солюшенах. А еще нужно указать имя класса интерфейса API, если ваш API будет построен на абстрактном классе или еще как-то, то посмотрите с помощью Syntax Visualizer какой тип определения этого класса. частные элементы инфраструктуры получим в ReplaceObsoleteApiCalls Возвращаемся к алгоритму и ответим на простые вопросы в нем, начинать нужно с конца.
4. Найди определение метода, у которого есть атрибут  3. В классе интерфейса API 2. Найди пару устаревший-новый метод 1. Замени устаревший метод на новый Отвечаем на вспомогательные вопросы.
5. В сообщении атрибута  найдешь имя нового метода 6. По всем ссылкам на устаревший метод (хотя можешь сделать исключения для некоторых проектов и классов) Уточнение об исключениях можно представить следующими фильтрами. Запускаем и получаем вот такую красоту.

 Проект можно оформить как расширение студии vsix или, например, положить на сервер контроля версий и использовать как анализатор. А можно запускать при необходимости как тулу. Весь проект опубликован на гитхабе.