Come strutturare più soluzioni / progetti sovrapposti in .Net?

Di recente ho iniziato a lavorare per un nuovo client con una vecchia base di codice legacy in cui ci sono più soluzioni .net, ognuna in genere ospita alcuni progetti unici per quella soluzione ma poi "prende in prestito" / "collegamenti" (aggiungi progetto esistente) altri progetti che tecnicamente appartiene ad altre soluzioni (almeno se si passa dalla struttura delle cartelle in TFS)

Non ho mai visto una configurazione così intrecciata, non esiste un ordine di compilazione chiaro, a volte un progetto nella soluzione A fa solo riferimento alle DLL direttamente dalla directory di output di un progetto ospitato nella soluzione B, a volte il progetto è stato appena incluso direttamente anche se risiede Lontano nella struttura delle cartelle.

Sembra che tutto sia stato ottimizzato per la pigrizia degli sviluppatori.

Quando li ho confrontati con il motivo per cui non avevano un server CI, mi hanno risposto che è difficile impostare il codice organizzato così com'è. (Lo sto configurando ora e maledendo questa organizzazione del codice)

Le soluzioni sono organizzati intorno artefatti distribuzione (roba che deve essere distribuito insieme si trovano nella stessa soluzione), che io penso è una decisione saggia, ma il contenuto di tali soluzioni (i progetti) sono in tutto il luogo.

Esiste un consenso sulle migliori pratiche da utilizzare quando si riutilizzano librerie di classi comuni su più soluzioni / artefatti di distribuzione,

• Come strutturare il codice nel VCS
• Come facilitare la condivisione della logica aziendale tra artefatti di distribuzione separati

Non sono mai stato un fan di includere progetti esistenti che appartengono ad altre soluzioni. Esistono troppe variabili in cui apportare una modifica a quel progetto per 1 soluzione interrompe completamente qualcosa in un'altra soluzione. Quindi risolvendo questo problema si finisce per rompere la soluzione originale. Raccogliere, sciacquare, ripetere.

Quando questo tipo di dipendenza si perde in più soluzioni, mi piace separare il codice dipendente nella sua soluzione PROPRIA e creare una libreria black-box che viene quindi inclusa come riferimento. Penso che le tue soluzioni siano state intrecciate in modo che il debug possa essere eseguito fino in fondo nel progetto condiviso per ogni soluzione. Se la libreria è costruita e testata correttamente, questo tipo di debug non è davvero necessario. La biblioteca dovrebbe essere in grado di resistere ai propri meriti e dovrebbe essere testata a fondo in modo che le aspettative di qualsiasi progetto del consumatore siano soddisfatte in modo coerente.

In realtà ho organizzato strutture TFS simili a quella che stai menzionando e mentre presenta sfide uniche per CI presenta numerosi vantaggi. Uno chiaro è che supporta e incoraggia la corretta componentizzazione in progetti .NET separati e quindi supporta un buon TDD incoraggiando la copertura del test al 100%. Immediatamente noto alcuni problemi che puoi affrontare.

a volte un progetto nella soluzione A fa semplicemente riferimento alle DLL direttamente dalla directory di output di un progetto ospitato nella soluzione B, a volte il progetto è stato appena incluso direttamente anche se risiede LONTANO nella struttura delle cartelle.

I riferimenti binari all'output di altre directory non sono un buon approccio e diventano un cattivo approccio anche se mescolati con riferimenti di progetto. Prova a fare l'uno o l'altro, preferibilmente cambiando i tuoi riferimenti binari in riflessioni di progetto per coerenza almeno. A questo punto ogni soluzione può rappresentare una singola applicazione o livello di applicazione costruibile (ad esempio SuperApp.sln, OtherAppServices.sln, OtherAppPresentationTier.sln).

Per realizzare TUTTI i progetti, consiglio di creare anche una soluzione master. La soluzione master avrà riferimenti di progetto a tutto ed esiste essenzialmente per il solo vantaggio di avere un comando di generazione singolo che gestisce tutti i progetti nella suite di applicazioni. Gli sviluppatori non devono utilizzare la soluzione master per lo sviluppo attivo o il debug. Questo rende molto più semplice il montaggio dei manufatti di costruzione.

La distribuzione può quindi essere eseguita con un semplice batch, PowerShell o script Perl. Questo essenzialmente costruirà la soluzione appropriata o la soluzione Master e quindi distribuirà tutto negli ambienti appropriati. Questo può essere facilmente integrato in qualsiasi server CI se fatto bene.

• Come facilitare la condivisione della logica aziendale tra artefatti di distribuzione separati

Creare un progetto per una logica aziendale comune o avere una migliore separazione delle preoccupazioni per una logica aziendale più globale o universale. Tutte le soluzioni distribuibili che desiderano fare riferimento a ciò dovrebbero farlo mediante un riferimento al progetto.

Nell'organizzazione del codice in TFS, diventa più facile raggiungere questo obiettivo mantenendo i progetti comuni o condivisi a un livello superiore nella struttura di directory.