Desarrollo local sin dolor al tiempo que se hace referencia a los paquetes NuGet

Estoy intentando publicar y consumir paquetes NuGet versionados de bibliotecas de clases mientras evito dolores de cabeza para el desarrollo local. Aquí hay un ejemplo de diseño de solución de Visual Studio: 

| Libraries
  | LibraryA
  | LibraryB
  | LibraryC
| Applications
  | ApplicationD
  | ApplicationE

Esta es una solución única que contiene bibliotecas de clases compartidas y múltiples aplicaciones. Actualmente, las referencias a las bibliotecas de clases por parte de las aplicaciones son referencias locales dentro de la solución.

Lo que me gustaría hacer es publicar las bibliotecas (A, B, C) como paquetes NuGet versionados que luego son referenciados por las aplicaciones según sea necesario (D, E). Esto permite que un cambio a una biblioteca compartida sea independiente de una actualización a una aplicación que se implementa. Sin esto, cambiar una biblioteca podría hacer que los binarios cambien en una docena o más aplicaciones, todas las cuales técnicamente tendrían que ser probadas. Esto es indeseable, y el control de versiones con NuGet lo soluciona.

Sin Embargo, digamos que quiero actualizar el contenido de LibraryA y ApplicationD al mismo tiempo. Para hacer esto después de que hayamos cambiado a NuGet, tendré que hacer cambios en LibraryA, confirmarlos, esperar a que se cree el paquete, decirle a ApplicationD que actualice su referencia a LibraryA, y luego probar o desarrollar en ApplicationD. Esto es mucho más complicado que simplemente trabajar con ambos al mismo tiempo utilizando referencias locales en la solución.

¿Cuál es una mejor manera de obtener tanto la robustez de los paquetes NuGet versionados para mis bibliotecas de clases compartidas, mientras que también mantiene desarrollo simple, incluso si se extiende a través de múltiples proyectos y aplicaciones? Las únicas otras soluciones que he encontrado implican demasiados gastos generales o dolor de cabeza, como tener que cambiar constantemente las referencias para la aplicaciónd entre el paquete NuGet y el proyecto local.

EDITAR: Para aclarar la premisa, esta pregunta asume lo siguiente:

  • La arquitectura (solución y organización del proyecto) no se puede reorganizar significativamente
  • Compartido las bibliotecas van a cambiar a una frecuencia no trivial
  • Cambiar una biblioteca compartida no puede forzar la actualización de ninguna aplicación
  • Las aplicaciones pueden hacer referencia a diferentes versiones de bibliotecas compartidas
Author: jmsb, 2014-12-30
Source

3 answers

Desafortunadamente, realmente no hay una manera de tener lo mejor de ambos mundos. Internamente en mi empresa, lo hemos mitigado un poco con un proceso de compilación/implementación rápido, que contrarresta la mayoría de las cargas con siempre hacer referencia a un paquete NuGet. Básicamente, todas nuestras aplicaciones utilizan una versión diferente de la misma biblioteca alojada en un repositorio NuGet local. Dado que utilizamos nuestro propio software para construir, implementar y alojar los paquetes, hace que sea bastante rápido actualizar la biblioteca, luego actualizar su Paquete NuGet en otra solución. Esencialmente, el flujo de trabajo más rápido que hemos encontrado es este:

  1. Hacer cambios en la biblioteca
  2. Construir e implementar automáticamente la versión de la biblioteca incrementada en 1 a la fuente interna de NuGet
  3. Actualizar el paquete NuGet en la aplicación de consumo

Todo el proceso, desde el check-in hasta la actualización del proyecto consumidor, toma alrededor de 3 minutos. El repositorio NuGet también tiene un servidor de símbolos / fuente que ayuda enormemente con la depuración.

 3
Author: John Rasch,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2014-12-30 21:23:48

Aunque toma algo de trabajo, es posible editar a mano .archivos csproj para configurar la referencia condicional agregando un atributo Condition a las referencias apropiadas.

EDIT He movido estas condiciones a ItemGroups, ya que parece que así es como funciona mi código de producción mencionado, y se ha mencionado que este es un posible problema en VS 2013.

<ItemGroup Condition="'$(Configuration)' == 'Debug Local'">
    <!-- Library A reference as generated by VS for an in-solution reference, children unmodified -->
    <ProjectReference>...
</ItemGroup>

<ItemGroup Condition="'$(Configuration)' == 'Debug NuGet'">
    <!-- Library A reference as generated by NuGet, child nodes unmodified --> 
    <Reference Include="LibraryA">...
</ItemGroup>

Esto le permitiría tener, en los Proyectos D & E, configuraciones de" Debug NuGet " vs. "Debug Local" que hace referencia a las bibliotecas de manera diferente. Si luego tiene varios archivos de solución que tienen sus configuraciones asignadas a las configuraciones apropiadas en los proyectos dentro, el usuario final nunca vería más que " Debug "y" Release " para la mayoría de las operaciones, ya que esas son las configuraciones de la solución, y solo necesitaría abrir la solución completa para editar los proyectos A, B y C.

Ahora, en cuanto a sacar los proyectos A, B y C del camino, podría configurarlos bajo a carpeta marcada como subrepo (asumiendo que estás usando un SCM que soporta esto, como Git). La mayoría de los usuarios nunca tendrían que tirar de la subrepo ya que no están accediendo a los proyectos de ABC, y en su lugar están agarrando de NuGet.

En cuanto al mantenimiento, puedo garantizar que VS no editará las referencias condicionales, y las respetará durante la compilación - He pasado por VS 2010 y 2013 (EDIT: Professional version, aunque he profundizado en hacer lo mismo con express) con los mismos proyectos de referencia condicionales en funcionamiento. Tenga en cuenta que en VS, las referencias se pueden hacer independientemente de la versión, haciendo que NuGet sea el único lugar desde el que se debe mantener la versión, y eso se puede hacer como cualquier otro paquete de NuGet. Aunque tengo esperanzas, NO he probado si NuGet luchará con las referencias condicionales.

EDIT También puede ser prudente tener en cuenta que las referencias condicionales pueden causar advertencias sobre archivos DLL faltantes, pero en realidad no obstaculizan la compilación o corre.

 17
Author: David,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2014-12-30 20:10:12

Sé que esta es una publicación de hace 2 años, pero la encontré mientras enfrentaba la misma situación. También encontré esto para VS2015, estoy en el proceso de probarlo. Volveré y ajustaré mi respuesta en consecuencia.

Https://marketplace.visualstudio.com/items?itemName=RicoSuter.NuGetReferenceSwitcherforVisualStudio2015

 8
Author: JayR,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-05-09 14:25:42