¿Debería agregarse la carpeta .nuget al control de versiones?

Con las versiones más recientes de NuGet, es posible configurar un proyecto para restaurar automáticamente los paquetes de NuGet de modo que la packagescarpeta no tenga que incluirse en el repositorio de código fuente. Bueno.

Sin embargo, este comando agrega una nueva .nugetcarpeta y hay un binario allí, NuGet.exe. Visual Studio también puede volver a crearlo automáticamente, por lo que no parece correcto agregarlo al control de versiones. Sin embargo, sin esta carpeta, Visual Studio ni siquiera cargará la solución correctamente.

¿Cómo lidian ustedes con esto? ¿Agregar .nuget al control de fuente? ¿Ejecuta algún script de línea de comando antes de abrir la solución?

Esta publicación es antigua, ya no debería usar la restauración del paquete NuGet a nivel de solución. A partir de la versión 2.7+, existe una opción en la configuración de NuGet para restaurar automáticamente los paquetes en la compilación. Entonces, la carpeta .nuget se puede eliminar y la opción eliminar de sus proyectos.

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

ACTUALIZACIÓN: con el lanzamiento de NuGet 4.xy .NET Standard 2.0, cuando usa el nuevo formato csproj ahora puede usar referencias de paquetes, lo que irónicamente reintroduce la dependencia en msbuild para restaurar paquetes, pero ahora los paquetes son un ciudadano de primera clase de msbuild . El enlace anterior también menciona el PackageReference, pero el siguiente anuncio lo detalla mejor:

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

Y el anuncio de NuGet 4.x RTM, que irónicamente no es tan útil:

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

ACTUALIZACIÓN 2: Aparentemente, con VS2017 incluso puede usar referencias de paquetes con proyectos clásicos de csproj, pero ya no son compatibles con versiones anteriores y ha habido algunos problemas con la restauración de las subdependencias de paquetes. Estoy seguro de que todo se resolverá.

La respuesta de @Richard Szalay es correcta: no es necesario que confirme nuget.exe. Si, por alguna razón, Visual Studio no descarga automáticamente nuget.exe, asegúrese de tener lo siguiente establecido en verdadero en el nuget.targetsarchivo:

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

Cierre la solución VS, vuelva a abrirla y compile. Visual Studio debería descargar nuget.exe automáticamente ahora.

Según este hilo , la carpeta .nuget debe estar controlada por versión.

Necesitas comprometerte .nuget\nuget.targets, pero no nuget.exe. Los destinos descargarán el archivo ejecutable si no existe, siempre que cambie DownloadNuGetExea trueen nuget.targets

Aunque por lo general no me gusta la idea de agregar archivos ejecutables al control de código fuente, sugeriría que el control de código fuente debería contener todo lo necesario para abrir, construir y ejecutar el proyecto.

En este caso, parece que la carpeta .nuget es una dependencia necesaria. Por lo tanto, debería estar bajo control de fuente.

La única pregunta que queda, que necesita investigar, es cómo reaccionará NuGet si esa carpeta está marcada como de solo lectura, lo que hará TFS una vez que se haya registrado.

Actualización: Investigué un poco más sobre esto, ya que nunca antes había usado NuGet. http://blog.davidebbo.com/2011/03/using-nuget-without-committing-packages.html

Sugeriría que probablemente lo que quiera hacer es convertir NuGet en un requisito que debe instalarse en todas las estaciones de trabajo de los desarrolladores.

Además, debe colocar en control de código fuente el archivo por lotes necesario para que una estación de trabajo esté lista para comenzar a editar el proyecto. El archivo por lotes ejecutará los comandos necesarios para obtener e instalar los paquetes de dependencia.

Más allá de eso, diría que es posible que desee ponerse en contacto con NuGet directamente para preguntarles cómo, exactamente, se supone que funciona esto.

Ahora que nuget admite la restauración de paquetes, lo estamos analizando más de cerca.

Usamos Subversion para el control de fuentes, y mis pensamientos iniciales son que .nugetdebería agregarse a nuestro repositorio, pero agregarlo usando svn: externals para que apunte a una sola ubicación.

De esa manera, podemos enviar automáticamente nuevas versiones a todos los desarrolladores y proyectos. Para proyectos en ramas de lanzamiento, en lugar de HEAD, podemos especificar la revisión de svn: referencia externa si queremos dejar nuget solo.

Tenemos muchos proyectos, por lo que también significa no duplicar nuget.exevarias veces en el repositorio.

Tenemos el nuget.configarchivo en la carpeta, ya que tiene las referencias a nuestro servidor interno de Nuget, usando el área de fuentes del paquete: https://docs.nuget.org/consume/nuget-config-settings

Aparte de esta razón, debe dejar que Visual Studio se encargue de la descarga de paquetes.