Estamos empezando a usar NuGet y tenemos algunos problemas:

Primero algunos datos de NuGet:

(Solo para asegurarnos de que hemos entendido las premisas de cómo funciona NuGet)

Los paquetes.config (ubicados en raíz del proyecto) se crean y actualizan a medida que agrega, actualiza o elimina paquetes. Dentro de este archivo, la propiedad de versión del paquete refleja la versión completa que está en uso, por lo que en este sentido también es un estado. Es posible agregar la propiedad allowedVersions a la especificación del paquete, que es una restricción sobre qué versiones se pueden actualizar. Para que funcione la restauración de paquetes, este archivo debe estar bajo control de código fuente.

La carpeta de paquetes se encuentra en la raíz de la solución y contiene una versión descargada de los paquetes dependientes en una subcarpeta nombrada para que coincida con los nombres de los paquetes (incluida la versión), para permitir que múltiples proyectos del mismo paquete sean utilizados por diferentes proyectos en varios Solución de proyecto. Se recomienda no controlarlos en origen, ya que son archivos binarios y el hecho de que la restauración de paquetes puede recrearlos cuando sea necesario. Cuando se actualiza un paquete, se crea una nueva carpeta que coincide con la actualización que contiene el paquete.

Los archivos de proyecto contienen una referencia a los paquetes en la carpeta de paquetes, para que funcionen las compilaciones y para que Visual Studio también pueda proporcionar autocompletado, intellisense y más. Cuando se actualiza un paquete, las referencias en el archivo de proyecto se actualizan para coincidir con la nueva ubicación del paquete en la carpeta de paquetes.

Preguntas:

Dado que las entradas de paquete de archivo packages.config contienen la información de la versión completa, necesitamos actualizar constantemente el control de origen con los cambios. O bien, podríamos ignorar los cambios, la mayoría de las veces, pero cuando solo la versión ha cambiado, (en la mayoría de los casos) podríamos ignorarlos. Esto parece muy innecesario, ya que la restauración de NuGet debería poder saber qué versiones están permitidas (a través de allowedVersions).

La propiedad allowedVersions se debe agregar manualmente, algo que se olvida fácilmente. Estamos utilizando el control de versiones semántico, por lo que para nosotros, al instalar, es decir, una versión Foo-1.1.0, allowedVersions = "[1,2)" debe estar implícito.

Cuando se agrega la restauración permitida, entonces la restauración del paquete NuGet no parece ser capaz de encontrar ensamblajes de publicación (¿quizás un error?).

¿Por qué los paquetes son manejados por NuGet en un nivel de solución? Si está trabajando en una solución de combinación y combinación, que contiene un proyecto A (repo-1) y un proyecto B (repo-2), el paquete de nivel de solución no va a funcionar bien. Es decir, si guarda el archivo de la solución en una ubicación separada, las cosas podrían seguir funcionando. Pero, si luego configura otra solución que contenga project-A (repo-1) y project-C (repo-3), entonces project-A repentinamente necesitaría un paquete de restauración nuevamente, y peor aún, las referencias del proyecto serían cambiado para coincidir con el último cambio. Volver a la primera solución tendrá referencias que no funcionarán. El registro de estos hará que no funcionen para otros.

En una actualización de paquete, las referencias del archivo de proyecto se actualizan (para que coincidan con los nuevos nombres de carpeta con versionid en ellas) y aparecerán como un cambio no confirmado. Cometer este cambio parece ser la norma, pero en nuestra opinión esto no debería ser necesario.

Notas sobre ExcludeVersion (Lo que podría sugerirse como una solución al problema anterior:

Solo puede proporcionar esa opción cuando ejecuta manualmente los comandos de NuGet, afaik. Al instalar / actualizar paquetes a través de los menús de NuGet en Visual Studio, no se puede usar esa opción. El uso de cualquiera de las herramientas automáticas significa que el nombre de la carpeta y la referencia del proyecto se deben corregir manualmente después.

Sabemos que ExcludeVersion no es la configuración predeterminada, probablemente debido a la compatibilidad con los casos en los que alguien está trabajando en una solución de proyectos múltiples, donde los diferentes proyectos dependen de diferentes versiones del mismo paquete.

¿Soluciones posibles?

(Pero, ¿qué puede requerir cambios sustanciales en el ecosistema de NuGet?)

A - packages.config

Deseo que cada elemento del paquete en packages.config pueda deshacerse deVersions permitidas y, en cambio, cambie la versión para que sea el especificador de rango. El elemento de paquetes también debe proporcionar una manera de identificar por separado de qué fuente obtener las actualizaciones. Finalmente, si un paquete instalado sigue las versiones semánticas, entonces la propiedad de la versión debería configurar automáticamente el rango de versiones de acuerdo con la versión instalada.

Ejemplo de paquetes.config:

`<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="Foo" version="[1,2] source="Development Feed">
</packages>`

Esto sería:

Solucione el problema con confirmaciones excesivas del archivo package.config, ya que la propiedad de la versión ya no se actualiza constantemente.

No es necesario recordar establecer el rango para los proyectos versionados semánticamente.

Asegúrese de que los paquetes se obtengan del feed deseado y de que no se pierda tiempo buscándolo en las fuentes incorrectas.

B - Carpeta de paquetes y los nombres de los paquetes instalados dentro de

Me gustaría que la carpeta de paquetes estuviera ubicada en cada raíz del proyecto y que los nombres de las subcarpetas estuvieran limitados solo al nombre del paquete, excluyendo la versión. Esto sería:

Solucione el problema con una confirmación excesiva de los archivos de proyecto, ya que las referencias de proyecto en el archivo de proyecto ahora apuntan a la misma carpeta de paquete después de una actualización.

Permite que los proyectos utilicen diferentes versiones del mismo paquete, ya que son realmente independientes entre sí.

Nos encantaría conocer las soluciones a los problemas enumerados.