Refactorización de código compartido en varias soluciones

Question

Tengo varias soluciones de Visual Studio que comparten un proyecto común.

Ejemplo:

Solution of the common project 
    - Common project 

Solution A 
    - Common project 
    - Custom project A 

Solution B 
    - Common project 
    - Custom project B 

And so on... 

Cada solución tiene su propio repositorio SVN para los desarrolladores para ser capaces de trabajar sólo en una solución particular.

Habrá aproximadamente 50-60 soluciones diferentes y necesito poder construirlas por separado.

Cuando estaré, por ejemplo, cambiando el nombre de un método en el proyecto común que se usa en otros proyectos, ¿hay alguna forma de aplicar los cambios a cada solución?

Al igual que esta solución sugerida aquí (Is there a refactoring tool that works across solutions files?), podría crear una solución maestra que contenga todos los proyectos y refactorizar desde allí, pero tendré que verificar y actualizar cada repositorio para poder hacer esto.

¿Debo cambiar la estructura de mis repositorios?

¿Hay una manera mejor de hacer esto o evitar este problema?

Answer 1

No es posible en Visual Studio aplicar una refacturación en particular a proyectos que no están actualmente abiertos. Las refabricaciones solo se aplicarán a proyectos abiertos en la solución actual.

Para facilitar las refactorizaciones en una gran cantidad de soluciones, lo mejor es simplemente crear una solución maestra que abarque todos los proyectos. Esto puede ser un poco flojo y lento de usar para propósitos generales. Pero para refactorizaciones a gran escala, puede ahorrar muchos artículos.

No estoy muy seguro de entender qué quiere decir con

voy a tener que obtener y actualizar cada repositorio para ser capaz de hacer esto.

Cualquier refacturación que toque todos sus proyectos eventualmente lo forzará a actualizarlos todos. Entonces parece que necesitarías hacer esto de todos modos. Siento que me falta algo aquí.

Answer 2

Tenemos un escenario similar como usted y que utilizan un enfoque múltiple para resolverlo:

1) cambios específicos del cliente están aislados de la aplicación principal a través del uso de interfaces, métodos sustituidos, o una nueva métodos (cuando uno existente no será suficiente).

Esto garantiza que el marco de aplicación central sea compatible con versiones anteriores de las soluciones existentes.

2) En el raro caso en que se deba aplicar un cambio a todas las soluciones, tenemos una única solución maestra que podemos usar para actualizar todos los proyectos.

3) Integración continua: en cada registro individual, cada solución se genera automáticamente y los mensajes de éxito o fracaso se distribuyen a todos los desarrolladores para que las partes responsables puedan corregir cualquier cambio.

Debido a la responsabilidad involucrada (todos saben quién rompió la compilación), hay una buena cantidad de presión (positiva) sobre los desarrolladores para garantizar que no sean ellos los que causen el problema.

Usamos CruiseControl.Net con un repositorio de subversión, pero estoy seguro de que hay muchas otras soluciones que funcionarían con su repositorio.