2012-01-08 23 views
6

Tengo varias soluciones de Visual Studio que comparten un proyecto común.Refactorización de código compartido en varias soluciones

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?

+0

¿Está utilizando svn: external para incluir el proyecto común en los proyectos personalizados? –

+0

No, yo no. El desarrollador debe verificar el proyecto manualmente para que la referencia no se rompa. Echaré un vistazo a svn: external. – Jason

Respuesta

3

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í.

+0

Tendré que pagar todos los proyectos de cada repositorio separado que use el proyecto compartido para poder usar una solución maestra. No todos los desarrolladores deben tener todos los proyectos en su estación de trabajo. – Jason

+0

@Jason, aunque todavía no entiendo. Si su refactorización realmente afecta a cada proyecto, ¿finalmente no tendrá que tener todos los proyectos en su máquina para no romper la construcción? – JaredPar

+0

El proyecto común es la aplicación base utilizada por todos nuestros clientes. Cuando un cliente desea personalizar o agregar funciones a nuestro sistema, creamos una solución separada que depende de la aplicación base. No todos los desarrolladores tienen que trabajar en todas las soluciones, por lo que tendrán que obtener toda la base de código de los repositorios para poder refactorizar desde una solución maestra. Lo siento si no está muy claro. ¿Tiene más sentido? – Jason

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.

Cuestiones relacionadas