Compartir por

Advertencia de NuGet NU1605

  • Artigo

Ejemplo 1

Cambio a una versión anterior del paquete detectado: “PackageB” de 4.0.0 a 3.5.0. Haz referencia al paquete directamente desde el proyecto para seleccionar una versión diferente.
    “Project” -> “PackageA” 4.0.0 -> “PackageB” (>= 4.0.0)
    “Project” -> “PackageB” (>= 3.5.0)

Problema

Un paquete de dependencias especificó una restricción de versión en una versión de un paquete posterior a la que la restauración resolvió en última instancia. Esto se debe a la regla direct-dependency-wins: al resolver paquetes, la versión del paquete directo en el subgrafo invalidará la de los paquetes lejanos con el mismo id.

Solución

Para el proyecto que muestra la advertencia de restauración, agrega una referencia de paquete a la versión posterior del paquete.

En el ejemplo anterior, cambiarías la referencia del paquete a PackageB 4.0.0:

“PackageA” 4.0.0 -> “PackageB” 4.0.0
“PackageB” 4.0.0

Ejemplo 2

Cambio a una versión anterior del paquete detectado: “PackageC” de 2.0.0 a 1.1.0. Haz referencia al paquete directamente desde el proyecto para seleccionar una versión diferente.
    “Project” -> “PackageA” 1.0.0 -> “PackageB” 2.0.0 ->“PackageC” (>= 2.0.0)
    “Project” -> “PackageA” 1.0.0 -> “PackageC” (>= 1.1.0)

Problema

Un paquete de dependencias especificó una restricción de versión en una versión de un paquete posterior a la que la restauración resolvió en última instancia. Esto se debe a la regla direct-dependency-wins: al resolver paquetes, NuGet intenta respetar la intención del autor del paquete. El autor de PackageA ha cambiado explícitamente a una versión anterior, a PackageC 1.1.0 desde PackageC 2.0.0.

Solución

Para el proyecto que muestra la advertencia de restauración, agrega una referencia de paquete a la versión posterior del paquete.

En el ejemplo anterior, cambiarías la referencia del paquete a PackageC 2.0.0:

“PackageA” 4.0.0 -> “PackageB” 4.0.0
“PackageB” 4.0.0

Ejemplo 3

Cambio de paquete a una versión anterior detectado: System.IO.FileSystem.Primitives de 4.3.0 a 4.0.1. Haz referencia al paquete directamente desde el proyecto para seleccionar una versión diferente.
Proyecto -> System.IO.FileSystem 4.0.1 -> runtime.win.System.IO.FileSystem 4.3.0 -> System.IO.FileSystem.Primitives (>= 4.3.0)
Proyecto -> System.IO.FileSystem 4.0.1 -> System.IO.FileSystem.Primitives (>= 4.0.1)

Problema

Algunas combinaciones de paquetes que se incluyen con .NET Core 1.0 y 1.1 no son compatibles entre sí cuando se hace referencia a ellos juntos en un proyecto de .NET Core 3.0 o superior, y se especifica RuntimeIdentifier. Los paquetes problemáticos suelen comenzar por System. o Microsoft. y tienen números de versión entre 4.0.0 y 4.3.1. En este caso, el mensaje de cambio a una versión anterior tendrá un paquete que empezará por runtime.<RID> en la cadena de dependencias.

Solución

Para solucionar este problema, agrega la siguiente PackageReference:

<PackageReference Include="Microsoft.NETCore.Targets" Version="3.0.0" PrivateAssets="all" />

Puedes optar por usar la correspondencia version con la versión principal del SDK.

Ejemplo 4

Cambio a una versión anterior del paquete detectado: Microsoft.NETCore.App de 2.1.8 a 2.1.0. Haz referencia al paquete directamente desde el proyecto para seleccionar una versión diferente.
    prueba -> mvc -> Microsoft.NETCore.App (>= 2.1.8)
    prueba -> Microsoft.NETCore.App (>= 2.1.0)

Problema

El proyecto mvc especificó una restricción de versión en una versión de un paquete posterior a la que la restauración resolvió en última instancia. Esto se debe a la regla direct-dependency-wins: al resolver paquetes, la versión del paquete al que se hace referencia directamente en el grafo invalidará la del paquete lejano con el mismo id.

Solución

Este error específico (con el paquete Microsoft.NETCore.App) se ha mejorado moviendo el SDK de .NET Core a la versión 2.2.100 o posterior. Microsoft.NETCore.App es un paquete al que se hace referencia automáticamente que el SDK de .NET Core de versiones anteriores a la 3.0.100 elige incluir de forma automática. Consulta también Puesta al día del runtime de implementación autocontenida.

Nota:

Aunque NU1605 se considera una advertencia mediante las herramientas de NuGet, el SDK de .NET opta por tratar esta advertencia como un error a través de WarningsAsErrors. Es posible que el proyecto actualice esta advertencia a un error estableciendo TreatWarningsAsErrors como true. Aunque no se recomienda, ya que es más probable que encuentres problemas en tiempo de ejecución, puedes optar por suprimir esta advertencia.

Sugerencia

Solución alternativa: NuGetSolver es una extensión de Visual Studio que ha desarrollado Microsoft DevLabs y está diseñada para ayudar a resolver conflictos de dependencias. Esta extensión automatiza el proceso de identificación y resolución de esos problemas. Para obtener más información, visite la página de NuGetSolver en Visual Studio Marketplace. Además, nos encantaría que nos contase su experiencia.