Refactoring shared code across multiple solutions

Question

I have several Visual Studio solutions which shares a common project.

Example:

Solution of the common project
  - Common project

Solution A
  - Common project
  - Custom project A

Solution B
  - Common project 
  - Custom project B

And so on...

Each solution has its own SVN repository for developers to be able to work only on a particular solution.

There will be about 50-60 different solutions and I need to be able to build them separately.

When I will be, for example, renaming a method in the common project that is used in other projects, is there a way to apply the changes to every solutions?

Like this solution suggested here (Is there a refactoring tool that works across solutions files?), I could create a master solution which contains all the projects and refactor from there, but I will have to checkout and update every repository to be able to do this.

Should I change the structure of my repositories?

Is there a better way to do this or avoid this problem?

Answer 1

There is no way in Visual Studio to apply a particular refactoring to projects which are not currently open. Refactorings will only be applied to projects open in the current solution.

To facilitate refactorings across a large number of solutions the best approach is to simply create a master solution encompassing all of the projects. This can be a bit unweildy and slow to use for general purposes. But for large scale refactorings it can save a lot of item.

I'm not quite sure I understand what you mean by

I will have to checkout and update every repository to be able to do this.

Any refactoring which touches all of your projects will eventually force you to update all of them. So it would seem like you'd need to do this anyways. I feel like I'm missing something here.

Answer 2

We have a similar scenario as you and we utilize a multi-pronged approach to solve it:

1) Customer-specific changes are isolated from the core application through the use of interfaces, overridden methods, or new methods (when an existing one won't suffice).

This ensures that the core application framework is backwards compatible with existing solutions.

2) In the rare case where a change must be applied to all solutions, we have a single master solution that we can use to update all projects.

3) Continuous integration: on every single checkin, every single solution is automatically built and success or fail messages are distributed to all developers so that the responsible parties can fix any breaking changes.

Because of the accountability involved (everyone knows who broke the build), there is a good amount of (positive) pressure on the developers to ensure they are not the ones to cause the problem.

We use CruiseControl.Net with a subversion repository, but I am sure there are plenty of other solutions out there that would work with your repository.