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?

Are you using svn:external to include the common project in the custom projects? — Shane Wealti, Jan 08 '12 at 17:33
No, I don't. The developer has to checkout the project manually so the reference doesn't break. I will have a look at svn:external. — Jason, Jan 08 '12 at 17:37

score 3 · Answer 1 · answered Jan 08 '12 at 17:32

3

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.

answered Jan 08 '12 at 17:32

JaredPar

733,204
149
1,241
1,454

I will have checkout every projects from every separate repository that uses the shared project to be able to use a master solution. The thing is not every developer should have all the projects on his workstation. – Jason Jan 08 '12 at 17:36
@Jason i'm still not understanding though. If your refactoring truly touches every project then don't you eventually have to have every project on your machine in order to not break the build? – JaredPar Jan 08 '12 at 17:37
The common project is the base application used by all our customers. When a customer wants to customize or add features to our system, we create a separate solution that depends on the base application. Not every developer has to work on every solutions so they will have to get the whole codebase from the repositories to be able to refactor from a master solution. Sorry if it's not very clear. Does it make more sense? – Jason Jan 08 '12 at 17:41
@Jason what's the process if you make a breaking change then? Does every customer have to sync and correct it manually? – JaredPar Jan 08 '12 at 17:46
That is the particular problem am I trying to solve with this question. I guess I have a bigger problem that I tought. Can you suggest any particular practices to avoid this situation? – Jason Jan 08 '12 at 17:50
@Jason The best way to prevent breaking changes IMHO is to keep asmmeta files for every public / shared assembly in your project and diff them on build. Asmmeta is a way textually representing the exposed API of an assembly so diffing on build would tell you if you make any public API breaking changes. – JaredPar Jan 08 '12 at 17:53

score 2 · Answer 2 · answered Jan 09 '12 at 02:17

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.

Refactoring shared code across multiple solutions

2 Answers2