Come utilizzare correttamente NuGet con lo sviluppo del team?

Question

Quindi vorrei utilizzare NuGet per gestire i vari progetti che utilizzo per uno specifico progetto su cui io e il mio team stiamo lavorando. Fino a questo punto, ho inserito i miei file della libreria .js nella directory/Scripts della mia soluzione web (ASP.NET MVC 2) e li ho citati. Naturalmente, questo era manuale ed era fastidioso da gestire durante gli aggiornamenti, ecc.

Ora che utilizzo NuGet, mi rendo conto che l'obiettivo di NuGet è quello di renderlo abbastanza indolore. Inoltre, sembra che non dovrei controllare i miei pacchetti nel mio repository (AKA non ho più bisogno di gestire le mie librerie esterne). Tuttavia, quando apro jQuery (ad esempio) da NuGet, posiziona i suoi file specifici nella directory/Scripts del mio progetto.

Dove mi confondo - cosa, se non altro, dovrei controllare il controllo del codice sorgente a questo punto? Continuo a controllare nella directory/Scripts?

Inoltre, se qualcun altro sta lavorando a questo progetto e controlla la soluzione dal controllo del codice sorgente, i pacchetti vengono scaricati automaticamente (supponendo che la soluzione sia fornita con un pacchetto packages.config valido)?

Sto solo cercando di chiarire un paio di punti prima di iniziare a utilizzare NuGet a tempo pieno.

Answer 1

Ci sono due scenari per NuGet vs VCS: per effettuare il check-in o non per il check-in, questa è la domanda. Entrambi sono validi a mio avviso, ma quando si utilizza TFS come VCS, sceglierei uno no-checkin policy for NuGet packages.

Detto questo, anche quando si utilizza un criterio di non-controllo per i pacchetti NuGet, continuerei a controllare le modifiche del contenuto che quei pacchetti NuGet hanno fatto ai miei progetti. La cartella \Scripts verrebbe archiviata nella sua interezza (non selettiva, non ignorata).

Il criterio di non-controllo per i pacchetti per me significa: non controllare nella cartella \ Packages (cloak it, ignorarlo), ad eccezione del file \Packages\repositories.config.

Come tale, non si sta commettendo alcun pacchetto NuGet e quando si utilizza Enable-PackageRestore da NuGetPowerTools (questo sarà integrato in NuGet v1.6 proprio dietro l'angolo), qualsiasi macchina che controlla il codice e le build, recupererà tutte le dipendenze di NuGet richieste in una fase di pre-build. Questo vale sia per le macchine di sviluppo locali che per i server di compilazione, purché nella soluzione sia disponibile Enable-PackageRestore e punti ai repository NuGet corretti (locale, interno, esterno).

Se ci pensate, quando installate un pacchetto NuGet che aggiunge solo riferimenti ad alcuni file binari, stavate già eseguendo il samething in uno scenario di non-check-in: non avreste commesso le sottocartelle della cartella \Packages, ma ancora, dovresti commettere le modifiche al progetto (il riferimento aggiunto).

Direi, essere coerente (per qualsiasi tipo di pacchetto), se contiene solo file binari, solo contenuto o un mix. Do not commit the packages themselves, commetti le modifiche alle tue fonti. (se solo per evitare il fastidio di cercare ciò che è cambiato dal punto di vista dei contenuti)

Answer 2

NuGet, come Nexus, sono repository di risorse (l'artefice è qualsiasi tipo di deliverable, incluso il binario potenzialmente di grandi dimensioni).

L'effetto collaterale è per voi di non memorizzare in un VCS (Version Control System) elementi che:

• non potrebbero trarre vantaggio da funzionalità VCS (ramificazione, la fusione)
• aumenterebbe significativamente la dimensione del repository VCS (senza delta o triangolo debole di stoccaggio)
• sarebbe molto difficile da rimuovere da un repository VCS (progettato principalmente per mantenere storia)

Ma l'obiettivo è per voi di dichiarare quello che vi serve (e lasciare NuGet recuperare per voi), invece di memorizzare da soli.
Quindi è possibile utilizzare la versione /Scripts come segnaposto, ma non è più necessario scaricare versioni del suo contenuto ora recuperate automaticamente.