Contesto per domanda
Sto lavorando su un prodotto legacy, che ha più progetti: librerie di classi, siti Web, servizi Windows, servizi Web, ecc. Ho un singolo file di soluzione che contiene tutti i progetti (quasi 70 progetti). Ho usato Teamcity CI per costruire questa soluzione. Funziona bene. Sto usando Microsoft Visual Studio.
Refactor codice
Vogliamo suddividerli in più file di soluzione ciascuno dei quali farà riferimento alle librerie di classi richieste.
- Se c'è un cambiamento solo in uno dei servizi di Windows / servizio web / sito Web, allora tale soluzione verrà creata da teamcity, non dall'intera soluzione.
- Debugging efficiente spiegato di seguito.
Domanda - È consigliabile farlo?
Possibili scenari: Say svc1 dipende da lib1, lib2, lib3. e svc2 dipende da lib1, lib2.
- Svc1 - Svc1.sln (contenente lib1, lib2, lib3)
- lib1
- lib2
- lib3
- Svc2 - Svc2.sln (contenente lib1, lib2)
- lib1
- lib2
Qui, lib1, lib2 sono libreria condivisa, e svc1, svc2 dipendono da loro. lib1, lib2 risiedono nella stessa ubicazione del progetto, ma 2 soluzioni diverse le riferiscono e vengono aggiunte come riferimento del progetto .
Domanda - È ancora consigliabile fare questo refactoring per i file di soluzione di segregazione del sake per creare build e debug (questo perché, ora svc1 avrà solo 3 progetti dipendenti, e io non ho per aprire 70 progetti per eseguire il debug di svc1) più veloce ed efficiente.