visual-studio - subir - visual studio code git
¿Debería agregarse la carpeta.nuget al control de versión? (7)
Ahora que nuget admite la restauración de paquetes, lo estamos estudiando más de cerca.
Usamos Subversion para el control de código fuente, y mi pensamiento inicial es que .nuget debería ser agregado a nuestro repositorio, pero agregado usando svn:externals para que apunte a una sola ubicación.
De esa forma, podemos enviar automáticamente nuevas versiones a todos los desarrolladores y proyectos. Para los proyectos en las ramas de publicación, en lugar de HEAD, podemos especificar la revisión de la referencia svn: external si queremos dejar nuget alone.
Tenemos muchos proyectos, por lo que también significa no duplicar nuget.exe varias veces en el repositorio.
Con las versiones más nuevas de NuGet, es posible configurar un proyecto para restaurar automáticamente los paquetes NuGet de modo que la carpeta de 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 lidian ustedes con esto? Añadir .nuget al control de fuente? ¿Ejecuta algún script de línea de comando antes de abrir la solución?
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 debe investigar, es cómo reaccionará NuGet si esa carpeta está marcada como de solo lectura, lo 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 quieres hacer es hacer que NuGet sea un requisito que debe instalarse en todas las estaciones de trabajo de los desarrolladores.
Además, debe colocar en el control de origen el archivo 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 quizás quieras contactarte directamente con NuGet para preguntarles cómo, exactamente, se supone que debe funcionar.
De acuerdo con este hilo , la carpeta .nuget debe ser controlada por la versión.
Esta publicación es antigua, ya no deberías volver a utilizar la restauración del paquete NuGet a nivel de solución. 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. Por lo tanto, 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 Standard 2.0, cuando utiliza el nuevo formato csproj ahora puede usar referencias de paquetes, irónicamente reintroduciendo la dependencia en msbuild para restaurar paquetes, pero ahora los paquetes son un ciudadano de primera clase de msbuild . El enlace de arriba también hace mención de PackageReference , pero el siguiente anuncio lo detalla mejor:
https://blog.nuget.org/20170316/NuGet-now-fully-integrated-into-MSBuild.html
Y el anuncio 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: Al parecer, 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 para restaurar las dependencias de paquetes. Estoy seguro de que todo se resolverá.
La respuesta de @Richard Szalay es correcta: no es necesario que confíe nuget.exe. Si por alguna razón Visual Studio no descarga automáticamente el nuget.exe, asegúrese de tener el siguiente conjunto en verdadero en el archivo nuget.targets :
<!-- Download NuGet.exe if it does not already exist -->
<DownloadNuGetExe Condition=" ''$(DownloadNuGetExe)'' == '''' ">true</DownloadNuGetExe>
Cierre la solución VS, vuelva a abrirla y compórtala. Visual Studio debería descargar nuget.exe automáticamente ahora.
Tenemos el archivo nuget.config en la carpeta, ya que tiene las referencias a nuestro servidor Nuget interno, usando el área Fuentes de paquete: https://docs.nuget.org/consume/nuget-config-settings
Además de este motivo, debe dejar que Visual Studio maneje la descarga de paquetes.
.nuget/nuget.targets confirmar .nuget/nuget.targets , pero no nuget.exe . Los objetivos descargarán el exe si no existe, siempre que cambies DownloadNuGetExe a true en nuget.targets