Shared code refactoring for multiple solutions

Question

I have several Visual Studio solutions that have 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 so that developers can work only with a specific solution.

There will be about 50-60 different solutions, and I will need to create them myself.

When, for example, I rename a method to a common project that is used in other projects, is there a way to apply changes to each solution?

Like this proposed solution ( Is there a refactoring tool that works with solution files? ), I could create a main solution that contains all the projects and refactoring from there, but I will need to check and update each repository to do this.

Should I restructure my repositories?

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

Answer 1

In Visual Studio, there is no way to apply specific refactoring to projects that are not currently open. Refactoring will only apply to projects open in the current solution.

To facilitate the reorganization in a large number of solutions, the best approach is simply to create a main solution that covers all projects. It can be a little die-hard and slowly used for general purposes. But for large-scale refactoring, it can save a lot of items.

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

I will need to check and update each repository to do this.

Any refactoring that affects all of your projects will ultimately force you to update them all. So it looks like you still have to do it. I feel that something is missing here.

Answer 2

We have a similar scenario like you, and we use a multi-purpose approach to solve it:

1) Client-specific changes are isolated from the main application through the use of interfaces, overridden methods, or new methods (when an existing one is not enough).

This ensures that the underlying application platform is backward compatible with existing solutions.

2) In the rare case when changes should be applied to all decisions, we have one main solution that we can use to update all projects.

3) Continuous integration: in each separate session, each automatic construction of each solution and messages on successful completion or failure are distributed to all developers so that responsible parties can correct any violations.

Due to responsibility (everyone knows who broke the assembly), there is a lot of (positive) pressure on the developers to ensure that they are not the ones that can cause the problem.

We use CruiseControl.Net with the subversion repository, but I'm sure there are many other solutions that will work with your repository.