Best Practice:Ambiente collaborativo, Bin, SVN

Question

Quali sono le migliori pratiche per il check-in BIN directory in un ambiente di sviluppo collaborativo utilizzando SVN?Dovrebbe a livello di progetto riferimenti di essere esclusi dal checkin?È più semplice basta aggiungere tutti i bin directory?

Ho sviluppato un sacco di DotNetNuke siti e sembra che, in un multi-ambiente di sviluppo, è sempre un compito enorme per ottenere l'installazione dell'ambiente correttamente.

L'obiettivo finale, naturalmente, è quello di avere un nuovo sviluppatore di checkout il tronco da SVN, ripristinare il DNN database e hanno tutti solo di "lavoro"...

Answer 1

Eventuali assemblee che dovrebbero essere il GAC deve rimanere nella GAC.Questo include System.web.dll o qualsiasi altro 3rd party dll che ti distribuire alla GAC in produzione.Questo significa un nuovo sviluppatore dovrebbe installare queste assemblee.

Tutti gli altri 3rd party assemblee riferimenti attraverso un percorso relativo.La mia struttura tipica è:

-Project
--Project.sln
--References
---StructureMap.dll
---NUnit.dll
---System.Web.Mvc.dll
--Project.Web
---Project.Web.Proj
---Project.Web.Proj files
--Project
---Project.Proj
---Project.Proj files

Progetto.Web di Progetto e di riferimento per gli assembly nella root/cartella Riferimenti relativamente.Questi .le dll sono verificati in subversion.

A parte questo, */bin */bin/* obj dovrebbe essere globale ignorare percorso.

Con questa impostazione, tutti i riferimenti agli assembly sono sia attraverso il GAC (così dovrebbe funzionare su tutti i computer), relative a ciascun progetto all'interno di una soluzione.

Answer 2

È questo un .Netto domanda specifica?

Generalmente la pratica migliore è di non controllare in qualsiasi cosa che viene creata automaticamente dal file che sono già in SCM.Tutto ciò è idealmente creato come parte del processo di generazione automatica.

Se il bin directory ti stai riferendo contiene terze parti binari, piuttosto che una build del progetto, ignorare (downvote?) questo consiglio.

Answer 3

Albero Chirurgo è un grande strumento che crea un vuoto .NET albero di sviluppo.È stato messo a punto, negli anni di uso e implementa un sacco di buone pratiche.

Answer 4

Maven aiuta molto con questo problema quando sto codifica java.Noi commettiamo l'pom.xml a scs e il repository maven contiene tutte le nostre dipendenze.Per me che mi sembra un bel modo per farlo.

Answer 5

Seguiamo la pratica di utilizzare un fornitore di directory che contiene tutte le specifiche del fornitore intestazioni e i binari.L'obiettivo è che chiunque dovrebbe essere in grado di costruire il prodotto solo controllando fuori e in esecuzione di un certo livello di script di build.