Applicazioni multiple in una singola soluzione di Visual Studio [chiuso]

17

Sto lavorando per un'azienda che vuole mettere insieme tutte le sue applicazioni .Net (applicazioni web, applicazioni Windows e applicazioni console) in un'unica soluzione di Visual Studio.

Sto cercando esperienza da sviluppatori che strutturano le proprie applicazioni in questo modo o che lavorano in un'azienda che fa questo. E 'questa una buona idea?

  • Quali sono i pro / contro per mettere tutte le tue applicazioni in un'unica soluzione piuttosto che avere soluzioni separate per ogni applicazione?

  • Quanto è veloce Visual Studio con una soluzione di oltre 20 progetti?

  • E quanto è stabile il file di soluzione con lo sviluppo concorrente controllato dalla sorgente?

posta BruceHill 27.09.2013 - 22:50
fonte

2 risposte

21

Recentemente, abbiamo migrato quasi tutto il codice sorgente della mia azienda in un'unica soluzione.

Perché?

Originariamente avevamo decine di soluzioni. Alcuni progetti di una soluzione hanno riutilizzato progetti da un altro e a nessuno importava l'utilizzo di un gestore di pacchetti. Il giorno in cui cambi sostanzialmente un progetto che viene utilizzato quasi ovunque, ti aspettano ore e ore di lavoro perso per l'intera azienda per i prossimi giorni o settimane. La parte peggiore è che non puoi nemmeno sapere quali sarebbero influenzati dal cambiamento.

L'unione di tutto il codice in un'unica soluzione era un'alternativa. Funziona bene per il momento, e le dipendenze sono ora facili da seguire. Vuoi modificare un metodo ma anche tenere traccia delle ripercussioni che questo cambiamento potrebbe avere in qualsiasi punto della base di codice? Visual Studio può farlo con facilità. Per me, è un successo.

L'integrazione continua ora è più facile. Una soluzione da compilare e distribuire. Quasi nulla da configurare.

È scalabile?

Per quanto riguarda le prestazioni, sono stato molto sorpreso da Visual Studio . Ho pensato che inizierà a piangere con una soluzione con, diciamo, 50 progetti. Oggi ci sono più di 200 progetti; Visual Studio sembrava essere abbastanza scalabile per gestirli come se ce ne fossero solo 20. Sì, ci sono cose che richiedono tempo. Se ricompilate ogni progetto, con i contratti di codice, l'analisi del codice abilitata di default, ecc., Aspettatevi che ci vorrà un po 'di tempo. Ma nessuno si aspetterebbe di compilare 200 progetti con una velocità di 10 e, a proposito, non si dovrebbe: questo è il ruolo del server di integrazione continua. Il tempo di avvio (avvio a freddo, quindi caricamento della soluzione) è molto veloce ; forse non così veloce come con 10 progetti, ma ancora molto accettabile (meno di 20 secondi su una macchina acquistata più di cinque anni fa).

Per andare ancora oltre, scaricare sistematicamente i progetti è una buona idea (e davvero facile quando i progetti sono organizzati nelle directory all'interno della soluzione). Se qualcuno lavora su qualcosa che richiede solo tre progetti da caricare, non è necessario caricare tutti i 200 progetti (a meno che, ovviamente, le dipendenze possano essere influenzate).

Il controllo della versione funziona come previsto pure (sto usando un server SVN, se è importante). Non ho lavorato in un reale ambiente concorrente, con, diciamo, dozzine di sviluppatori che commettono frequentemente codice, ma immagino che questo non avrebbe troppi problemi. Fai attenzione ai casi in cui molti sviluppatori aggiungono nuovi progetti allo stesso tempo: unire il file .sln non è la cosa più facile da fare.

Conclusione

Se dovessi prendere nuovamente la decisione:

  1. Continuerò a migrare tutto in un'unica soluzione. Questo riduce enormemente il dolore delle dipendenze spezzate, e solo questo beneficio ne vale la pena. Avere un posto centralizzato per tutto il codice è anche una buona idea; ciò rende possibile, ad esempio, cercare qualcosa all'interno di Visual Studio. Posso anche lavorare su due progetti debolmente correlati e avere ancora una sola finestra di Visual Studio aperta.

  2. Vorrei anche studiare un po 'di più NuGet e la possibilità di ospitare un server NuGet privato. La gestione delle dipendenze tramite NuGet può risolvere alcuni dei problemi quando non si desidera unire alcuni progetti nella soluzione comune. Personalmente, non ho avuto casi del genere, ma immagino che potrebbero avere altre società.

  3. Infine, investire in un SSD per ogni sviluppatore può fare una grande differenza. Ma non è necessario, e nel mio caso, il codice base è ancora memorizzato su un normale disco rigido.

risposta data 27.09.2013 - 23:43
fonte
8

Questo è l'utilizzo previsto.

What are the pro's/con's to putting all your applications in a single solution rather than having separate solutions for each application?

  • Pro:
    • riferimenti più facili tra i progetti
    • più facile debug / passaggio attraverso
    • più facile da collegare ai processi (ad esempio, stai passando attraverso un servizio Windows, quando salta al codice della libreria condivisa, e funziona solo perché tutti i simboli sono già caricati e contabilizzati)
    • la ricerca del codice all'interno dell' ide funziona meglio (non devi necessariamente sapere in quale progetto si trova il codice che stai cercando)
    • i changelists di più progetti sono più facili da gestire (ovvero hai modificato il codice della libreria, quindi devi aggiornare il codice client contemporaneamente, con 1 controllo)
  • contro:
    • velocità di costruzione: se hai l'abitudine di "ricostruire tutto", le build richiedono più tempo. Molto più lunghe e le build incrementali a volte hanno un comportamento funky.
    • ide speed: vedi il prossimo

How fast is Visual Studio with a solution of 20+ projects?

Con oltre 20 progetti ... potrebbe non essere così male. Ho visto di più senza VS avendo problemi. È abbastanza stabile / veloce. TUTTAVIA ... se è un problema, può essere mitigato: apri il .csproj in VS e lavora da lì. Non hai i vantaggi di avere tutto in un'unica soluzione, ma puoi sempre riaprire la sln quando ne hai bisogno e lavorare nel .csproj quando necessario (come fai ora).

And how stable is the solution file with source-controlled concurrent development?

Il file della soluzione cambia solo quando aggiungi / rimuovi progetti o oggetti a livello di soluzione, quindi raramente cambia. È xml, quindi puoi vedere cosa c'è dentro. Cambiano raramente.

    
risposta data 28.09.2013 - 00:27
fonte

Leggi altre domande sui tag