La cartella .nuget dovrebbe essere aggiunta al controllo di versione?

Question

Con le versioni più recenti di NuGet è possibile configurare un progetto per ripristinare automaticamente i pacchetti NuGet in modo che la cartella packages non debba essere inclusa nel repository del codice sorgente. Buona.

Tuttavia, questo comando aggiunge una nuova cartella .nuget e vi è un file binario, NuGet.exe. Questo può anche essere ricreato automaticamente da Visual Studio e quindi non sembra corretto aggiungerlo al controllo di versione. Tuttavia, senza questa cartella, Visual Studio non caricherà nemmeno correttamente la soluzione.

Come ci si occupa di questo? Aggiungi .nuget al controllo del codice sorgente? Esegui qualche script da riga di comando prima di aprire la soluzione?

Answer 1

Questo post è obsoleto, non è più necessario utilizzare il ripristino del pacchetto NuGet a livello di soluzione. Dalla versione 2.7+ è disponibile un'opzione nell'installazione di NuGet per ripristinare automaticamente i pacchetti durante la compilazione. Quindi la cartella .nuget può essere cancellata e l'opzione rimossa dai tuoi progetti.

http://docs.nuget.org/docs/reference/package-restore

UPDATE: Con il rilascio di NuGet 4.xe .NET standard 2.0, quando si utilizza il nuovo formato csproj ora è possibile utilizzare i riferimenti del pacchetto, per ironia della sorte reintrodurre la dipendenza da MSBuild per ripristinare pacchetti , ma ora i pacchetti sono cittadini di prima classe di msbuild. Il link qui sopra fa anche menzione del PackageReference, ma i dettagli il seguente annuncio meglio:

https://blog.nuget.org/20170316/NuGet-now-fully-integrated-into-MSBuild.html

E l'annuncio 4.x RTM NuGet, che ironicamente non è così utile:

https://blog.nuget.org/20170308/Announcing-NuGet-4.0-RTM.html

UPDATE 2: Apparentemente con VS2017 è anche possibile utilizzare i riferimenti ai pacchetti con i progetti csproj classici, ma non sono più compatibili con le versioni precedenti, e ci sono stati alcuni problemi con il ripristino di PA sottodipendenze ckage. Sono sicuro che tutto sarà risolto.

Answer 2

Anche se di solito non mi piace l'idea di aggiungere exe al controllo del codice sorgente, suggerirei che il controllo del codice sorgente dovrebbe contenere tutto ciò che è necessario per aprire, creare ed eseguire il progetto.

In questo caso, sembra che la cartella .nuget sia una dipendenza richiesta. Pertanto dovrebbe essere sotto il controllo del codice sorgente.

L'unica domanda a sinistra, che è necessario per la ricerca, è come NuGet sta andando a reagire nel caso che la cartella è contrassegnata di sola lettura, che TFS farà una volta che è stato controllato in.

---

Aggiornamento: Ho fatto un po 'più di ricerche su questo come non ho mai usato NuGet prima. http://blog.davidebbo.com/2011/03/using-nuget-without-committing-packages.html

Suggerirei che probabilmente ciò che si vuole fare è rendere NuGet un requisito che deve essere installato su ogni workstation degli sviluppatori.

Inoltre, è necessario inserire nel controllo sorgente il file batch necessario per ottenere una workstation pronta per iniziare a modificare il progetto. Il file batch eseguirà i comandi necessari per ottenere e installare i pacchetti di dipendenze.

Oltre a ciò, direi che potresti voler contattare direttamente NuGet per chiedere loro come, esattamente, questo dovrebbe funzionare.

Answer 3

Secondo this thread, la cartella .nuget deve essere controllata dalla versione.

Answer 4

Ora che nuget supporta il ripristino del pacchetto, lo stiamo osservando più da vicino.

Usiamo Subversion per il controllo del codice sorgente e le mie considerazioni iniziali sono che .nuget deve essere aggiunto al nostro repository, ma aggiunto utilizzando svn:externals in modo che punti a una singola posizione.

In questo modo possiamo distribuire automaticamente nuove versioni a tutti gli sviluppatori e i progetti. Per i progetti sui rami di rilascio, anziché HEAD, possiamo specificare la revisione di svn: riferimenti esterni se vogliamo lasciare solo il nuget.

Abbiamo molti progetti, quindi significa anche non duplicare nuget.exe più volte nel repository.

Answer 5

È necessario eseguire il commit .nuget\nuget.targets, ma non nuget.exe. Gli obiettivi scaricheranno l'exe se non esiste, purché si modifichi DownloadNuGetExe in true in nuget.target

Answer 6

@Richard La risposta di Szalay è corretta: non è necessario eseguire il commit di nuget.exe. Se per qualche motivo Visual Studio non scarica automaticamente il nuget.exe, assicurarsi di avere la seguente serie di vero nel file nuget.targets:

<!-- Download NuGet.exe if it does not already exist --> 
<DownloadNuGetExe Condition=" '$(DownloadNuGetExe)' == '' ">true</DownloadNuGetExe> 

chiudere la soluzione VS, riaprirlo e costruirlo. Visual Studio dovrebbe scaricare automaticamente nuget.exe ora.

Answer 7

Abbiamo il file nuget.config nella cartella, in quanto ha i riferimenti al nostro server interno Nuget, utilizzando l'area le fonti di pacchetti: https://docs.nuget.org/consume/nuget-config-settings

Oltre a questo motivo, si dovrebbe lasciare che Visual Studio gestisce il download di Pacchetti.