Рефакторинг общего кода в нескольких решениях

Question

У меня есть несколько решений Visual Studio, которые используют общий проект.

Пример:

Solution of the common project
  - Common project

Solution A
  - Common project
  - Custom project A

Solution B
  - Common project 
  - Custom project B

And so on...

Каждое решение имеет свой собственный репозиторий SVN, чтобы разработчики могли работать только над конкретным решением.

Там будет около 50-60 различных решений, и мне нужно иметь возможность создавать их отдельно.

Когда я буду, например, переименовывать метод в общем проекте, который используется в других проектах, есть ли способ применить изменения ко всем решениям?

Как это решение, предложенное здесь ( Существует ли инструмент рефакторинга, который работает с файлами решений? ), я мог бы создать мастер-решение, которое содержит все проекты и рефакторинг оттуда, но мне придется оформить заказ и обновите каждый репозиторий, чтобы сделать это.

Должен ли я изменить структуру своих репозиториев?

Есть ли лучший способ сделать это или избежать этой проблемы?

Answer 1

В Visual Studio нет способа применить определенный рефакторинг к проектам, которые в данный момент не открыты.Рефакторинг будет применяться только к проектам, открытым в текущем решении.

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

Я не совсем уверен, что понимаю, что вы подразумеваете под

Мне придется проверять и обновлять каждый репозиторий, чтобы иметь возможность сделать это.

Любой рефакторинг, затрагивающий все ваши проекты, в конечном итоге заставит вас обновить их все.Так что, похоже, вам все равно придется это делать.Я чувствую, что я что-то здесь упускаю.

Answer 2

У нас есть такой же сценарий, как и у вас, и мы используем многоаспектный подход для его решения:

1) Изменения, характерные для клиента, изолируются от основного приложения с помощью интерфейсов, переопределенных методов или новых методов (когда существующего недостаточно).

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

2) В редком случае, когда изменение должно применяться ко всем решениям, у нас есть одно мастер-решение, которое мы можем использовать для обновления всех проектов.

3) Непрерывная интеграция: при каждой регистрации автоматически создается каждое отдельное решение, а сообщения об успехах или неудачах рассылаются всем разработчикам, чтобы ответственные стороны могли исправить любые критические изменения.

Из-за задействованной ответственности (все знают, кто нарушил сборку), разработчики оказывают значительное (положительное) давление на то, чтобы убедиться, что они не являются причиной проблемы.

Мы используем CruiseControl.Net с хранилищем Subversion, но я уверен, что существует множество других решений, которые будут работать с вашим хранилищем.