¿Debería agregarse la carpeta .nuget al control de versión?

Question

Con las versiones más nuevas de NuGet, es posible configurar un proyecto para restaurar automáticamente los paquetes NuGet para que la carpeta packages no necesite ser incluida en el repositorio de código fuente. Bueno.

Sin embargo, este comando agrega una nueva carpeta .nuget y allí hay un archivo binario, NuGet.exe. Esto también puede ser recreado automáticamente por Visual Studio y no se considera correcto agregar eso al control de versiones. Sin embargo, sin esta carpeta, Visual Studio ni siquiera cargará la solución correctamente.

¿Cómo pueden lidiar con esto? Añadir .nuget al control de fuente? ¿Ejecuta algún script de línea de comando antes de abrir la solución?

Answer 1

Esta publicación es antigua, ya no deberías volver a utilizar el paquete de solución NuGet restore. A partir de la versión 2.7+ hay una opción en la configuración NuGet para restaurar automáticamente los paquetes en la compilación. Así que la carpeta .nuget se puede eliminar y la opción eliminada de sus proyectos.

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

ACTUALIZACIÓN: Con el lanzamiento de NuGet 4.x y .NET 2.0 estándar, cuando se utiliza el nuevo formato csproj ahora se puede utilizar referencias de paquetes, irónicamente, la reintroducción de la dependencia de msbuild para restaurar paquetes , pero ahora los paquetes son un ciudadano de primera clase de msbuild. El enlace anterior también hace mención de la PackageReference, pero detalla el siguiente anuncio mejor:

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

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

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

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

Answer 2

Aunque normalmente no me gusta la idea de agregar exe's al control de fuente, sugeriría que el control de fuente debe contener todo lo que se requiere para abrir, construir y ejecutar el proyecto.

En este caso, parece que la carpeta .nuget es una dependencia obligatoria. Por lo tanto, debe estar bajo el control de la fuente.

La única pregunta que queda, que es necesario investigar, es como NuGet va a reaccionar si esa carpeta está marcado de sólo lectura, que TFS hará una vez que se haya registrado.

---

Actualización: Hice un poco más de investigación 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 quiere hacer es hacer de NuGet un requisito que debe instalarse en todas las estaciones de trabajo de los desarrolladores.

Además, debe colocar en el control de código fuente el archivo de proceso por lotes requerido para preparar una estación de trabajo para comenzar a editar el proyecto. El archivo de proceso 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 esto funciona.

Answer 3

Según this thread, la carpeta .nuget debe tener una versión controlada.

Answer 4

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

Utilizamos Subversion para el control de código fuente, y mi pensamiento inicial es que .nuget se debe agregar a nuestro repositorio, pero se agregó usando svn:externals para que apunte a una sola ubicación.

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

Tenemos un montón de proyectos, por lo que también significa no duplicar nuget.exe varias veces en el repositorio.

Answer 5

Debe confirmar .nuget\nuget.targets, pero no nuget.exe. Los objetivos descargarán el exe si no existe, siempre y cuando cambie DownloadNuGetExe a true en nuget.objetivos

Answer 6

@Richard La respuesta de Szalay es correcta - no es necesario que confíe nuget.exe. Si por alguna razón Visual Studio no se descarga automáticamente el nuget.exe, asegúrese de que ha continuación se enuncian a cierto en el archivo nuget.targets:

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

cerrar la solución VS, volver a abrirlo y construirlo. Visual Studio debería descargar nuget.exe automáticamente ahora.

Answer 7

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

Aparte de eso, usted debe dejar de Visual Studio manejar la descarga de paquetes.