¿Cómo utilizar correctamente NuGet con Team Development?

Question

Así que me gustaría utilizar NuGet para administrar los diversos proyectos que uso para un proyecto específico en el que estoy trabajando mi equipo. Hasta este momento, he colocado mis archivos de biblioteca .js en el directorio/Scripts de mi solución web (ASP.NET MVC 2) y los he referenciado. Por supuesto, esto era manual y era molesto de administrar durante las actualizaciones, etc.

Ahora que estoy usando NuGet, me doy cuenta de que todo el objetivo de NuGet es hacer que esto sea bastante sencillo. Además, parece que no debería tener que verificar mis paquetes en mi repositorio (AKA ya no necesito administrar mis bibliotecas externas). Sin embargo, cuando tomo jQuery (por ejemplo) de NuGet, coloca sus archivos específicos en el directorio/Scripts de mi proyecto.

Donde me confundo, ¿qué pasa si controlo el control de la fuente en este punto? ¿Todavía controlo en el directorio/Scripts?

Además, si alguien más está trabajando en este proyecto y verifica la solución desde el control de origen, ¿se descargan automáticamente los paquetes (suponiendo que la solución viene con un paquete.config válido)?

Estoy tratando de aclarar un par de puntos antes de comenzar a utilizar NuGet a tiempo completo.

Answer 1

Hay dos escenarios para NuGet vs VCS: para registrarse o no para el check-in, esa es la pregunta. Ambos son válidos en mi opinión, pero cuando utilizo TFS como VCS, definitivamente elegiría no-checkin policy for NuGet packages.

Dicho esto, incluso cuando se utiliza una política de no-check-in para los paquetes NuGet, todavía verifico los cambios de contenido que esos paquetes NuGet han hecho a mis proyectos. La carpeta \Scripts se registraría en su totalidad (no selectiva, no ignorada).

La política de no-checkin para paquetes significa: no registrar en la carpeta \ Packages (cloak it, ignórelo), excepto para el archivo \Packages\repositories.config.

Como tal, no está cometiendo ningún paquete NuGet y cuando usa Enable-PackageRestore desde NuGetPowerTools (esto será incorporado en NuGet v1.6 a la vuelta de la esquina), cualquier máquina que verifique el código y las compilaciones, buscará todas las dependencias NuGet requeridas en un paso previo a la compilación. Esto es válido tanto para máquinas de desarrollo local como para servidores de compilación, siempre que se habilite Enable-PackageRestore en su solución y apunte a los repositorios NuGet correctos (local, interno, externo).

Si lo piensas bien, al instalar un paquete NuGet que solo agrega referencias a algunos binarios, ya estarías haciendo lo mismo en un escenario de no-checkin: no asignarías las subcarpetas de la carpeta \Packages, pero aún así, comprometerías los cambios del proyecto (la referencia agregada).

Diría que sea consistente (para cualquier tipo de paquete), ya sea que contenga solo binarios, solo contenido o una combinación. Do not commit the packages themselves, comprometa los cambios en sus fuentes. (aunque solo sea para evitar la molestia de buscar qué cambió el contenido)

Answer 2

NuGet, como Nexus, son repositorio de artefactos (artefacto que es cualquier tipo de entregable, incluido el binario potencialmente grande).

El efecto secundario es para que lo guarde en un VCS (sistema de control de versiones) elementos que:

• no se beneficiarían de funciones de control de versiones (de ramificación, la fusión)
• aumentaría significativamente el tamaño del repositorio VCS (sin delta o delta débil almacenamiento)
• sería muy difícil de eliminar de un repositorio VCS (diseñado principalmente para mantener la historia)

Pero el objetivo es para que usted pueda declarar lo que necesita (y dejar que NuGet traiga en su caso) en lugar de almacenar usted mismo.
Así que puede la versión /Scripts como marcador de posición, pero ya no necesita versionar ninguno de sus contenidos que ahora se recupera automáticamente.