Pregunta Desarrollo local libre de dolor al tiempo que hace referencia a paquetes NuGet


Estoy intentando publicar y consumir paquetes versionados de bibliotecas de clases de NuGet, a la vez que evito dolores de cabeza para el desarrollo local. Aquí hay un diseño de ejemplo 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 en solución.

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

Sin embargo, digamos que quiero actualizar el contenido de LibraryA y ApplicationD al mismo tiempo. Para hacer esto después de haber 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 usando referencias locales en solución.

¿Cuál es una mejor manera de obtener la solidez de los paquetes NuGet versionados para mis bibliotecas de clases compartidas y al mismo tiempo mantener el desarrollo simple incluso si abarca varios proyectos y aplicaciones? Las únicas otras soluciones que he encontrado implican demasiada sobrecarga o dolor de cabeza, como tener que cambiar constantemente las referencias para ApplicationD 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
  • Las bibliotecas compartidas van a cambiar a una frecuencia no trivial
  • Cambiar una biblioteca compartida no puede obligar a que se actualice ninguna aplicación
  • Las aplicaciones pueden hacer referencia a diferentes versiones de bibliotecas compartidas

32
2017-12-30 19:30


origen


Respuestas:


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

  1. Haga cambios a la biblioteca
  2. Cree e implemente automáticamente la versión de la biblioteca incrementada en 1 a la fuente NuGet interna
  3. Actualiza el paquete NuGet en la aplicación para el consumidor

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


3
2017-12-30 21:23



Aunque requiere cierto trabajo, es posible editar manualmente archivos .csproj para configurar referencias condicionales agregando un Condition atribuir a las referencias apropiadas.

EDITAR Trasladé estas condiciones a ItemGroups, ya que parece que así es como funciona mi código de producción mencionado, y se ha mencionado que esto 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 las configuraciones de D & E de proyectos, "Debug NuGet" frente a "Debug Local", que hace referencia a las bibliotecas de forma diferente. Si luego tiene varios archivos de solución que tienen sus configuraciones asignadas a las configuraciones apropiadas en los proyectos, el usuario final nunca verá más que "Depurar" y "Liberar" para la mayoría de las operaciones, ya que esas son las configuraciones de la solución, y solo necesita abrir la solución completa para editar los proyectos A, B y C.

Ahora, en cuanto a quitar los proyectos A, B y C, puede configurarlos en una carpeta marcada como subrepo (suponiendo que esté usando un SCM que admita esto, como Git). La mayoría de los usuarios nunca necesitarían extraer el subrepo ya que no están accediendo a los proyectos de ABC, y en cambio están comprando desde 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 (EDITAR: Versión profesional, aunque he profundizado haciendo lo mismo con express) con los mismos proyectos de referencia condicional en el trabajo. Tenga en cuenta que en VS, las referencias pueden hacerse independientes de la versión, por lo que NuGet es el único lugar desde el que se debe mantener la versión, y eso se puede hacer como cualquier otro paquete NuGet. Aunque tengo esperanzas, NO he probado si NuGet luchará con las referencias condicionales.

EDITAR También puede ser prudente observar que las referencias condicionales pueden causar advertencias sobre archivos DLL faltantes, pero en realidad no dificultan la compilación o la ejecución.


16
2017-12-30 19:42



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

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


6
2018-05-09 14:25