Advertencia de NuGet NU5128
Escenario 1
Algunas plataformas de destino declaradas en el grupo de dependencias de nuspec y la carpeta lib/ref no tienen coincidencias exactas en la otra ubicación. Consulte la lista de acciones siguientes:
- Agregue un grupo de dependencias para . NETStandard2.0 a nuspec
Problema
El directorio lib/<tfm>/
o ref/<tfm>/
del paquete contiene al menos un archivo para el Moniker de la plataforma de destino (TFM) especificado en el mensaje de advertencia. Pero no existe ningún grupo de dependencias para este TFM en el archivo nuspec
. Esto puede hacer que los consumidores del paquete crean que no es compatible con el TFM, incluso si el paquete no tiene dependencias. Si el paquete tiene dependencias no declaradas, el proyecto que usa el paquete experimentará errores en tiempo de ejecución.
Solución
- Ejecución del destino del paquete de NuGet en el proyecto
Si es posible, use el destino del paquete de MSBuild de NuGet, ya que compara automáticamente los TFM de ensamblado con los grupos de dependencias de las plataformas de destino del proyecto. Tenga en cuenta que el proyecto debe usar PackageReference
para sus propias dependencias de NuGet. Si el proyecto usa packages.config, debe usar nuget.exe pack
y un archivo nuspec
.
- Archivo
nuspec
editado manualmente
Si usa un archivo nuspec
personalizado, se recomienda que cada TFM para el que existan ensamblados lib/
o ref/
debe tener un grupo de dependencias coincidente, incluso si las dependencias son las mismas que las del siguiente TFM compatible. Por ejemplo, si un paquete contiene ensamblados netstandard1.0
y netstandard2.0
, y las dependencias son las mismas para los dos, se recomienda que los dos TFM se muestren como grupos de dependencias con elementos de dependencia duplicados.
Tenga en cuenta que en el identificador de TFM usado en las rutas de acceso de ensamblado se utiliza un formato diferente al del identificador de TFM usado en los grupos de dependencias. El mensaje de advertencia especifica el nombre correcto que se va a usar en el grupo de dependencias. Si el paquete no tiene dependencias para ese marco de destino, use un grupo vacío. Por ejemplo:
<package>
<metadata>
...
<dependencies>
<group targetFramework=".NETFramework4.7.2" />
</dependencies>
</metadata>
...
</package>
- Quite los archivos
lib/
oref/
Si no quiere que el paquete sea compatible con el TFM notificado, modifique el proyecto de forma que no haya archivos lib/<tfm>/
o ref/<tfm>/
en el paquete para ese TFM. Por ejemplo, si la advertencia indica que se agrega un grupo de dependencias para .NETFramework4.7.2
a nuspec
, quite los archivos lib/net472/*
y ref/net472/*
del paquete.
Escenario 2
Algunas plataformas de destino declaradas en el grupo de dependencias de nuspec y la carpeta lib/ref no tienen coincidencias exactas en la otra ubicación. Consulte la lista de acciones siguientes:
- Adición de ensamblados lib o ref para la plataforma de destino netstandard2.0
Problema
El archivo nuspec
tiene un grupo de dependencias para el Moniker de la plataforma de destino (TFM) notificado, pero no existen ensamblados para este TFM en lib/
o ref/
. Si hay ensamblados para un TFM compatible, el paquete se seguirá instalando, pero las dependencias podrían ser incorrectas para los ensamblados que se usan en tiempo de compilación y se podría producir un error en el proyecto en tiempo de ejecución.
Solución
- Ejecución del destino del paquete de NuGet en el proyecto
Si es posible, use el destino del paquete de MSBuild de NuGet, ya que compara automáticamente los TFM de ensamblado con los grupos de dependencias de las plataformas de destino del proyecto. Tenga en cuenta que el proyecto debe usar PackageReference
para sus propias dependencias de NuGet. Si el proyecto usa packages.config, debe usar nuget.exe pack
y un archivo nuspec
.
- Edición manual del archivo
nuspec
Agregue el TFM notificado como marco de destino adicional para el que se compila el proyecto y agregue los ensamblados al paquete. Si usa un proyecto de estilo de SDK para seleccione varios TFM como destino, los destinos del paquete MSBuild de NuGet pueden agregar automáticamente ensamblados en la carpeta lib/<tfm>/
correcta y crear grupos de dependencias con los TFM y las dependencias correctos. Si usa un proyecto de estilo que no es de SDK, es probable que tenga que crear otro archivo del proyecto para el TFM adicional y modificar el archivo nuspec
para copiar los ensamblados de salida en la ubicación correcta del paquete.
- Adición de un archivo
_._
vacío
Si el paquete no contiene ensamblados, como un metapaquete, considere la posibilidad de agregar un archivo _._
vacío a los directorios lib/<tfm>/
de los TFM enumerados en el mensaje de advertencia. Por ejemplo, si la advertencia indica que se agregan ensamblados para el marco de destino netstandard2.0
, cree un archivo lib/netstandard2.0/_._
vacío en el paquete.
- Eliminación del grupo de dependencias
Si usa un archivo nuspec
personalizado, quite el grupo de dependencias para el TFM notificado, y deje solo grupos de dependencias para los TFM para los que existen archivos lib/<tfm>/
o ref/<tfm>/
.
- Eliminación de todas las dependencias de los paquetes que no están relacionados con ensamblados
Si el paquete no contiene ningún archivo lib/
o ref/
, y no es un metapaquete, es probable que no tenga ninguna dependencia necesaria para el consumidor del paquete. Si va a empaquetar con el destino MSBuild Pack de NuGet, puede establecer <SuppressDependenciesWhenPacking>true</SuppressDependenciesWhenPacking>
en cualquier instancia de PropertyGroup
en el archivo del proyecto. Si usa un archivo nuspec
personalizado, quite el elemento <dependencies>
.
- Otros escenarios
Esta advertencia se agregó durante el desarrollo de NuGet 5.3 y primero estuvo disponible en la versión preliminar 9 del SDK de .NET Core 3.0. En NuGet/Home#8583 se realiza el seguimiento de un problema que provocaba la advertencia en demasiados escenarios. Puede usar la propiedad de NoWarn
MSBuild (agregue <NoWarn>$(NoWarn);NU5128</NoWarn>
a cualquier instancia de PropertyGroup
en el archivo del proyecto). Si tiene varios proyectos afectados, puede usar Directory.Build.targets
para agregar NoWarn
automáticamente a todos los proyectos.