Un progetto di Visual Studio dovrebbe essere contenuto in più di una soluzione?

Question

Nota: questo è per un negozio che funziona in C++, C++/CLI e C# con alcuni prodotti forniti come una combinazione di tutti e tre.

Attualmente abbiamo una regola per cui un progetto dovrebbe avere una sola soluzione contenente. La regola è stata originariamente creata perché il plug-in del controllo del codice sorgente per Visual Studio non è stato in grado di gestire i progetti contenuti in più soluzioni, tentando sempre di modificare i collegamenti del controllo origine quando si passa da una soluzione all'altra.

Per altre ragioni, smetteremo di utilizzare il plug-in del controllo sorgente del tutto (non lasciando cadere il controllo della fonte, solo il plug-in senza cervello). Riafinisce la questione se continuare o meno la politica di restrizione dei progetti da contenere in un'unica soluzione.

Abbiamo un bel po 'di codice in librerie, DLL e assiemi che sono consumati da più prodotti consegnabili, e attualmente lo controlliamo con un sistema di gestione delle dipendenze tra soluzioni in cui, se si sta lavorando nella soluzione per un prodotto finale, è semplice richiedere una build delle soluzioni di dipendenza, che dà il via ad altre istanze di Visual Studio per costruirle. Il sistema funziona, ma ha i seguenti inconvenienti:

• le soluzioni per i progetti comuni sono spesso troppo grasso, che contiene alcuni progetti necessari per il prodotto che viene attualmente sviluppato e di solito molto di più che non sono necessari per la sviluppo di lavoro a portata di mano. Sono stati semplicemente accorpati in una sorta di soluzione catch-all che copre progetti che sono semplicemente imparentati. Ciò si traduce in tempi di compilazione estesi a causa della compilazione del codice non necessario.
• Nei casi in cui abbiamo tentato di risolvere le suddette soluzioni di grasso, spesso ci ritroviamo con una soluzione troppo sottile che contiene un solo progetto. Ognuno di questi richiede una configurazione aggiuntiva nel sistema di gestione delle dipendenze tra soluzioni. Anche questo può aumentare i tempi di costruzione man mano che vengono moltiplicate più istanze di Visual Studio.

Sto considerando di rivedere la politica per consentire a un progetto utilizzato in più prodotti consegnabili di essere contenuto in più di una soluzione. Potremmo eliminare la gestione delle dipendenze tra soluzioni e ridurre drasticamente il numero di soluzioni (fino a uno per prodotto). Sono preoccupato per la quantità di lavoro che questa riorganizzazione prenderà e se ne varrà la pena o no. Temo di non essere nemmeno in grado di rilevare i potenziali benefici finché il team non lavorerà per un po '. Prevedo anche un paio di potenziali problemi che sono le vere domande qui.

• Un numero elevato di progetti in un'unica soluzione pone problemi di stabilità in Visual Studio 2005 (la nostra attuale piattaforma di sviluppo)? Va meglio in VS 2008 o VS 2010?
• Se un progetto è contenuto in più di una soluzione, come è possibile gestire gli effetti su più soluzioni se le configurazioni del progetto devono essere modificate (come l'aggiunta di una nuova configurazione)?

A chiunque stia già lavorando in un ambiente con una soluzione per prodotto consegnabile, con componenti comuni come progetti contenuti in più soluzioni: Hai riscontrato qualche svantaggio significativo a tale configurazione?

Answer 1

No, utilizzare tutte le soluzioni che è conveniente.

Ad esempio, abbiamo una soluzione di grandi dimensioni che costruisce circa 53 progetti.Include un programma di installazione e un programma di disinstallazione in modo che possano essere compilati comodamente dal nostro server di build, ma se voglio lavorare su tali applicazioni, li carico nelle loro soluzioni (1 progetto ciascuno), invece di stare tutto il tempo caricando 69 altro progetti inutili. Non hanno alcuna dipendenza dagli altri progetti, quindi non c'è alcun problema a farlo in questo modo (anzi, è molto più efficiente in quanto la soluzione carica e costruisce molto più velocemente)

L'unica avvertenza di più soluzioni è che devi stare attento in ogni caso in cui non crei una dipendenza (ad esempio se non costruisci una libreria, allora devi fare attenzione che venga creata ogni volta che cambia il codice sorgente, perché non lo farà più essere costruita automaticamente per voi)

modificare

per rispondere l'ultima parte della tua domanda (perché SO prende la questione di distanza, mentre you'r e modificando la risposta!), l'unico problema con Solutions in VS2005 è che è molto lento con molti progetti in loro. VS2008 è molto più veloce al caricamento di una soluzione di grandi dimensioni, ma il principale risultato è che più progetti ci sono in una soluzione, più tempo ci vuole per costruire (anche se si tratta semplicemente di saltare i progetti che non devono essere costruiti , ci vuole molto tempo)

Se si aggiunge una nuova configurazione di soluzione, quindi basta creare una soluzione uber (o semplicemente mantenere quella esistente!) e quindi apportare le modifiche in modo che vengano applicate a tutte le porzioni in un colpo solo. Dovrai comunque aggiungere la nuova configurazione a qualsiasi soluzione separata che desideri utilizzare, ma se si tratta di soluzioni a un solo progetto, puoi semplicemente eliminarle, caricare il .csproj e verrà ricostruito automaticamente con tutte le configurazioni esso. E aggiungere nuove configurazioni probabilmente non succederà molto spesso.

Answer 2

Anch'io lavoro in un ambiente che ha molti progetti comuni che vengono utilizzati in diversi deliverable. La nostra politica è stata una soluzione per applicazione consegnabile. Quindi un progetto comune può essere incluso in diverse soluzioni. Questo ha funzionato bene per noi. I progetti comuni, pur contenuti in soluzioni separate, si collegano tutti allo stesso repository del codice sorgente. Quindi, se il codice comune viene modificato, tutte le applicazioni che contengono sono interessate (il nostro sistema di integrazione continua) serve come controllo che le altre applicazioni non si rompono a seguito della modifica al codice comune.

Più progetti hai in una soluzione VS, più tempo ci vuole per caricare e sembra complicato dover gestire diverse configurazioni di build e dipendenze in un'unica soluzione.

Answer 3

I principali problemi con avere un progetto in diverse soluzioni sono:

• Se si effettua una modifica al progetto, può causare un errore di compilazione in un'altra soluzione in cui viene utilizzato.
• Le soluzioni devono essere costantemente aggiornati per tenere il passo con i cambiamenti nei progetti comuni

Il vantaggio di avere un progetto in ogni soluzione che viene utilizzata è:

• E 'più facile eseguire il debug quando è possibile seguire il problema relativo al codice souce.

Un altro modo per farlo sarebbe quello di fare in modo che ogni soluzione utilizzi le dll dei progetti comuni di cui hanno bisogno. Quindi ogni soluzione può decidere quando vogliono cambiare la versione che usano.

Il numero di progetti in una soluzione non è un problema grave. Ma renderà più lento caricare e costruire la soluzione. Abbiamo soluzioni di oltre 50 progetti.

Answer 4

Abbiamo una "soluzione principale" che contiene oltre 100 progetti. Ciò ha richiesto per sempre un caricamento in VS.2005 fino a quando Microsoft ha rilasciato le correzioni Intellisense descritte here.

La nostra procedura di compilazione automatica "integrazione continua" crea sempre la soluzione principale. Per lo sviluppo, divido la "soluzione principale" in soluzioni più piccole che contengono un sottoinsieme di progetti correlati. Mantenere questa struttura richiede del tempo quando vengono aggiunti nuovi progetti, ma ne vale la pena.

L'unico problema che ho scoperto con i progetti in più soluzioni è evitato usando $ (ProjectDir) invece di $ (SolutionDir) nelle regole di compilazione, poiché quest'ultimo dipende da come viene caricato il progetto.

Answer 5

Tools for SLN file (Visual Studio Solution file) contiene uno strumento che:

permettono di creare filtri per un file SLN. Il modo in cui funziona è che quando viene aperto il file del filtro, viene creata una soluzione temporanea in modo dinamico. Il file di soluzione creato contiene solo i progetti specificati nel filtro e tutte le dipendenze di tali progetti . Ciò rende possibile avere una mega-soluzione che contiene tutti i progetti necessari per costruire il sistema completo ma ha ancora la possibilità di lavorare in modo efficiente su un sottoinsieme del sistema.

Questo rimuove gran parte del costo di mantenimento dei file di soluzioni di sub-set per la velocità di sviluppo.

Tuttavia è necessario chiedersi se si dispone di più file di progetto, quindi è necessario, in quanto la combinazione di file di progetto può accelerare notevolmente la compilazione e il caricamento delle soluzioni.

Answer 6

C'è ora un'estensione per Visual Studio gratuita, "Funnel", che risolve questo problema caricando sottoinsiemi predefiniti della soluzione. Il collegamento è per VS2012-VS2015; c'è anche una versione VS2010 a cui si fa riferimento nella home page dell'estensione.

È possibile impostare più profili (ad esempio combinazioni di progetto). Questi sono memorizzati in un file parallelo solution.sln.vsext e tale file può essere impegnato e condiviso con il tuo team. Mentre VS2015 è diventato molto più efficace nella gestione di grandi, oltre 100 soluzioni di progetto C/C++/C#, lo trovo particolarmente utile per escludere i progetti makefile che vengono creati ogni volta che viene creata la soluzione.