Novedades del SDK y las herramientas para .NET 8

En este artículo se describen las nuevas características del SDK y las herramientas de .NET para .NET 8.

SDK

Esta sección contiene los subtemas siguientes:

• Evaluación del proyecto basado en la CLI
• Salida de compilación del terminal
• Rutas de salida simplificadas
• Comando "dotnet workload clean"
• Recursos "dotnet publish" y "dotnet pack"
• Motor de plantillas
• Vínculo de origen
• SDK de compilación de origen

Evaluación del proyecto basado en la CLI

MSBuild incluye una nueva característica que facilita la incorporación de datos de MSBuild a los scripts o herramientas. Las siguientes marcas nuevas están disponibles para los comandos de la CLI, como dotnet publish, para obtener datos para su uso en canalizaciones de CI y en otros lugares.

Marca	Descripción
--getProperty:<PROPERTYNAME>	Recupera la propiedad MSBuild con el nombre especificado.
--getItem:<ITEMTYPE>	Recupera elementos de MSBuild del tipo especificado.
--getTargetResults:<TARGETNAME>	Recupera las salidas de la ejecución del destino especificado.

Los valores se escriben en la salida estándar. Los valores múltiples o complejos se generan como JSON, como se muestra en los ejemplos siguientes.

>dotnet publish --getProperty:OutputPath
bin\Release\net8.0\

>dotnet publish -p PublishProfile=DefaultContainer --getProperty:GeneratedContainerDigest --getProperty:GeneratedContainerConfiguration
{
  "Properties": {
    "GeneratedContainerDigest": "sha256:ef880a503bbabcb84bbb6a1aa9b41b36dc1ba08352e7cd91c0993646675174c4",
    "GeneratedContainerConfiguration": "{\u0022config\u0022:{\u0022ExposedPorts\u0022:{\u00228080/tcp\u0022:{}},\u0022Labels\u0022...}}"
  }
}

>dotnet publish -p PublishProfile=DefaultContainer --getItem:ContainerImageTags
{
  "Items": {
    "ContainerImageTags": [
      {
        "Identity": "latest",
        ...
    ]
  }
}

Salida de compilación del terminal

dotnet build tiene una nueva opción para generar una salida de compilación más moderna. Esta salida del registrador de terminal agrupa los errores con el proyecto del que proceden, diferencia mejor las distintas plataformas de destino para los proyectos de varios destinos y proporciona información en tiempo real sobre lo que está haciendo la compilación. Para optar por la nueva salida, use la opción --tl. Para obtener más información sobre esta opción, consulte Opciones de compilación de dotnet.

Rutas de salida simplificadas

.NET 8 presenta una opción para simplificar la ruta de salida y la estructura de carpetas para las salidas de compilación. Anteriormente, las aplicaciones .NET generaban un conjunto profundo y complejo de rutas de salida para distintos artefactos de compilación. Con la nueva estructura de ruta de salida simplificada, todas las salidas de compilación se recopilan en una ubicación común, lo que facilita que las herramientas las encuentren.

Para obtener más información, consulte diseño de salida artefactos.

El comando dotnet workload clean

.NET 8 presenta un comando nuevo para limpiar los paquetes de cargas de trabajo que podrían quedar después de varias actualizaciones del SDK de .NET o Visual Studio. Si tiene problemas al administrar cargas de trabajo, considere la posibilidad de usar workload clean para restaurar de manera segura a un estado conocido antes de volver a intentarlo. El comando tiene dos funciones:

• dotnet workload clean

  Ejecuta la recolección de elementos no utilizados de carga de trabajo para cargas de trabajo basadas en archivos o basadas en MSI, que limpia los paquetes huérfanos. Los paquetes huérfanos proceden de versiones desinstaladas del SDK de .NET o paquetes en los que ya no existen registros de instalación para el paquete.

  Si Visual Studio está instalado, el comando también muestra las cargas de trabajo que debe limpiar manualmente con Visual Studio.

• dotnet workload clean --all

  Este modo es más agresivo y limpia todos los paquetes de la máquina que tiene el tipo de instalación de carga de trabajo del SDK actual (que no es de Visual Studio). También quita todos los registros de instalación de carga de trabajo para la banda de características del SDK de .NET en ejecución e inferiores.

Recursos dotnet publish y dotnet pack

Dado que los comandos dotnet publish y dotnet pack están diseñados para generar recursos de producción, ahora generan recursos Release de forma predeterminada.

En la salida siguiente se muestra el comportamiento diferente entre dotnet build y dotnet publish, y cómo se puede revertir a la publicación de recursos Debug estableciendo la propiedad PublishRelease en false.

/app# dotnet new console
/app# dotnet build
  app -> /app/bin/Debug/net8.0/app.dll
/app# dotnet publish
  app -> /app/bin/Release/net8.0/app.dll
  app -> /app/bin/Release/net8.0/publish/
/app# dotnet publish -p:PublishRelease=false
  app -> /app/bin/Debug/net8.0/app.dll
  app -> /app/bin/Debug/net8.0/publish/

Para obtener más información, vea "dotnet pack" usa la configuración Release y "dotnet publish" usa la configuración Release.

Auditoría de seguridad de dotnet restore

A partir de .NET 8, puede optar por comprobar si hay vulnerabilidades conocidas cuando se restauran los paquetes de dependencia. Esta auditoría genera un informe de vulnerabilidades de seguridad con el nombre del paquete afectado, la gravedad de la vulnerabilidad y un vínculo a la advertencia para obtener más detalles. Al ejecutar dotnet add o dotnet restore, aparecerán advertencias NU1901-NU1904 para las vulnerabilidades que se encuentren. Para obtener más información, consulte Auditoría de vulnerabilidades de seguridad.

Motor de plantillas

El motor de plantillas proporciona una experiencia más segura en .NET 8 mediante la integración de algunas de las características relacionadas con la seguridad de NuGet. Estas mejoras incluyen:

• Impedir la descarga de paquetes de fuentes http:// de forma predeterminada. Por ejemplo, el siguiente comando no podrá instalar el paquete de plantilla porque la dirección URL de origen no usa HTTPS.

  dotnet new install console --add-source "http://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-public/nuget/v3/index.json"

  Puede invalidar esta limitación mediante la marca --force.

• Para dotnet new, dotnet new install y dotnet new update, compruebe si hay vulnerabilidades conocidas en el paquete de plantillas. Si se encuentran vulnerabilidades y quiere continuar, debe usar la marca --force.

• Para dotnet new, proporcione información sobre el propietario del paquete de plantilla. El portal de NuGet comprueba la titularidad y se puede considerar una característica de confianza.

• Para dotnet search y dotnet uninstall, indique si una plantilla está instalada desde un paquete que es "de confianza", es decir, usa un prefijo reservado.

SourceLink

Source Link ahora se incluye en el SDK de .NET. El objetivo es que, al agrupar Source Link en el SDK, en vez de requerir un elemento <PackageReference> independiente para el paquete, más paquetes incluyan esta información de forma predeterminada. Esta información mejorará la experiencia del IDE para los desarrolladores.

Nota:

Como efecto secundario de este cambio, la información de confirmación se incluye en el valor InformationalVersion de las bibliotecas y aplicaciones compiladas, incluso las que tienen como destino .NET 7 o una versión anterior. Para obtener más información, consulte Source Link incluido en el SDK de .NET.

SDK de compilación de origen

El SDK integrado en la distribución de Linux (compilación de origen) ahora puede compilar aplicaciones autocontenidas mediante los paquetes del entorno de ejecución de compilación de origen. El paquete del entorno de ejecución específico de la distribución se agrupa con el SDK de compilación de origen. Durante una implementación independiente, se hará referencia a este paquete del entorno de ejecución agrupado, lo que habilitará la característica para los usuarios.

Compatibilidad con AOT nativo

La opción para publicar como AOT nativa se introdujo por primera vez en .NET 7. La publicación de una aplicación con AOT nativa crea una versión totalmente independiente de la aplicación que no necesita un entorno de ejecución; todo se incluye en un único archivo. .NET 8 aporta las siguientes mejoras a la publicación de AOT nativa:

• Agrega compatibilidad con las arquitecturas x64 y Arm64 en macOS.

• Reduce el tamaño de las aplicaciones de AOT nativa en Linux hasta un 50 %. En la siguiente tabla se muestra el tamaño de una aplicación "Hola mundo" publicada con AOT nativa que incluye todo el entorno de ejecución de .NET en .NET 7 frente a .NET 8:

  Sistema operativo	.NET 7	.NET 8
  Linux x64 (con -p:StripSymbols=true)	3,76 MB	1,84 MB
  Windows x64	2,85 MB	1,77 MB

• Permite especificar una preferencia de optimización: tamaño o velocidad. De forma predeterminada, el compilador elige generar código rápido, pero teniendo en cuenta el tamaño de la aplicación. Sin embargo, puede usar la propiedad <OptimizationPreference> de MSBuild para optimizar específicamente para una u otra. Para obtener más información, consulte Optimización de implementaciones de AOT.

Plantilla de aplicación de consola

La plantilla de aplicación de consola predeterminada ahora incluye compatibilidad con AOT lista para usar. Para crear un proyecto configurado para la compilación AOT, simplemente ejecute dotnet new console --aot. La configuración del proyecto agregada por --aot tiene tres efectos:

• Genera un archivo ejecutable independiente nativo con AOT nativa al publicar el proyecto, por ejemplo, con dotnet publish o Visual Studio.
• Habilita los analizadores de compatibilidad para recortar, AOT y un único archivo. Estos analizadores le alertan de las partes potencialmente problemáticas del proyecto (si hay alguna).
• Habilita la emulación en tiempo de depuración de AOT para que, al depurar el proyecto sin compilación AOT, obtenga una experiencia similar a AOT. Por ejemplo, si usa System.Reflection.Emit en un paquete NuGet que no se ha anotado para AOT (y, por lo tanto, el analizador de compatibilidad lo ha ignorado), la emulación significa que no se encontrará ninguna sorpresa al intentar publicar el proyecto con AOT.

Plataformas de destino similares a iOS con AOT nativa

.NET 8 inicia el trabajo para habilitar la compatibilidad de la AOT nativa con plataformas similares a iOS. Ahora puede compilar y ejecutar aplicaciones .NET iOS y .NET MAUI con la AOT nativa en las siguientes plataformas:

• ios
• iossimulator
• maccatalyst
• tvos
• tvossimulator

Las pruebas preliminares muestran que el tamaño de la aplicación en el disco disminuye aproximadamente un 35 % para las aplicaciones .NET iOS que usan AOT nativo en lugar de Mono. El tamaño de la aplicación en el disco para aplicaciones de .NET MAUI para iOS disminuye hasta un 50 %. Además, el tiempo de inicio también es más rápido. Las aplicaciones de .NET iOS tienen aproximadamente un 28 % más rápido de tiempo de inicio, mientras que las aplicaciones de .NET MAUI iOS tienen aproximadamente un 50 % mejor rendimiento de inicio en comparación con Mono. La compatibilidad con .NET 8 es experimental y solo el primer paso para la característica en su conjunto. Para obtener más información, consulte la entrada de blog mejoras de rendimiento de .NET 8 en .NET MAUI.

La compatibilidad de la AOT nativa está disponible como una característica de participación destinada a la implementación de aplicaciones; Mono sigue siendo el entorno de ejecución predeterminado para el desarrollo y la implementación de aplicaciones. Para compilar y ejecutar una aplicación .NET MAUI con la AOT nativa en un dispositivo iOS, use dotnet workload install maui para instalar la carga de trabajo de .NET MAUI y dotnet new maui -n HelloMaui para crear la aplicación. A continuación, establezca la propiedad MSBuild PublishAot a true en el archivo del proyecto.

<PropertyGroup>
  <PublishAot>true</PublishAot>
</PropertyGroup>

Al establecer la propiedad necesaria y ejecutar dotnet publish como se muestra en el ejemplo siguiente, la aplicación se implementará mediante AOT nativo.

dotnet publish -f net8.0-ios -c Release -r ios-arm64  /t:Run

Limitaciones

No todas las características de iOS son compatibles con la AOT nativa. Del mismo modo, no todas las bibliotecas que se suelen usar en iOS son compatibles con la AOT nativa. Además de las limitaciones de la implementación de la AOT nativa existentes, en la lista siguiente se muestran algunas de las otras limitaciones al dirigirse a plataformas similares a iOS:

• El uso de AOT nativa solo está habilitado durante la implementación de la aplicación (dotnet publish).
• La depuración de código administrado solo se admite con Mono.
• La compatibilidad con el marco MAUI de .NET es limitada.

Compilación AOT para aplicaciones Android

Para reducir el tamaño de la aplicación, las aplicaciones .NET y .NET MAUI que tienen como destino Android usan el modo de compilación anticipada (AOT) con perfiles cuando están integradas en modo de versión. La compilación AOT con perfiles afecta a menos métodos que la compilación AOT normal. .NET 8 presenta la propiedad <AndroidStripILAfterAOT> que permite optar por una compilación AOT adicional para aplicaciones Android para reducir aún más el tamaño de la aplicación.

<PropertyGroup>
  <AndroidStripILAfterAOT>true</AndroidStripILAfterAOT>
</PropertyGroup>

De forma predeterminada, configurar AndroidStripILAfterAOT en true invalida la configuración predeterminada AndroidEnableProfiledAot, lo que permite recortar (casi) todos los métodos compilados AOT. También puede usar AOT con perfiles y la eliminación de IL conjuntamente estableciendo explícitamente ambas propiedades en true:

<PropertyGroup>
  <AndroidStripILAfterAOT>true</AndroidStripILAfterAOT>
  <AndroidEnableProfiledAot>true</AndroidEnableProfiledAot>
</PropertyGroup>

Compilación cruzada de aplicaciones de Windows

Al compilar aplicaciones destinadas a Windows en plataformas que no son de Windows, el ejecutable resultante ahora se actualiza con cualquier recurso Win32 especificado, por ejemplo, el icono de aplicación, el manifiesto, la información de versión.

Anteriormente, las aplicaciones tenían que compilarse en Windows para tener estos recursos. La corrección de esta brecha en la compatibilidad entre compilaciones ha sido una solicitud popular, ya que era un aspecto importante que afectaba tanto a la complejidad de la infraestructura como al uso de recursos.

.NET en Linux

Líneas base de compatibilidad mínima para Linux

Se han actualizado las líneas base de compatibilidad mínima para Linux en .NET 8. .NET se compila para Ubuntu 16.04 en todas las arquitecturas. Esto es especialmente importante para definir la versión mínima de glibc para .NET 8. .NET 8 no se iniciará en versiones de distribución que incluyan un glibc anterior, como Ubuntu 14.04 o Red Hat Enterprise Linux 7.

Para obtener más información, consulte Compatibilidad con la familia Red Hat Enterprise Linux.

Compilación de su propio .NET en Linux

En versiones anteriores de .NET, podía compilar .NET desde un origen, pero era necesario crear un "tarball de origen" a partir de la confirmación del repositorio dotnet/installer correspondiente a una versión. En .NET 8, esto ya no es necesario y puede compilar .NET en Linux directamente desde el repositorio dotnet/dotnet. Ese repositorio usa dotnet/source-build para compilar entornos de ejecución, herramientas y SDK de .NET. Esta es la misma compilación que usan Red Hat y Canonical para compilar .NET.

La compilación en un contenedor es el enfoque más sencillo para la mayoría de las personas, ya que las imágenes de contenedor dotnet-buildtools/prereqs contienen todas las dependencias necesarias. Para obtener más información, vea las instrucciones de compilación.

Verificación de firmas de NuGet

A partir de .NET 8, NuGet comprueba los paquetes firmados en Linux de forma predeterminada. NuGet continúa comprobando también los paquetes firmados en Windows.

La mayoría de los usuarios no deberían percatarse de la comprobación. Sin embargo, si tiene un conjunto de certificados raíz existente ubicado en /etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem, es posible que vea errores de confianza acompañados de la advertencia NU3042.

Puede optar por no realizar la comprobación estableciendo la variable de entorno DOTNET_NUGET_SIGNATURE_VERIFICATION en false.

Análisis de código

.NET 8 incluye varios analizadores de código nuevos y correcciones para ayudar a comprobar que las API de la biblioteca de .NET se usan de forma correcta y eficaz. En la tabla siguiente se resumen los nuevos analizadores.

Id. de regla	Category	Descripción
CA1856	Rendimiento	Se desencadena cuando el atributo ConstantExpectedAttribute no se aplica correctamente en un parámetro.
CA1857	Rendimiento	Se desencadena cuando un parámetro se anota con el atributo ConstantExpectedAttribute, pero el argumento proporcionado no es una constante.
CA1858	Rendimiento	Para determinar si una cadena comienza con un prefijo determinado, es mejor llamar a String.StartsWith que llamar a String.IndexOf y comparar el resultado con cero.
CA1859	Rendimiento	Esta regla recomienda actualizar el tipo de variables locales específicas, campos, propiedades, parámetros de método y tipos devueltos de métodos de tipos de interfaz o tipos abstractos a tipos concretos cuando sea posible. El uso de tipos concretos genera código de mayor calidad.
CA1860	Rendimiento	Para determinar si un tipo de colección tiene elementos, es mejor usar Length, Count o IsEmpty que llamar a Enumerable.Any.
CA1861	Rendimiento	Las matrices constantes que se pasan como argumentos no se reutilizan cuando se las llama repetidamente, lo que implica que se crea una matriz cada vez. Para mejorar el rendimiento, considere la posibilidad de extraer la matriz en un campo de solo lectura estático.
CA1865-CA1867	Rendimiento	La sobrecarga de char es una sobrecarga de mejor rendimiento para una cadena con un único char.
CA2021	Confiabilidad	Enumerable.Cast<TResult>(IEnumerable) y Enumerable.OfType<TResult>(IEnumerable) requieren tipos compatibles para funcionar correctamente. Las conversiones de ampliación y definidas por el usuario no se admiten con tipos genéricos.
CA1510-CA1513	Capacidad de mantenimiento	Los asistentes de inicio son más sencillos y eficaces que un bloque if que construye una nueva instancia de excepción. Estos cuatro analizadores se crearon para estas excepciones: ArgumentNullException, ArgumentException, ArgumentOutOfRangeException y ObjectDisposedException.

Diagnóstico

Recarga activa de C# admite la modificación de genéricos

A partir de .NET 8, Recarga activa de C# admite la modificación de tipos y métodos genéricos. Al depurar aplicaciones de consola, de escritorio, móviles o WebAssembly con Visual Studio, puede aplicar cambios a clases genéricas y métodos genéricos en código de C# o páginas de Razor. Para obtener más información, consulte la lista completa de ediciones admitidas por Roslyn.

Consulte también

• Novedades de .NET 8