Numero di progetti consigliato in Visual Studio Solution

Question

Stiamo iniziando a sviluppare nuove applicazioni che includeranno qualcosa come 30-50 progetti sviluppati da una decina di sviluppatori con C# in MS Visual Studio.

Sto lavorando alla componentizzazione dei moduli dell'applicazione per supportare l'architettura e abilitare il lavoro parallelo.

Abbiamo discusso: quante soluzioni dovremmo avere?

Alcuni sostengono che dovremmo avere 1-2 soluzioni con 15-30 progetti ciascuna. Alcuni sostengono che abbiamo bisogno di una soluzione per componente che significa circa 10-12 soluzioni con circa 3-6 progetti ciascuna.

sarei felice di sentire pro/contro e l'esperienza con ogni direzione (o altra direzione di esso)

Grazie

Answer 1

Non credo che il numero effettivo di soluzioni questioni. Molto più importante è che rompi la cosa lungo linee funzionali. Come esempio stupido e forzato se si dispone di una serie di librerie che gestiscono l'interoperabilità con servizi Web esterni, questa sarebbe una soluzione; un EXE con le DLL che deve funzionare sarebbe un altro.

Answer 2

Penso che non dovresti esagerare il numero di progetti/soluzioni. Componente cosa può
e sarà riutilizzato per il, altrimenti non eseguire la componentistica! Renderà le cose solo meno trasparenti e aumenterà i tempi di costruzione. Il partizionamento può anche essere fatto all'interno di un progetto usando la cartella o usando una struttura di classe logica.

Answer 3

Si desidera mantenere i riferimenti del progetto. Se riesci a suddividere la tua soluzione in modo sicuro con due o più serie discrete di progetti che dipendono l'uno dall'altro, fallo. Se non puoi, allora tutti appartengono insieme.

Answer 4

Le soluzioni sono davvero disponibili per la gestione delle dipendenze, quindi è possibile avere un progetto in più di una soluzione, se più di una cosa dipende da esso. Il numero di soluzioni dovrebbe realmente dipendere dal grafico delle dipendenze.

Modifica: Ciò significa che non si devono attaccare progetti che non dipendono gli uni dagli altri nella stessa soluzione, in quanto crea l'illusione della dipendenza, il che significa che qualcuno potrebbe creare una vera dipendenza quando due progetti dovrebbero essere realmente indipendenti.

Answer 5

L'unica cosa su così tanti progetti in una soluzione è che i riferimenti e l'ordine di costruzione iniziano a generare confusione.

Come regola generale, mi piacerebbe ridurre il numero di progetti (rendere il progetto un po 'più generico) e fare in modo che gli sviluppatori condividano il controllo del codice sorgente su tali progetti, ma separare la funzionalità all'interno di tali progetti per sotto-namespace.

Answer 6

Ho lavorato a una soluzione con quasi 200 progetti. Non è un grosso problema se hai abbastanza RAM :).

Una cosa importante da ricordare è che i progetti dipendono l'uno dall'altro (sia con Dipendenze o Riferimenti), dovrebbero probabilmente essere nella stessa soluzione. Altrimenti si ottiene uno strano comportamento quando diversi progetti hanno dipendenze diverse in soluzioni diverse.

Answer 7

Dovresti avere tutto il necessario. Non ci sono limiti duri o buone pratiche. Esercitati e leggi quali sono i progetti e le soluzioni e poi prendi le giuste decisioni di ingegneria su ciò di cui hai bisogno da lì.

Answer 8

Abbiamo una soluzione con circa 130 progetti. Circa 3 anni fa, quando usavamo vsnet 2003, si è trattato di un problema terribile. A volte soluzione e VSS stavano andando in crash.

Ma ora con VS.NET 2005 è ok. Solo il caricamento richiede molto tempo. Alcuni miei colleghi che scaricano progetti che non usano. È un'altra opzione per accelerare.

Cambiare il tipo di build per rilasciare è un altro problema. Ma ora abbiamo script MSBuild. Non usiamo relese build di VS.NET non più.

Answer 9

È stato detto in altre risposte, tuttavia, è probabilmente da ripeterlo.

Le dipendenze del progetto sono buone in quanto possono ricostruire i progetti dipendenti se la dipendenza ha una modifica.

Se si esegue una dipendenza da file di assiemi, non è possibile che VS o MSBuild sappiano che è necessario creare una serie di progetti. Quello che accadrà è che nella prima build il progetto che è cambiato verrà ricostruito. Se hai messo la dipendenza dall'output di build, almeno nella seconda build il progetto dipende da quello che verrà creato. Ma poi hai un numero sconosciuto di build necessarie per arrivare alla fine della catena.

Con le dipendenze del progetto, risolverà tutto per te.

Quindi la risposta che dice ha tanti (o pochi) necessari per garantire che le dipendenze del progetto vengano utilizzate.

Se la tua squadra è suddivisa in aree funzionali che hanno un meccanismo di rilascio più formale piuttosto che il check-in del codice sorgente, allora la suddivisione in quelle linee sarebbe la strada da percorrere, altrimenti la mappa delle dipendenze è tua amica.

Answer 10

Ho lavorato su entrambi i prodotti: uno con ~ 100 progetti in un'unica soluzione e uno con> 20 soluzioni, di 4-5 progetti ciascuno (Test, Business Layer, API, ecc.).

Ogni approccio ha i suoi vantaggi e svantaggi.

Una singola soluzione è molto utile quando si apportano modifiche: è più facile lavorare con le dipendenze e consente agli strumenti di refactoring di funzionare correttamente. Tuttavia, comporta tempi di caricamento più lunghi e tempi di costruzione più lunghi.

Più soluzioni possono aiutare a rafforzare la separazione dei problemi e mantenere bassi i tempi di compilazione/caricamento e possono essere adatti per avere più team con focus più ristretto e confini di servizio ben definiti. Tuttavia, hanno un grosso svantaggio quando si tratta di refactoring, dal momento che molti riferimenti sono file, non riferimenti di progetto.

Forse c'è spazio per un approccio ibrido utilizzare soluzioni più piccole per la maggior parte, ma creare un singolo che includa tutti i progetti per i tempi in cui sono necessarie modifiche su scala più ampia. Naturalmente, è necessario mantenere due soluzioni separate ...

Infine, la struttura dei progetti e delle dipendenze avrà una certa influenza su come organizzi le tue soluzioni.

E tenere a mente, nel lungo periodo la RAM è più economica del tempo del programmatore ...

Answer 11

Al momento di decidere quale numero di progetti vs soluzioni non è necessario, è necessario considerate questo alcune domande:

• strati logici della vostra applicazione;
• dipendenza tra progetti;
• come vengono costruiti i progetti;
• chi lavora con quali progetti;

Attualmente abbiamo 1 soluzione con 70 progetti. Per la nostra continua integrazione abbiamo creato 5 progetti msbuild, quindi CI non crea la nostra soluzione di sviluppo.

In precedenza, avevamo una soluzione separata per il livello di presentazione (web e progetti correlati) nel repository git separato. Questa soluzione è stata utilizzata da sviluppatori web esterni e freelance.