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

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

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

Come affrontate questo problema? Aggiungere .nuget al controllo del codice sorgente? Eseguire uno script della riga di comando prima di aprire la soluzione?

Questo post è vecchio, non dovresti più usare il ripristino del pacchetto NuGet a livello di soluzione. A partire 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 eliminata e l'opzione rimossa dai tuoi progetti.

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

AGGIORNAMENTO: con il rilascio di NuGet 4.xe .NET Standard 2.0, quando si utilizza il nuovo formato csproj è ora possibile utilizzare i riferimenti ai pacchetti, reintroducendo ironicamente la dipendenza da msbuild per ripristinare i pacchetti, ma ora i pacchetti sono un cittadino di prima classe di msbuild . Il link sopra menziona anche il PackageReference, ma il seguente annuncio lo descrive meglio:

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

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

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

AGGIORNAMENTO 2: A quanto pare con VS2017 puoi persino usare i riferimenti ai pacchetti con i classici progetti csproj, ma non sono più compatibili con le versioni precedenti e ci sono stati alcuni problemi con il ripristino delle sottodipendenze dei pacchetti. Sono sicuro che sarà tutto risolto.

La risposta di @Richard Szalay è giusta: non è necessario eseguire il commit di nuget.exe. Se per qualche motivo Visual Studio non scarica automaticamente nuget.exe, assicurati di avere il seguente impostato su true nel nuget.targetsfile:

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

Chiudere la soluzione VS, riaprirla e compilarla. Visual Studio dovrebbe scaricare automaticamente nuget.exe ora.

Secondo questo thread , la cartella .nuget dovrebbe essere controllata dalla versione.

Devi impegnarti .nuget\nuget.targets, ma non nuget.exe. Le destinazioni scaricheranno l'exe se non esiste, a condizione che si passi DownloadNuGetExea truein nuget.targets

Sebbene di solito non mi piaccia l'idea di aggiungere exe al controllo del codice sorgente, suggerirei che il controllo del codice sorgente contenga 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 rimasta, che devi cercare, è come reagirà NuGet se quella cartella è contrassegnata come di sola lettura, cosa che TFS farà una volta che è stata archiviata.

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

Suggerirei che probabilmente quello che vuoi fare è rendere NuGet un requisito che deve essere installato su ogni workstation degli sviluppatori.

Inoltre, è necessario inserire nel controllo del codice sorgente il file batch necessario per preparare una workstation 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, dovrebbe funzionare.

Ora che nuget supporta il ripristino dei pacchetti, lo stiamo esaminando più da vicino.

Usiamo Subversion per il controllo del codice sorgente e il mio pensiero iniziale è che .nugetdovrebbe essere aggiunto al nostro repository, ma aggiunto usando svn: externals in modo che punti a una singola posizione.

In questo modo possiamo distribuire automaticamente nuove versioni a tutti gli sviluppatori e progetti. Per i progetti sui rami di rilascio, piuttosto che su HEAD, possiamo specificare la revisione di svn: externals reference se vogliamo lasciare in pace nuget.

Abbiamo molti progetti, quindi significa anche non duplicare nuget.exepiù volte nel repo.

Abbiamo il nuget.configfile nella cartella, in quanto contiene i riferimenti al nostro server Nuget interno, utilizzando l'area Package Sources: https://docs.nuget.org/consume/nuget-config-settings

Oltre a questo motivo, dovresti lasciare che Visual Studio gestisca il download dei pacchetti.