Quali file di progetto ASP.NET MVC devono essere conservati in un repository?

Question

background: Io e i miei colleghi stiamo lavorando al progetto asp.net mvc ... abbiamo un computer che funziona come un server su cui è archiviato il progetto ... ognuno di noi ha una copia del progetto e abbiamo messo insieme le tartarughe.

domande: quando si vuole commettere qualcosa, quali file si impegnano esattamente? .. asp.net segnala molti file dll, file csproj, file cs e sln che sembrano essere diversi da quelli del server.

Forse la mia domanda non è quella giusta che dovrei chiedere quindi vorrei apprezzare qualche idea su cosa sia l'approccio migliore per lavorare in gruppo.

Answer 1

Il file csproj di base dovrebbe essere impegnata ogni volta che si aggiungono o rimuovono le cose dal progetto, al fine di garantire che il progetto ha tutti i file corretti. La soluzione (sln) è buona per il commit, per lo stesso motivo, anche se l'ho vista anche senza. Dovresti anche impegnare qualsiasi file CS, naturalmente, dato che sono l'obiettivo principale delle cose.

I file DLL devono essere impegnati solo se sono esterni ai riferimenti: le DLL interne al progetto possono essere ignorate, in quanto verranno create da ciascun computer a turno. Inoltre, si desidera evitare file .user inutili. Ignora le cartelle 'bin' e 'obj' per ogni directory, quando si tratta di commit anche.

Answer 2

In realtà non è necessario controllare tutto ciò che il progetto può generare da solo. Quindi non c'è bisogno di controllare nella cartella bin o obj o qualcosa del genere, si vuole anche ignorare qualsiasi file delle preferenze dell'utente.

Questo include DLL, a meno che siano dll di terze parti, quindi si desidera verificarle per assicurarsi che tutti stiano lavorando contro la stessa versione e in questo modo non è necessario continuare a modificare i percorsi di riferimento.

Answer 3

Manteniamo tutto tranne le cartelle BIN/OBJ in SVN. Abbiamo tutte le librerie di terze parti in una cartella separata dalla quale fanno riferimento.

Gentilezza,

Dan

Answer 4

Non lavoro in asp.net, quindi risponderò genericamente. Abbiamo un repository di codice di sovversione per il nostro sistema di versioni, anche cvs funziona bene. Gli sviluppatori recuperano tutto il codice aggiornato dal repository, funzionano, si assicurano che funzioni correttamente, ne facciano un altro, ricompilino, eseguano test e quindi eseguano il commit delle modifiche al codice sorgente nel repository. Su base regolare è possibile avere uno strumento o creare manualmente l'applicazione dal repository e distribuirla su un server di prova. Nessun codice compilato deve essere inserito nel repository.

-Jay

Answer 5

Usiamo la seguente struttura di progetto in SVN (ma questo vale per CVS pure).

+ tags 
+ branches 
> trunk 
    + build (build scripts) 
    + lib (external libraries) 
    > src (source code)  
    >> Organization.App (solution name) 
    >> Organization.App.Core (code library) 
     + Config 
     > Domain 
      > Model 
      > Persistence 
      > Queries 
      > Services 
     > Persistence 
     > Services 
    >> Organization.App.Web (mvc web app) 
     > Assets 
      + Images 
      + Scripts 
      + Stylesheets 
     + Controllers 
     + Views 
     + ViewModels 

Abbiamo inserito tutte le nostre dipendenze di terze parti nella cartella lib. Compreso MVC, che può essere distribuito in bin. See this article by Phil Haack. Quindi, quando un nuovo sviluppatore arriva online, tutto ciò che devono fare è controllare il bagagliaio, e dovrebbero avere tutto ciò di cui hanno bisogno per andare avanti. L'utilizzo di un server CI è un gioco da ragazzi perché tutte le dipendenze dei progetti sono incapsulate dalla cartella lib e tutti i progetti di Visual Studio fanno riferimento a quelle DLL in quella cartella lib.

Ha senso?

Non importa la cartella principale e la cartella web. È così che strutturiamo i nostri progetti all'interno della soluzione. Ma questo è un whole other conversation. :)

Answer 6

Se si utilizza uno strumento di gestione delle modifiche del database, come ad esempio Tarantino, sarà inoltre necessario archiviare gli script di modifica SQL e/o compilare gli script. Abbiamo una cartella nella nostra soluzione 'Core' dove conserviamo questi, ovvero 'Core/Database/Updates'. Usiamo SQL Compare per trovare le modifiche nel nostro database, quindi controlliamo gli script di modifica SQL in modo che altri sviluppatori possano semplicemente eseguirli localmente. Abbiamo una configurazione nant task per chiamare su Tarantino per sincronizzare gli altri ambienti di compilazione (Dev, QA) ed eseguire qualsiasi nuovo script di modifica.