0

.Net 6 Preview 4

Publicada en por Fernando Sonego

Este 25 de mayo se lanzó la nueva preview 4 de .Net 6. Esta versión preview 4 establece una base sólida para la versión final  de .NET 6 en noviembre de este mismo año, con características y experiencias finales. También está listo para pruebas en el mundo real si aún no ha probado .NET 6 en su entorno.‎

Se confirma la fecha final de lanzamiento que será del 9 al 11 de noviembre en la ‎‎.NET Conf 2021‎‎. Se lanzara oficialmente.NET 6 el día 9 donde habrán muchas charlas y demos en profundidad con todo lo nuevo que viene en .NET 6.‎

Si quieres comenzar a probar desde ahora puedes ‎‎descargar .NET 6 Preview 4‎‎‎‎ para Linux, macOS y Windows.‎

‎.NET 6 se ha probado con ‎‎Visual Studio 16.11‎‎ y ‎‎Visual Studio para Mac 8.9‎‎. El equipo usar esas versiones si deseamos probar .NET 6 con ‎‎Visual Studio‎‎.‎

Build 2021‎

‎Esta semana se realizará la ‎‎conferencia Microsoft Build conference  Es gratis y se transmite en la web. Tampoco es necesario registrarse‎.

Puedes consultar algunas de las charlas que se  incluirán sobre .NET 6 y demos que estarán en el evento:

‎Unificación de la plataforma .NET‎

‎Hemos hablado mucho en publicaciones anteriores y en conferencias sobre ‎‎la unificación de .NET‎‎, pero falta en los temas. La unificación de la plataforma está integrada en todo lo que hacemos y no tiene necesidad de su propio tema. Uno puede pensar que es el único mega-tema por encima y más allá de los que se enumeran. Se intercala a través de múltiples de los temas y es una suposición básica del equipo en el futuro.‎

‎El ‎‎proyecto de rendimiento de bucle interno‎‎ es un gran ejemplo. Se supone que todas las aplicaciones de .NET 6 comparten la misma base, por ejemplo, con el mismo sistema de compilación y bibliotecas. Cuando hay una diferencia técnica, como el uso de un tiempo de ejecución diferente (CoreCLR o Mono) o una técnica de generación de código (AOT o JIT), tomamos esas cosas en cuenta y ofrecemos experiencias pragmáticas y apropiadas, con un sesgo a ninguna diferencia de experiencia observable. El ‎‎proyecto EventPipe‎‎ es otro ejemplo similar.‎

‎Confianza en la producción‎

‎Pronto comenzaremos a lanzar compilaciones «en vivo» que son compatibles con la producción. Actualmente estamos apuntando a agosto para eso. Nuestro modelo de desarrollo está orientado a permitir cargas de trabajo de producción, incluso mientras estamos terminando de trabajar en todos los temas que acabamos de mencionar.‎

‎La confianza en la producción comienza con el ‎‎sitio de dotnet.microsoft.com‎‎. Ha estado ejecutando la mitad de su carga de sitio en .NET 6 a partir de Preview 1. Si bien no es a gran escala, es un sitio de misión crítica para nuestro equipo y lo tomamos muy en serio. .NET 6 ha estado trabajando para nosotros como un campeón.‎

‎También trabajamos con equipos de Microsoft que implementan sus aplicaciones de producción en vistas previas de .NET. Lo hacen para poder aprovechar las nuevas características de .NET desde el principio. Estos equipos siempre están buscando oportunidades para reducir sus costos de alojamiento en la nube, y la implementación de nuevas versiones de .NET ha demostrado ser uno de los enfoques más efectivos y de menor esfuerzo para eso. Estos equipos nos dan retroalimentación temprana que nos ayuda a garantizar que las nuevas características estén listas para el uso de producción global. También influyen significativamente en la forma de la característica final porque son nuestros primeros usuarios de producción.‎

‎Todas estas primeras pruebas de batalla con aplicaciones del mundo real aumentan nuestra confianza en que .NET 6 estará listo para ejecutar su aplicación.‎

‎El resto de la publicación está dedicada a las características que son nuevas en la vista previa 4.‎

‎Herramientas: Hot Reload con el depurador de Visual Studio y dotnet CLI‎ 

‎Hot Reload es una nueva experiencia que le permite realizar ediciones en el código fuente de su aplicación mientras se ejecuta sin necesidad de pausar manualmente la aplicación o alcanzar un punto de interrupción. Esta herramienta mejora la productividad del desarrollador al reducir el número de veces que necesita reiniciar la aplicación en ejecución.‎

‎Con esta versión, Hot Reload funciona para muchos tipos de aplicaciones, como WPF, Windows Forms, WinUI, ASP.NET, aplicaciones de consola y otros marcos que se ejecutan sobre el tiempo de ejecución de CoreCLR. También están trabajando para llevar esta tecnología a las aplicaciones WebAssembly, iOS y Android que se ejecutan sobre Mono, pero esto todavía está un poco verde‎.

‎Para probar esta característica, debemos tener instalado ‎‎Visual Studio 2019 versión 16.11 Preview 1‎‎ e iniciar la aplicación con el depurador de Visual Studio (F5). Una vez que la aplicación se esté ejecutando, ahora tendremos la nueva opción de realizar cambios en el código y aplicarlos con el nuevo botón «aplicar cambios de código» como se ve a continuación.‎

‎Hot Reload también está disponible a través de la herramienta dotnet watch.

Para más información puede leer ad, puede leer ‎‎ Introducing .NET Hot Reload.

‎Compatibilidad con System.Text.Json para IAsyncEnumerable‎

IAsyncEnumerable<T>‎ es una característica importante que vino con .NET Core 3.0 y C# 8. Las ‎‎nuevas mejoras‎‎ permiten la (des)serialización con objetos ‎System.Text.JsonIAsyncEnumerable<T>

‎En los ejemplos siguientes podemos ver secuencias como representación de cualquier origen de datos asincrónico. El origen podría ser archivos en un equipo local o resultados de una consulta de base de datos o una llamada a la API de servicio web.‎

‎Serialización en streaming‎

‎System.Text.Json ahora admite la serialización de valores como matrices JSON, como puede ver en el siguiente ejemplo.‎IAsyncEnumerable<T>.

using System;
using System.Collections.Generic;
using System.IO;
using System.Text.Json;

static async IAsyncEnumerable<int> PrintNumbers(int n)
{
    for (int i = 0; i < n; i++) yield return i;
}

using Stream stream = Console.OpenStandardOutput();
var data = new { Data = PrintNumbers(3) };
await JsonSerializer.SerializeAsync(stream, data); // prints {"Data":[0,1,2]}

IAsyncEnumerable‎ los valores solo se admiten mediante los métodos de serialización asincrónica. si Intentamos serializar usando los métodos sincrónicos resultará en una llamada ‎NotSupportedException

‎Deserialización de streaming‎

‎La deserialización por streaming requería una nueva API que devolviera . Se agrego el método para este propósito, como puede ver en el siguiente ejemplo.‎IAsyncEnumerable<T>JsonSerializer.DeserializeAsyncEnumerable.

using System;
using System.IO;
using System.Text;
using System.Text.Json;

var stream = new MemoryStream(Encoding.UTF8.GetBytes("[0,1,2,3,4]"));
await foreach (int item in JsonSerializer.DeserializeAsyncEnumerable<int>(stream))
{
    Console.WriteLine(item);
}

En el ejemplo, se deserializar elementos bajo demanda y puede ser útil cuando se consumen flujos de datos particularmente grandes. Solo admite la lectura de matrices JSON a nivel de raíz, pero esto podría mejorarse en el futuro.

‎El método existente está soportado nominalmente , pero dentro de los límites de su firma de método no streaming. Debe devolver el resultado final como un único valor, como se puede ver en el siguiente ejemplo ‎DeserializeAsyncIAsyncEnumerable<T>.

using System;
using System.Collections.Generic;
using System.IO;
using System.Text;
using System.Text.Json;

var stream = new MemoryStream(Encoding.UTF8.GetBytes(@"{""Data"":[0,1,2,3,4]}"));
var result = await JsonSerializer.DeserializeAsync<MyPoco>(stream);
await foreach (int item in result.Data)
{
    Console.WriteLine(item);
}

public class MyPoco
{
    public IAsyncEnumerable<int> Data { get; set; }
}

‎En este ejemplo, el deserializadohabrá almacenado en búfer todo el contenido de la memoria antes de devolver el objeto deserializado. Esto se debe a que el deserializador debe haber consumido todo el valor JSON antes de devolver un resultado ‎IAsyncEnumerable.

‎System.Text.Json: Función DOM grabable‎

‎La ‎‎característica JSON DOM grabable‎‎ agrega un nuevo modelo de programación sencillo y de alto rendimiento para esta nueva API. Evita la complejidad y los pasos de serialización y el costo tradicional de un DOM con ‎System.Text.Json.

  • ‎Una alternativa ligera a la serialización para los casos en que el uso de tipos POCO no es posible o deseado, o cuando un esquema JSON no está fijo y debe ser inspeccionado.‎
  • ‎Permite la modificación eficiente de un subconjunto de un árbol grande. Por ejemplo, es posible navegar de manera eficiente a una subsección de un árbol JSON grande y leer una matriz o deserializar un POCO de esa subsección. LINQ también se puede usar con eso.‎
  • ‎Habilita el uso de la palabra clave C#, que permite un modelo de tipo flexible y más parecido a un script.‎dynamic

API DOM grabables‎ Tipos:

namespace System.Text.Json.Node
{
    public abstract class JsonNode {...};
    public sealed class JsonObject : JsonNode, IDictionary<string, JsonNode?> {...}
    public sealed class JsonArray : JsonNode, IList<JsonNode?> {...};
    public abstract class JsonValue : JsonNode {...};
}

‎‎Código de ejemplo‎

‎En el ejemplo siguiente se muestra el nuevo modelo de programación.‎

    // Parse a JSON object
    JsonNode jNode = JsonNode.Parse("{"MyProperty":42}");
    int value = (int)jNode["MyProperty"];
    Debug.Assert(value == 42);
    // or
    value = jNode["MyProperty"].GetValue<int>();
    Debug.Assert(value == 42);

    // Parse a JSON array
    jNode = JsonNode.Parse("[10,11,12]");
    value = (int)jNode[1];
    Debug.Assert(value == 11);
    // or
    value = jNode[1].GetValue<int>();
    Debug.Assert(value == 11);

    // Create a new JsonObject using object initializers and array params
    var jObject = new JsonObject
    {
        ["MyChildObject"] = new JsonObject
        {
            ["MyProperty"] = "Hello",
            ["MyArray"] = new JsonArray(10, 11, 12)
        }
    };

    // Obtain the JSON from the new JsonObject
    string json = jObject.ToJsonString();
    Console.WriteLine(json); // {"MyChildObject":{"MyProperty":"Hello","MyArray":[10,11,12]}}

    // Indexers for property names and array elements are supported and can be chained
    Debug.Assert(jObject["MyChildObject"]["MyArray"][1].GetValue<int>() == 11);

Mejoras de System.Linq‎

‎Se han agregado ‎‎nuevas funcionalidades a la  API de System.LINQ‎‎ solicitadas y aportadas por la comunidad.‎

‎Compatibilidad enumerable y parámetros‎ IndexRange

‎El método ahora acepta índices del final del enumerable, como puede ver en el ejemplo siguiente.‎Enumerable.ElementAt.

Enumerable.Range(1, 10).ElementAt(^2); // returns 9

‎Se añadió una sobrecarga que acepta diferentes parámetros. Simplifica la toma de segmentos de secuencias enumerables:‎Enumerable.TakeRange

  • source.Take(..3)‎ en lugar de ‎source.Take(3)
  • source.Take(3..)‎ en lugar de ‎source.Skip(3)
  • source.Take(2..7)‎ en lugar de ‎source.Take(7).Skip(2)
  • source.Take(^3..)‎ en lugar de ‎source.TakeLast(3)
  • source.Take(..^3)‎ en lugar de ‎source.SkipLast(3)
  • source.Take(^7..^3)‎ en lugar de.‎source.TakeLast(7).SkipLast(3)
TryGetNonEnumeratedCount

‎El método intenta obtener el recuento del origen enumerable sin forzar una enumeración. Este enfoque puede ser útil en escenarios en los que es útil preasignar búferes antes de la enumeración, como puede ver en el ejemplo siguiente.‎TryGetNonEnumeratedCount.

List<T> buffer = source.TryGetNonEnumeratedCount(out int count) ? new List<T>(capacity: count) : new List<T>();
foreach (T item in source)
{
    buffer.Add(item);
}

TryGetNonEnumeratedCount‎ comprueba las fuentes que implementan / o aprovecha algunas de las ‎‎optimizaciones internas empleadas por Linq‎‎ ICollectionICollection<T>

DistinctBy/UnionBy/IntersectBy/ExceptBy

‎Se han añadido nuevas variantes a las operaciones de conjunto que permiten especificar la igualdad mediante funciones de selector de teclas, como se puede ver en el siguiente ejemplo.‎

Enumerable.Range(1, 20).DistinctBy(x => x % 3); // {1, 2, 3}
var first = new (string Name, int Age)[] { ("Francis", 20), ("Lindsey", 30), ("Ashley", 40) };
var second = new (string Name, int Age)[] { ("Claire", 30), ("Pat", 30), ("Drew", 33) };
first.UnionBy(second, person => person.Age); // { ("Francis", 20), ("Lindsey", 30), ("Ashley", 40), ("Drew", 33) }

MaxBy/MinBy

MaxBy‎ y los métodos permiten encontrar elementos máximos o mínimos mediante un selector de claves, como se puede ver en el siguiente ejemplo.‎

MinBy

var people = new (string Name, int Age)[] { ("Francis", 20), ("Lindsey", 30), ("Ashley", 40) };people.MaxBy(person => person.Age); // ("Ashley", 40)

Chunk

Chunk‎ se puede utilizar para fragmentar un origen enumerable en sectores de un tamaño fijo, como se puede ver en el siguiente ejemplo.‎

IEnumerable<int[]> chunks = Enumerable.Range(0, 10).Chunk(size: 3); // { {0,1,2}, {3,4,5}, {6,7,8}, {9} }

FirstOrDefault/LastOrDefault/SingleOrDefault‎ sobrecargas tomando parámetros predeterminados‎

‎Los métodos existentes devuelven si el origen enumerable está vacío. Se han añadido nuevas sobrecargas que aceptan un parámetro predeterminado para ser devuelto en ese caso, como se puede ver en el siguiente ejemplo.‎FirstOrDefaultLastOrDefaultSingleOrDefaultdefault(T)

Enumerable.Empty<int>().SingleOrDefault(-1); // returns -1

Zip‎ sobrecarga aceptando tres enumerables‎

‎El método ‎‎Zip‎‎ ahora admite la combinación de tres enumerables, como puede ver en el siguiente ejemplo.‎

var xs = Enumerable.Range(1, 10);
var ys = xs.Select(x => x.ToString());
var zs = xs.Select(x => x % 2 == 0);

foreach ((int x, string y, bool z) in Enumerable.Zip(xs,ys,zs))
{
}

‎Rendimiento de FileStream significativamente mejorado en Windows‎

FileStream‎ se ha reescrito en .NET 6, para tener un rendimiento y una fiabilidad mucho mayores en Windows.‎

‎El ‎‎proyecto de reescritura‎‎ se ha escalonado en cinco puntos Puedes consultar los siguientes links para más detalle:‎

‎Configuración‎

‎El primer PR permite elegir una implementación en tiempo de ejecución. La ventaja más obvia de este patrón es habilitar el cambio a la antigua implementación de .NET 5, lo que puede hacer con la siguiente configuración, en .‎FileStreamruntimeconfig.json

{
    "configProperties": {
        "System.IO.UseNet5CompatFileStream": true
    }
}

Se planea agregar una ‎‎estrategia ‎‎de io_uring‎‎ a continuación, que aproveche una característica de Linux con el mismo nombre en ‎‎kernels más modernos.‎

‎Punto de referencia de rendimiento‎

Veamos las mejoras usando ‎‎BenchmarkDotNet‎‎.‎


public class FileStreamPerf
{
    private const int FileSize = 1_000_000; // 1 MB
    private Memory<byte> _buffer = new byte[8_000]; // 8 kB

    [GlobalSetup(Target = nameof(ReadAsync))]
    public void SetupRead() => File.WriteAllBytes("file.txt", new byte[FileSize]);

    [Benchmark]
    public async ValueTask ReadAsync()
    {
        using FileStream fileStream = new FileStream("file.txt", FileMode.Open, FileAccess.Read, FileShare.Read, bufferSize: 4096, useAsync: true);
        while (await fileStream.ReadAsync(_buffer) > 0)
        {
        }
    }

    [Benchmark]
    public async ValueTask WriteAsync()
    {
        using FileStream fileStream = new FileStream("file.txt", FileMode.Create, FileAccess.Write, FileShare.Read, bufferSize: 4096, useAsync: true);
        for (int i = 0; i < FileSize / _buffer.Length; i++)
        {
            await fileStream.WriteAsync(_buffer);
        }
    }

    [GlobalCleanup]
    public void Cleanup() => File.Delete("file.txt");
}

‎Resultados:‎

  • ‎La lectura de 1 archivo MB es ahora ‎‎2 veces más rápida‎‎, mientras que la escritura es ‎‎4 veces más rápida‎‎.‎
  • ‎¡Las asignaciones de memoria se redujeron de 39 kilobytes a 1 kilobyte! ¡Esta es una ‎‎mejora del 97.5%‎‎!‎

‎Estos cambios deberían proporcionar una mejora dramática para los usuarios de Windows. 

‎Soporte mejorado de fecha, hora y zona horaria‎

‎Se han realizado ‎‎las siguientes mejoras‎‎ en los tipos relacionados con la fecha y la hora.‎

‎Nuevo y estructuras‎ DateOnlyTimeOnly

‎Se han añadido ‎‎estructuras de solo fecha y hora‎‎, con las siguientes características:‎

  • ‎Cada uno representa la mitad de un , ya sea solo la parte de fecha o solo la parte de tiempo.‎DateTime
  • DateOnly‎ es ideal para cumpleaños, días de aniversario y días hábiles. Se alinea con el tipo de SQL Server.‎date
  • TimeOnly‎ es ideal para reuniones recurrentes, despertadores y horarios comerciales semanales. Se alinea con el tipo de SQL Server.‎time
  • ‎Complementa los tipos de fecha/hora existentes (, , , ).‎DateTimeDateTimeOffsetTimeSpanTimeZoneInfo
  • ‎En el espacio de nombres, se envía en CoreLib, al igual que los tipos relacionados existentes.‎System

‎Mejoras de Perf a ‎DateTime.UtcNow

‎Esta ‎‎mejora‎‎ tiene los siguientes beneficios:‎

  • ‎Corrige la ‎‎regresión perf 2.5x‎‎ para obtener el tiempo del sistema en Windows.‎
  • ‎Utiliza una caché deslizante de 5 minutos de datos de segundos saltos de Windows en lugar de buscarlos con cada llamada.‎

‎Compatibilidad con zonas horarias de Windows e IANA en todas las plataformas‎

‎Esta mejora tiene los siguientes beneficios:‎

  • ‎Conversión implícita al usar (https://github.com/dotnet/runtime/pull/49412)‎TimeZoneInfo.FindSystemTimeZoneById
  • ‎Conversión explícita a través de nuevas API en: , , y (https://github.com/dotnet/runtime/issues/49407)‎TimeZoneInfoTryConvertIanaIdToWindowsIdTryConvertWindowsIdToIanaIdHasIanaId
  • ‎Mejora la compatibilidad entre plataformas y la interoperabilidad entre sistemas que utilizan diferentes tipos de zonas horarias.‎
  • ‎Elimina la necesidad de usar la biblioteca OSS TimeZoneConverter. La funcionalidad ahora está incorporada.‎

‎Nombres para mostrar de zona horaria mejorados‎

‎Esta ‎‎mejora‎‎ tiene los siguientes beneficios:‎

  • ‎Quita la ambigüedad de los nombres para mostrar de la lista devuelta por .‎TimeZoneInfo.GetSystemTimeZones
  • ‎Aprovecha los datos de globalización de ICU / CLDR.‎
  • ‎Unix solo por ahora. Windows todavía usa los datos del Registro. Esto se puede cambiar más adelante.‎

‎Otro‎

  • ‎El nombre para mostrar y el nombre estándar de la zona horaria UTC estaban codificados al inglés y ahora usan el mismo idioma que el resto de los datos de la zona horaria (en Unix, idioma predeterminado del sistema operativo en Windows).‎CurrentUICulture
  • ‎Los nombres para mostrar de zona horaria en WASM utilizan el ID IANA no localizado en su lugar, debido a limitaciones de tamaño.‎
  • TimeZoneInfo.AdjustmentRule‎ la clase anidada hace pública su propiedad interna y obtiene un nuevo constructor que toma como parámetro. (https://github.com/dotnet/runtime/issues/50256)‎BaseUtcOffsetDeltabaseUtcOffsetDelta
  • TimeZoneInfo.AdjustmentRule‎ También obtiene varias correcciones para cargar zonas horarias en Unix (https://github.com/dotnet/runtime/pull/49733), (https://github.com/dotnet/runtime/pull/50131)‎

CodeGen

‎Se han realizado las siguientes mejoras en el compilador RyuJIT. puecen verlo en cada uno de los issue reportados:

‎Contribuciones comunitarias‎

‎@SingleAccretion‎‎ ha estado ocupado haciendo las siguientes mejoras en los últimos meses. Eso es además de una contribución en ‎‎.NET 6 Preview 3‎‎. ¡Gracias!‎

‎PGO dinámico‎

‎Se han realizado las siguientes mejoras para admitir ‎‎el PGO dinámico‎‎.‎

‎Optimizaciones de bucle JIT‎

‎Se han realizado las siguientes ‎‎mejoras para las optimizaciones de bucle‎‎.‎

LSRA

‎Se han realizado las siguientes mejoras ‎‎en la asignación de registros de escaneo lineal (LRSA).‎

  • ‎dotnet/runtime #51281‎‎ — Mejore las estadísticas de LRSA para incluir información heurística de selección de registros‎

‎Optimizaciones‎

‎Diagnóstico de .NET: EventPipe para Mono y rendimiento mejorado de EventPipe‎

‎EventPipe es  el mecanismo multiplataforma de NET para la salida de eventos, datos de rendimiento y contadores. A partir de .NET 6, se ha movido movido la implementación de C++ a C. ¡Con este cambio, Mono también podrá usar EventPipe! Esto significa que tanto CoreCLR como Mono usarán la misma infraestructura de eventos, incluidas las herramientas de la CLI de .NET Diagnostics. Este cambio también vino con una pequeña reducción en el tamaño de CoreCLR:‎

‎También hemos realizado algunos cambios que mejoran el rendimiento de EventPipe mientras está bajo carga. Durante las primeras vistas previas, hemos realizado una serie de cambios que dan como resultado mejoras de rendimiento tan altas como 2.06 veces lo que .NET 5 era capaz de hacer: 

‎Publicación de un solo archivo‎

‎Se han realizado las siguientes mejoras para la publicación de aplicaciones de un solo archivo.‎

‎Análisis estático‎

‎Se agregaron analizadores para la publicación de un solo archivo en .NET 5 para advertir sobre y algunas otras API que se comportan de manera diferente en paquetes de un solo archivo Assembly.Location.

En.NET 6 Preview 4, se ha mejorado el análisis para permitir advertencias personalizadas. Si tiene una API que no funciona en la publicación de un solo archivo, ahora podemos 

marcarla con el atributo ‎[RequiresAssemblyFiles] y aparecerá una advertencia si el analizador está habilitado. 

Agregar este atributo también silenciará todas las advertencias relacionadas con un solo archivo en el método, por lo que puede usar la advertencia para propagar las advertencias hacia arriba a su API pública 

‎El analizador se habilitara automáticamente para proyectos exe cuando se establece n PublishSingleFile  en true, pero también puede habilitarlo para cualquier proyecto estableciendo EnableSingleFileAnalysis en true . Esto podría ser útil si desea incrustar una biblioteca en un solo paquete de archivos

‎Compresión‎

‎Los paquetes de un solo archivo ahora admiten la compresión, que se puede habilitar estableciendo la propiedad EnableCompressionInSingleFile en true. En tiempo de ejecución, los archivos se descomprimen en la memoria según sea necesario. La compresión puede proporcionar un gran ahorro de espacio para algunos escenarios.

‎Veamos la publicación de un solo archivo, con y sin compresión, utilizada con ‎‎NuGet Package Explorer‎‎.‎

‎Con compresión: 71.6 MB‎

‎La compresión puede aumentar significativamente el tiempo de inicio de la aplicación, especialmente en plataformas Unix (porque tienen una ruta de inicio rápido sin copia que no se puede usar con compresión). Debemos probar tu aplicación después de habilitar la compresión para ver si el costo de inicio adicional es aceptable.‎

PublishReadyToRun‎ ahora utiliza crossgen2 de forma predeterminada‎

‎Crossgen2‎‎ ahora está habilitado de forma predeterminada al publicar imágenes ReadyToRun. También admite opcionalmente la generación de imágenes compuestas.‎

‎La siguiente configuración se expone para permitirle configurar la publicación con código listo para ejecutar. La configuración se establece en sus valores predeterminados.‎

   <PublishReadyToRun>false</PublishReadyToRun>
    <!-- set to true to enable publishing with ready to run native code -->
    <PublishReadyToRunUseCrossgen2>true</PublishReadyToRunUseCrossgen2> 
    <!-- set to false to use crossgen like in 5.0 -->
    <PublishReadyToRunComposite>false</PublishReadyToRunComposite>
    <!-- set to true to generate a composite R2R image -->

Instalación de la CLI de cargas de trabajo opcionales del SDK de .NET 6‎

‎.NET 6 introducirá el concepto de ‎‎cargas de trabajo del SDK‎‎ que se pueden instalar después del hecho en la parte superior del SDK de .NET para habilitar varios escenarios. Las nuevas cargas de trabajo disponibles en la vista previa 4 son cargas de trabajo AOT de .NET MAUI y Blazor WebAssembly.‎

‎Para las cargas de trabajo MAUI de .NET, se recomienda seguir utilizando la herramienta ‎‎maui-check‎‎ para la vista previa 4, ya que incluye componentes adicionales que aún no están disponibles en Visual Studio o como una carga de trabajo del SDK de .NET. Para probar la experiencia del SDK de .NET de todos modos (usando iOS como ejemplo). Una vez instalado, puede ejecutar y luego crear y compilar su proyecto.‎dotnet workload install microsoft-ios-sdk-fulldotnet new iosdotnet build

‎Para Blazor WebAssembly AOT, siga las ‎‎instrucciones de instalación proporcionadas a través‎‎ del blog de ASP.NET.‎

‎Preview 4 incluye cargas de trabajo MAUI de .NET para iOS, Android, tvOS, MacOS y MacCatalyst.‎

‎Tengamos en cuenta que copia las cargas de trabajo de NuGet.org en la instalación del SDK, por lo que deberá ejecutarse con privilegios elevados/sudo si la ubicación de instalación del SDK está protegida (es decir, en una ubicación admin/root).‎dotnet workload install

‎Comprobación de versiones del SDK integrada‎

‎Para facilitar el seguimiento de cuándo están disponibles nuevas versiones del SDK y los tiempos de ejecución, se ha agregado un nuevo comando al SDK de .NET 6: ‎dotnet sdk check

‎Esto nos indicará dentro de cada banda de características cuál es la última versión disponible de .NET SDK y .NET Runtime.‎

CLI Templates (‎dotnet new)

‎La vista previa 4 presenta una nueva capacidad de búsqueda para plantillas. buscará ‎‎NuGet.org‎‎ plantillas coincidentes. Durante las próximas vistas previas, los datos utilizados para esta búsqueda se actualizarán con más frecuencia con.‎dotnet new –search.

‎Las plantillas instaladas están disponibles tanto para la CLI como para Visual Studio. Se resolvió un problema anterior con las plantillas instaladas por el usuario que se perdían cuando se instalaba una nueva versión del SDK, sin embargo, las plantillas instaladas antes de .NET 6 Preview 4 deberán reinstalarse.‎

‎Una vez instaladas las plantillas de la CLI, puede comprobar si las actualizaciones están disponibles a través de y . Esto ahora reflejará las actualizaciones de plantillas mucho más rápidamente, admitirá las fuentes de NuGet que haya definido y admitirá las credenciales de autorización.‎–update-check–update-apply–interactive

‎En la vista previa 4 y las próximas vistas previas, la salida de los comandos se limpiará para centrarse en la información que más necesita. Por ejemplo, enumera solo las plantillas que acaban de instalar, en lugar de todas las plantillas.‎dotnet newdotnet new –install <package>

‎Para admitir estos y los próximos cambios en , estamos realizando cambios significativos en la API del motor de plantillas que pueden afectar a cualquier persona que hospede el motor de plantillas. Estos cambios aparecerán en La vista previa 4 y la vista previa 5. Si está alojando el motor de plantillas, comuníquese con nosotros en https://github.com/dotnet/templating para que podamos trabajar con usted para evitar o minimizar las interrupciones.‎dotnet new

‎Conclusiones

El equipo comenta que ya estamos parados sobre la versión de .NET 6. El lanzamiento final será en noviembre, aunque aún falta bastante tiempo,  se están acercando a terminar el desarrollo de características.

Fernando Sonego

More Posts

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *