PackageReference en archivos del proyecto

Las referencias de paquetes, utilizando <PackageReference> elementos de MSBuild, especifican las dependencias de paquetes de NuGet directamente dentro de los archivos del proyecto, en lugar de tener un archivo packages.config independiente. El uso de PackageReference no afecta a otros aspectos de NuGet; por ejemplo, las configuraciones en archivos NuGet.Config (incluidos los orígenes de paquetes) se siguen aplicando como se explica en Common NuGet configurations.

Con PackageReference, también puede usar las condiciones de MSBuild para elegir referencias de paquetes por plataforma de destino u otras agrupaciones. También le proporciona un control específico sobre las dependencias y el flujo de contenido. (Para obtener más información, consulte Paquete nuGet y restauración como destinos de MSBuild).

Soporte para tipos de proyecto

De forma predeterminada, PackageReference se usa para proyectos de .NET, proyectos de .NET Standard y proyectos de UWP destinados a Windows 10 Build 15063 (Creators Update) y versiones posteriores, con la excepción de los proyectos de UWP de C++. Los proyectos de .NET Framework admiten PackageReference, pero actualmente tienen como valor predeterminado packages.config. Para usar PackageReference en un proyecto de .NET Framework, migre las dependencias del archivo de packages.config proyecto y, a continuación, quite packages.config.

ASP.NET aplicaciones destinadas a .NET Framework completa solo incluyen compatibilidad limitada con PackageReference. Los tipos de proyecto de C++y JavaScript no son compatibles.

Agregar un PackageReference

Agregue una dependencia en el archivo de proyecto usando la sintaxis siguiente:

<ItemGroup>
    <!-- ... -->
    <PackageReference Include="Contoso.Utility.UsefulStuff" Version="3.6.0" />
    <!-- ... -->
</ItemGroup>

Controlar la versión de una dependencia

La convención para especificar la versión de un paquete es la misma que cuando se usa packages.config:

<ItemGroup>
    <!-- ... -->
    <PackageReference Include="Contoso.Utility.UsefulStuff" Version="3.6.0" />
    <!-- ... -->
</ItemGroup>

En el ejemplo anterior, 3.6.0 significa cualquier versión que sea >=3.6.0 con preferencia para la versión más baja, como se describe en Control de versiones del paquete.

Uso de PackageReference para un proyecto sin dependencias de paquetes

Avanzado: Si no tiene paquetes instalados en un proyecto (ninguna PackageReference en el archivo de proyecto y ningún archivo packages.config), pero quiere que el proyecto se restaure como de estilo PackageReference, puede establecer una propiedad de proyecto RestoreProjectStyle en PackageReference en el archivo de proyecto.

<PropertyGroup>
    <!--- ... -->
    <RestoreProjectStyle>PackageReference</RestoreProjectStyle>
    <!--- ... -->
</PropertyGroup>    

Esto puede ser útil si hace referencia a proyectos con estilo PackageReference (proyectos de estilo csproj o SDK existentes). Esto permitirá que el proyecto haga referencia "de manera transitiva" a los paquetes a los que hacen referencia dichos proyectos.

PackageReference y repositorios

En los proyectos de PackageReference, las versiones de dependencia transitiva se resuelven en el momento de la restauración. Por lo tanto, en los proyectos PackageReference, todos los orígenes deben estar disponibles para todas las restauraciones.

Versiones flotantes

Las versiones flotantes son compatibles con PackageReference:

<ItemGroup>
    <!-- ... -->
    <PackageReference Include="Contoso.Utility.UsefulStuff" Version="3.6.*" />
    <PackageReference Include="Contoso.Utility.UsefulStuff" Version="3.6.0-beta.*" />
    <!-- ... -->
</ItemGroup>

Controlar los recursos de dependencias

Puede que esté usando una dependencia únicamente como instrumento de desarrollo y no quiera exponerla a proyectos que consumirán el paquete. En este escenario, puede usar los metadatos PrivateAssets para controlar este comportamiento.

<ItemGroup>
    <!-- ... -->

    <PackageReference Include="Contoso.Utility.UsefulStuff" Version="3.6.0">
        <PrivateAssets>all</PrivateAssets>
    </PackageReference>

    <!-- ... -->
</ItemGroup>

Las siguientes etiquetas de metadatos controlan los recursos de dependencia:

Los valores permitidos para estas etiquetas son los siguientes, con varios valores separados por punto y coma, excepto por all y none, que deben aparecer por sí mismos:

<ItemGroup>
    <!-- ... -->
    <!-- Everything except the content files will be consumed by the project -->
    <!-- Everything except content files and analyzers will flow to the parent project-->
    <PackageReference Include="Contoso.Utility.UsefulStuff" Version="3.6.0">
        <IncludeAssets>all</IncludeAssets> <!-- Default is `all`, can be omitted-->
        <ExcludeAssets>contentFiles</ExcludeAssets>
        <PrivateAssets>contentFiles;analyzers</PrivateAssets>
    </PackageReference>
    <!-- ... -->
    <!-- Everything except the compile will be consumed by the project -->
    <!-- Everything except contentFiles will flow to the parent project-->
    <PackageReference Include="Contoso.Utility.SomeOtherUsefulStuff" Version="3.6.0">
        <ExcludeAssets>compile</ExcludeAssets>
        <PrivateAssets>contentFiles</PrivateAssets>
    </PackageReference>
    <!-- ... -->
</ItemGroup>

Tenga en cuenta que, dado que build no se incluye con PrivateAssets, los destinos y las propiedades se derivarán al proyecto principal. Imagínese, por ejemplo, que la referencia anterior se usa en un proyecto que genera un paquete de NuGet llamado AppLogger. AppLogger puede consumir los destinos y las propiedades de Contoso.Utility.UsefulStuff, igual que los proyectos que consumen AppLogger.

Agregar una condición de PackageReference

Puede usar una condición para controlar si se incluye un paquete. Las condiciones pueden usar cualquier variable de MSBuild o una variable definida en el archivo de destinos o propiedades. Sin embargo, en la actualidad, solo se admite la TargetFramework variable .

Por ejemplo, supongamos que tiene como destino netstandard1.4 , net452 pero tiene una dependencia que solo es aplicable para net452. En este caso, no desea que un netstandard1.4 proyecto que consuma el paquete agregue esa dependencia innecesaria. Para evitarlo, especifique una condición en PackageReference de la siguiente manera:

<ItemGroup>
    <!-- ... -->
    <PackageReference Include="Newtonsoft.Json" Version="9.0.1" Condition="'$(TargetFramework)' == 'net452'" />
    <!-- ... -->
</ItemGroup>

Un paquete creado con este proyecto mostrará que Newtonsoft.Json se incluye como dependencia únicamente para un net452 objetivo:

El resultado de aplicar una condición sobre PackageReference en VS2017.

Las condiciones también se pueden aplicar al nivel del ItemGroup y se aplicarán a todos los elementos PackageReference secundarios.

<ItemGroup Condition = "'$(TargetFramework)' == 'net452'">
    <!-- ... -->
    <PackageReference Include="Newtonsoft.Json" Version="9.0.1" />
    <PackageReference Include="Contoso.Utility.UsefulStuff" Version="3.6.0" />
    <!-- ... -->
</ItemGroup>

GeneratePathProperty

Esta característica está disponible con NuGet 5.0 o una versión superior y con Visual Studio 2019 16.0 o una versión superior.

A veces es conveniente hacer referencia a los archivos de un paquete desde un destino de MSBuild. En los proyectos basados en packages.config, los paquetes se instalan en una carpeta relativa al archivo del proyecto. Sin embargo, en PackageReference, los paquetes se consumen desde la carpeta global-packages, la cual puede variar de una máquina a otra.

Para cerrar esa brecha, NuGet presentó una propiedad que apunta a la ubicación desde la cual se consumirá el paquete.

Example:

  <ItemGroup>
      <PackageReference Include="Some.Package" Version="1.0.0" GeneratePathProperty="true" />
  </ItemGroup>

  <Target Name="TakeAction" AfterTargets="Build">
    <Exec Command="$(PkgSome_Package)\something.exe" />
  </Target>

Además, NuGet genera automáticamente propiedades para paquetes que contienen una carpeta de herramientas.

  <ItemGroup>
      <PackageReference Include="Package.With.Tools" Version="1.0.0" />
  </ItemGroup>

  <Target Name="TakeAction" AfterTargets="Build">
    <Exec Command="$(PkgPackage_With_Tools)\tools\tool.exe" />
  </Target>

Las propiedades de MSBuild y las identidades de paquete no tienen las mismas restricciones, por lo que la identidad de paquete debe cambiarse a un nombre compatible con MSBuild, precedido por la palabra Pkg. Para comprobar el nombre exacto de la propiedad generada, examine el archivo generado nuget.g.props.

Alias de PackageReference

En algunos casos poco frecuentes, los distintos paquetes contendrán clases en el mismo espacio de nombres. A partir de NuGet 5.7 y Visual Studio 2019 Update 7, de forma similar a ProjectReference, PackageReference admite Aliases. De forma predeterminada, no se proporciona ningún alias. Cuando se especifica un alias, es necesario hacer referencia a todos los ensamblados procedentes del paquete anotado con un alias.

Puede ver el uso de ejemplo en NuGet\Samples.

En el archivo del proyecto, especifique los alias de la siguiente forma:

  <ItemGroup>
    <PackageReference Include="NuGet.Versioning" Version="5.8.0" Aliases="ExampleAlias" />
  </ItemGroup>

Y en el código, úselo de la siguiente manera:

extern alias ExampleAlias;

namespace PackageReferenceAliasesExample
{
...
        {
            var version = ExampleAlias.NuGet.Versioning.NuGetVersion.Parse("5.0.0");
            Console.WriteLine($"Version : {version}");
        }
...
}

Advertencias y errores de NuGet

Esta característica está disponible con NuGet 4.3 o una versión superior y con Visual Studio 2017 15.3 o una versión superior.

En muchos escenarios de empaquetado y restauración, todas las advertencias y errores de NuGet se codifican y comienzan con NU****. Todas las advertencias y errores de NuGet se enumeran en la documentación de referencia.

NuGet observa las propiedades de advertencia siguientes:

• TreatWarningsAsErrors, trata todas las advertencias como errores.
• WarningsAsErrors, trata advertencias específicas como errores.
• NoWarn, ocultar advertencias específicas, ya sea para todo el proyecto o para todo el paquete.

Examples:

<PropertyGroup>
    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
</PropertyGroup>
...
<PropertyGroup>
    <WarningsAsErrors>$(WarningsAsErrors);NU1603;NU1605</WarningsAsErrors>
</PropertyGroup>
...
<PropertyGroup>
    <NoWarn>$(NoWarn);NU5124</NoWarn>
</PropertyGroup>
...
<ItemGroup>
    <PackageReference Include="Contoso.Package" Version="1.0.0" NoWarn="NU1605" />
</ItemGroup>

Supresión de advertencias de NuGet

Aunque se recomienda resolver todas las advertencias de NuGet durante las operaciones de empaquetado y restauración, en determinadas situaciones su supresión puede ser justificada. Para suprimir una advertencia en todo el proyecto, le recomendamos que haga lo siguiente:

<PropertyGroup>
    <PackageVersion>5.0.0</PackageVersion>
    <NoWarn>$(NoWarn);NU5104</NoWarn>
</PropertyGroup>
<ItemGroup>
    <PackageReference Include="Contoso.Package" Version="1.0.0-beta.1"/>
</ItemGroup>

A veces, las advertencias solo se aplican a un determinado paquete del grafo. Puede optar por suprimir esa advertencia de forma más selectiva agregando un NoWarn elemento en el elemento PackageReference.

<PropertyGroup>
    <PackageVersion>5.0.0</PackageVersion>
</PropertyGroup>
<ItemGroup>
    <PackageReference Include="Contoso.Package" Version="1.0.0-beta.1" NoWarn="NU1603" />
</ItemGroup>

Supresión de advertencias de paquete NuGet en Visual Studio

En Visual Studio, también puede suprimir las advertencias a través del IDE.

Bloqueo de dependencias

Esta característica está disponible con NuGet 4.9 o superior y con Visual Studio 2017 15.9 o superior.

La entrada a la restauración de NuGet es un conjunto de PackageReference elementos del archivo de proyecto (dependencias de nivel superior o directas) y la salida es una recopilación completa de todas las dependencias de los paquetes, incluidas las dependencias transitivas. NuGet intenta siempre producir el mismo cierre completo de dependencias de paquetes si no ha cambiado la lista de referencias de paquetes de entrada. Sin embargo, hay algunos escenarios en los que no puede hacerlo. Por ejemplo:

• Al usar versiones flotantes como ``. Aunque la intención aquí es hacer flotante la última versión de todas las restauraciones de paquetes, hay escenarios en los que los usuarios necesitan que el gráfico se bloquee hacia una versión más reciente determinada y hacen flotante una versión posterior, en caso de estar disponible, en un gesto explícito.

• Se publica una versión más reciente del paquete que coincide con los requisitos de la versión PackageReference. Por ejemplo:

  • Día 1: si especificó <PackageReference Include="My.Sample.Lib" Version="4.0.0"/> , pero las versiones disponibles en los repositorios nuGet eran 4.1.0, 4.2.0 y 4.3.0. En este caso, NuGet habría resuelto la versión 4.1.0 (versión mínima más cercana).

  • Día 2: se publica la versión 4.0.0. NuGet ahora encontrará la coincidencia exacta y empezará a resolverse en 4.0.0.

• Se quita una versión del paquete especificada del repositorio. Aunque nuget.org no permite eliminaciones de paquetes, no todos los repositorios de paquetes tienen esta restricción. Esto hace que NuGet busque la mejor coincidencia cuando no puede resolver la versión eliminada.

Habilitación del archivo de bloqueo

Para conservar el cierre completo de las dependencias del paquete, puede participar en la característica de archivo de bloqueo estableciendo la propiedad RestorePackagesWithLockFile MSBuild para el proyecto:

<PropertyGroup>
    <!--- ... -->
    <RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>
    <!--- ... -->
</PropertyGroup>    

Si se establece esta propiedad, la restauración de NuGet generará un archivo de bloqueo (packages.lock.json) en el directorio raíz del proyecto que muestra todas las dependencias del paquete.

Comportamiento con el archivo de bloqueo

Si un archivo de bloqueo está presente para un proyecto, NuGet usa este archivo de bloqueo para ejecutar restore. NuGet realiza una comprobación rápida para ver si hubo algún cambio en las dependencias del paquete, como se mencionó en el archivo del proyecto (o los archivos de proyectos dependientes), y si no hubo ningún cambio, solo restaura los paquetes mencionados en el archivo de bloqueo. No hay ninguna reevaluación de dependencias de paquetes.

Si NuGet detecta un cambio en las dependencias definidas tal como se menciona en los archivos del proyecto, volverá a evaluar el gráfico del paquete y actualizará el archivo de bloqueo para reflejar el nuevo cierre del paquete para el proyecto.

En CI/CD y otros escenarios, en los que no desearía cambiar las dependencias de paquetes sobre la marcha, puede hacerlo estableciendo el lockedmode a true.

En dotnet.exe,ejecute:

> dotnet.exe restore --locked-mode

En msbuild.exe, ejecute:

> msbuild.exe -t:restore -p:RestoreLockedMode=true

También puede establecer esta propiedad condicional de MSBuild en el archivo del proyecto:

<PropertyGroup>
    <!--- ... -->
    <RestoreLockedMode>true</RestoreLockedMode>
    <!--- ... -->
</PropertyGroup> 

Si el modo de bloqueo es true, la restauración restablecerá los paquetes exactos como se enumeran en el archivo de bloqueo o fallará si ha actualizado las dependencias de paquetes definidas para el proyecto tras crear el archivo de bloqueo.

Bloquear archivos y PrunePackageReference

PrunePackageReference cambia las dependencias de un proyecto mediante la eliminación de paquetes transitivos innecesarios. Aunque la eliminación de estos paquetes no debe tener un impacto en tiempo de ejecución, afectará a los archivos de bloqueo. Si habilita la eliminación para un proyecto existente, siempre que se vuelva a generar el archivo de bloqueo, puede provocar menos paquetes que antes de la eliminación. El archivo de bloqueo actualizado comprueba que el modo bloqueado tiene en cuenta la eliminación, lo que significa que si habilitó la eliminación en un proyecto, la comprobación tendrá en cuenta los paquetes que se eliminan. Sin embargo, la próxima vez que se vuelva a generar el archivo de bloqueo, excluirá los paquetes podados, por lo que es posible que vea una diferencia que sea mayor de lo habitual.

Haga que el archivo de bloqueo forme parte de su repositorio de origen

Si va a compilar una aplicación, un ejecutable y el proyecto en cuestión está al principio de la cadena de dependencias, realice la comprobación del archivo de bloqueo en el repositorio de código fuente para que NuGet pueda usarlo durante la restauración.

Sin embargo, si el proyecto es un proyecto de biblioteca que no envía o un proyecto de código común en el que dependen otros proyectos, no debe proteger el archivo de bloqueo como parte del código fuente. No hay ningún daño al mantener el archivo de bloqueo, pero no se pueden usar las dependencias del paquete bloqueado para el proyecto de código común, como se muestra en el archivo de bloqueo, durante la restauración o compilación de un proyecto que depende de este proyecto de código común.

Example:

ProjectA
  |------> PackageX 2.0.0
  |------> ProjectB
             |------>PackageX 1.0.0

Si ProjectA tiene una dependencia de la versión PackageX de 2.0.0 y también hace referencia a ProjectB, que depende de la versión PackageX de 1.0.0, entonces el archivo de bloqueo para ProjectB mostrará una dependencia de la versión PackageX de 1.0.0. Sin embargo, cuando `ProjectA` se crea, su archivo de bloqueo contendrá una dependencia de `PackageX` versión `2.0.0` y `no` `1.0.0` como se muestra en el archivo de bloqueo para `ProjectB`. Por tanto, el archivo de bloqueo de un proyecto de código común tiene poco que decir sobre los paquetes resueltos para los proyectos que dependen de él.

Extensibilidad del archivo de bloqueo

Puede controlar diversos comportamientos de la restauración con el archivo de bloqueo como se describe a continuación:

Solucionador de dependencias de NuGet

El solucionador de dependencias de NuGet sigue las cuatro reglas como se describe en el documento de resolución de dependencias.

Para mejorar el rendimiento y la escalabilidad de la operación de restauración, el algoritmo de restauración se reescribió en la versión 6.12. A partir de la versión 6.12, el nuevo algoritmo de restauración está habilitado de manera predeterminada para todos los proyectos PackageReference. Aunque el nuevo algoritmo de restauración es funcionalmente equivalente al anterior, como sucede con cualquier software, los errores son posibles. Para revertir a la implementación anterior, establezca la propiedad de MSBuild RestoreUseLegacyDependencyResolver en true.

Si enfrenta fallos de restauración en las versiones 6.12, .NET 9 o 17.12, que no ocurrían en versiones anteriores, por favor envíe una incidencia en GitHub. Las diferencias entre los algoritmos antiguos y nuevos pueden tener diferentes impactos, como durante la compilación o en tiempo de ejecución. También existe la posibilidad de que los cambios no produzcan errores, pero se restauran versiones de paquetes diferentes. Si cree que podría verse afectado por cualquier cambio, estos son los pasos que puede seguir para comprobar si los cambios en el algoritmo de restauración de NuGet son la causa principal.

Restaurar escribe sus resultados en el directorio MSBuildProjectExtensionsPath, que se pueden comparar con los algoritmos nuevos y antiguos para encontrar diferencias. Normalmente, esta es la carpeta obj de la compilación. Puede usar msbuild.exe o dotnet.exe para los pasos siguientes.

1. Elimine la carpeta obj para su proyecto.

2. Ejecute msbuild -t:restore:

3. Guarde el contenido de obj en una ubicación que indique que es el comportamiento new.

4. Ejecute msbuild -t:restore -p:RestoreUseLegacyDependencyResolver="true".

5. Guarde el contenido de obj en una ubicación que indique que es el comportamiento legacy.

6. Compare los archivos de los dos directorios, especialmente project.assets.json.

   Las herramientas que pueden resaltar las diferencias son especialmente útiles para esto (por ejemplo, en Visual Studio Code, abra ambos archivos y use el clic con el botón derecho "seleccionar para comparar" y "comparar con seleccionado").

Si sigue el método anterior, debería haber exactamente una diferencia entre los archivos project.assets.json:

      "projectStyle": "PackageReference",
+     "restoreUseLegacyDependencyResolver": true,
      "fallbackFolders": [

Si nota más diferencias, envíe un informe de problemas en GitHub con todos los detalles.

AssetTargetFallback

La propiedad AssetTargetFallback permite especificar versiones adicionales del marco compatibles para los proyectos que su proyecto referencia y los paquetes NuGet que utiliza.

Si especifica una dependencia de paquete mediante PackageReference, pero ese paquete no contiene recursos compatibles con el marco de trabajo objetivo de su proyecto, entra en juego la propiedad AssetTargetFallback. La compatibilidad del paquete al que se hace referencia se vuelve a comprobar con cada plataforma de destino que se especifica en AssetTargetFallback. Cuando se hace referencia a un project o un package mediante AssetTargetFallback, se generará la advertencia NU1701.

Consulte la tabla siguiente para ver ejemplos de cómo afecta AssetTargetFallback a la compatibilidad.

Se pueden especificar varios marcos mediante ; como delimitador. Para agregar un marco de contingencia, puede hacer lo siguiente:

<AssetTargetFallback Condition=" '$(TargetFramework)'=='netcoreapp3.1' ">
    $(AssetTargetFallback);net472;net471
</AssetTargetFallback>

Puede excluir $(AssetTargetFallback) si quiere sobrescribirlo, en lugar de agregarlo a los valores AssetTargetFallback existentes.

PrunePackageReference

El entorno de ejecución de .NET evoluciona constantemente, con mejoras de rendimiento y nuevas API en cada versión. Las nuevas características agregadas a .NET también se proporcionan a veces como paquetes, de modo que los desarrolladores que usan marcos de destino más antiguos puedan usar la biblioteca, como System.Text.Json. Esto a menudo puede provocar un System.Text.Json 8.0.0 en un proyecto destinado a .NET 9 o .NET 8. Esta dependencia no es necesaria y la resolución de conflictos de compilación no usaría el ensamblado procedente del paquete, ya que ya está disponible en el entorno de ejecución de .NET. A partir de la versión 6.13 de NuGet y el SDK de .NET 9.0.200, PrunePackageReference habilita la eliminación de estos paquetes en tiempo de restauración para proyectos basados en sdk de .NET. La primera iteración del recorte de paquetes afectó solo a los paquetes transitivos, pero a partir del SDK de .NET 10, el recorte de paquetes también afecta a los paquetes directos.

La eliminación de paquetes está disponible como característica de participación con el SDK de .NET 9 y está habilitada de forma predeterminada para todos los marcos de un proyecto destinado >= .NET 10.0 al SDK de .NET 10.

La eliminación de paquetes solo está disponible con la resolución de dependencias predeterminada tal como se lanzó en la versión 6.12.

Especificación PrunePackageReference

La lista de paquetes que se van a eliminar se define con el elemento PrunePackageReference.

Las siguientes propiedades se pueden usar para modificar el comportamiento de eliminación.

El SDK de .NET predefine la lista de paquetes que se van a recortar.

Funcionamiento de PrunePackageReference

Cuando se especifica un paquete que se va a eliminar durante la restauración, se quita del gráfico de dependencias. Cuando se elimina un paquete, hay un mensaje, visible en detalle detallado, que indica que el paquete se ha quitado para la plataforma de destino especificada.

En el caso de los paquetes transitivos, lo que significa dependencias de otros paquetes o proyectos, los paquetes no se descargan y no aparecen en ninguna de las salidas de NuGet.

En el caso de los paquetes directos, PrivateAssets='all' y IncludeAssets='none' se aplican implícitamente.

• IncludeAssets='none' garantiza que los ensamblajes de este paquete no se usen durante la construcción. Antes de que existiera la eliminación, la resolución de conflictos durante la compilación garantizaba que los ensamblados de plataforma se preferían sobre los procedentes de los paquetes.
• PrivateAssets='all' garantiza que los paquetes no se incluyan en otros paquetes ni mediante referencias de proyecto.

Example:

Un proyecto como el siguiente:

  <PropertyGroup>
    <TargetFrameworks>net9.0;netstandard2.0</TargetFrameworks>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="System.Text.Json" Version="9.0.4" />
  </ItemGroup>

tendrá un archivo "nuspec" con las siguientes dependencias:

<dependencies>
    <group targetFramework=".NETFramework4.7.2">
        <dependency id="System.Text.Json" version="9.0.4" />
    </group>
    <group targetFramework="net9.0">
    </group>
</dependencies>

Cuando se pueda quitar completamente una referencia directa de PackageReference de tu proyecto, y uno de los marcos de proyecto es .NET 10 o posterior, se generará NU1510 solicitándote que elimines el paquete. Si sigue esta sugerencia, se reducirá la complejidad del grafo del proyecto.

En la tabla siguiente se resumen todos los comportamientos de eliminación de paquetes.

Aplicaciones PrunePackageReference

Las ventajas de la poda de paquetes son dobles.

• Ventajas de rendimiento, en virtud de la reducción del número de paquetes dentro de un gráfico de dependencias
• Reducción de falsos positivos mediante analizadores de componentes, como NuGetAudit

La eliminación es especialmente valiosa al auditar paquetes con establecido en NuGetAuditModeall. Si usa .NET 9, se recomienda probar la eliminación estableciendo en RestoreEnablePackagePruningtrue.