Microsoft Build 2023 arrive ! L'équipe .NET organisera un certain nombre de sessions, des approfondissements techniques aux questions-réponses avec l'équipe.
Découvrez les nouveautés d'
ASP.NET Core et
EF Core dans la version Preview 4. Restez au courant de ce qui est nouveau et à venir dans
What's New in .NET 8. Il sera mis à jour tout au long de la version.
Enfin, .NET 8 a été testé avec la version 17.7 Preview 1. Il est recommandé d'utiliser les
builds du canal de prévisualisation si vous souhaitez essayer .NET 8 avec la famille de produits Visual Studio. La prise en charge de .NET 8 par Visual Studio pour Mac n'est pas encore disponible. Si vous vous en tenez au canal stable, découvrez les dernières fonctionnalités et améliorations de la
version 17.6 de Visual Studio.
Jetons maintenant un coup d'œil à quelques nouvelles fonctionnalités de .NET 8.
MSBuild : nouveau terminal moderne de sortie
https://github.com/dotnet/msbuild/issues/8370
Les utilisateurs nous font souvent remarquer que la sortie par défaut de MSBuild (connue en interne sous le nom de "console logger") est difficile à analyser. Elle est assez statique, est souvent un mur de texte, et émet des erreurs lorsqu'elles sont déclenchées pendant la construction au lieu de les montrer logiquement comme faisant partie du projet en cours de construction. Nous pensons qu'il s'agit là d'excellents retours, et nous sommes heureux de présenter notre première itération d'une nouvelle version, plus moderne, de la journalisation des sorties de MSBuild. Nous l'avons appelé Terminal Logger, et il a quelques objectifs principaux :
- Regrouper logiquement les erreurs avec le projet auquel elles appartiennent
- Présenter les projets/constructions de manière à ce que les utilisateurs pensent à la construction (en particulier les projets multi-cibles)
- Mieux différencier les TargetFrameworks pour lesquels un projet est construit
- Continuer à fournir des informations d'un coup d'œil sur les résultats d'un projet
- Fournir des informations sur ce que la compilation est en train de faire au cours d'une compilation.
Voici à quoi cela ressemble.
La nouvelle sortie peut être activée en utilisant
/tl, optionnellement avec l'une des options suivantes :
- auto - la valeur par défaut, qui vérifie si le terminal est capable d'utiliser les nouvelles fonctionnalités et n'utilise pas une sortie standard redirigée avant d'activer le nouveau logger,
- on - annule la détection de l'environnement mentionnée ci-dessus et force l'utilisation du nouveau logger
- off - annule la détection de l'environnement mentionnée ci-dessus et force l'utilisation de l'ancien enregistreur de la console.
Une fois activé, le nouveau logger affiche la phase de restauration, suivie de la phase de construction. Durant chaque phase, les projets en cours de construction sont affichés en bas du terminal, et chaque projet en cours de construction vous indique la cible MSBuild en cours de construction, ainsi que le temps passé sur cette cible. Nous espérons que ces informations rendront les constructions moins mystérieuses pour les utilisateurs, et qu'elles leur donneront un point de départ pour effectuer des recherches lorsqu'ils voudront en savoir plus sur la construction ! Au fur et à mesure que les projets sont construits, une section "construction terminée" est écrite pour chaque construction.
- Le nom du projet construit
- Le Framework cible (s'il est multi-cibles !)
- Le statut de cette compilation
- Le résultat principal de cette compilation (avec un lien hypertexte pour un accès rapide)
- Et enfin, tous les diagnostics générés par la compilation pour ce projet.
Il n'y avait pas de diagnostic pour cet exemple - regardons
une autre compilation du même projet où une coquille a été introduite.
Ici, vous pouvez clairement voir le projet et l'erreur typographique décrits.
Nous pensons que cette présentation correspond à la modernité de .NET et qu'elle utilise les capacités des terminaux modernes pour informer les utilisateurs sur leurs créations. Nous espérons que vous l'essaierez et que vous nous ferez part de vos commentaires sur son fonctionnement, ainsi que des autres informations que vous souhaiteriez y voir figurer. Nous espérons utiliser ce logger comme base pour un nouveau lot d'améliorations UX pour MSBuild - y compris des aspects tels que les rapports de progression et les erreurs structurées à l'avenir ! Au fur et à mesure que vous l'utilisez, merci de nous faire part de vos commentaires via cette enquête, ou via la section Discussions du référentiel MSBuild. Nous sommes impatients d'avoir de vos nouvelles !
SDK : Mise à jour simplifiée du chemin de sortie
https://github.com/dotnet/designs/pull/281
https://github.com/dotnet/sdk/pull/31955
Dans l'aperçu 3, nous avons annoncé la nouvelle présentation simplifiée du chemin de sortie pour les projets SDK .NET et nous vous avons demandé de nous faire part de vos commentaires et de votre expérience de l'utilisation de cette nouvelle présentation. Nous vous en remercions ! Vos commentaires ont donné lieu à de nombreuses discussions et, sur la base de ce que nous avons entendu de la part de tous ceux qui ont testé les changements, nous avons apporté les mises à jour suivantes à la fonctionnalité :
- Le chemin d'accès par défaut à la nouvelle présentation passe de .artifacts à artifacts
- Nous supprimons la possibilité d'utiliser la fonctionnalité à partir de fichiers de projet au lieu de Directory.Build.props.
- Nous facilitons la prise en main de la fonctionnalité en incluant les propriétés requises en tant qu'option dans le modèle buildprops pour dotnet new.
J'aimerais expliquer le processus de réflexion qui nous a conduits à ces changements. Vous avez tous massivement soutenu la suppression du . du nom du dossier, principalement pour des raisons de visibilité sur les systèmes Unix, où le . signifie généralement un fichier ou un dossier "caché". Nous savions donc que nous voulions faire ce changement. Cependant, il y a deux raisons principales pour lesquelles nous ne voulions pas utiliser les
artifacts comme chemin racine initialement -
- le support de .gitignore
- les obstacles liés à la globalisation des fichiers du SDK .NET
Nous ne voulions pas que les gens aient soudainement à gérer des changements dans leurs fichiers
.gitignore juste pour essayer la fonctionnalité, mais après quelques recherches, nous avons découvert qu'un contributeur entreprenant et tourné vers l'avenir (merci @sayedihashimi !) s'est déjà assuré que les
artifacts sont dans tous les modèles communs pour les fichiers
.gitignore. Cela signifie que nous n'avons pas eu à nous soucier des utilisateurs qui vérifiaient les binaires de manière inattendue.
Nous ne voulions pas non plus inclure accidentellement les sorties d'
artifacts dans les modèles globaux par défaut que le SDK .NET utilise pour trouver les fichiers sources à construire dans un projet. Si nous changions le chemin racine de
.artifacts à
artifacts et que nous laissions les utilisateurs utiliser les nouvelles fonctionnalités au niveau du fichier de projet, nous devrions également modifier toutes les inclusions par défaut qui rendent les fichiers de projet du SDK si succincts. Cela semblait très propice aux erreurs, et franchement un gouffre d'échec pour l'expérience utilisateur. En conséquence, nous avons resserré les conditions d'utilisation de la fonctionnalité - vous devez maintenant opter pour la fonctionnalité via le fichier Directory.Build.props. Cela a pour effet secondaire de rendre la fonctionnalité plus stable. Avant cette modification, l'emplacement du dossier racine inféré changeait lorsqu'un fichier Directory.Build.props était créé. Maintenant, parce qu'un Directory.Build.props doit exister, l'emplacement du chemin d'accès aux artefacts devrait rester stable.
Pour tester la nouvelle version de la fonctionnalité, nous avons facilité la génération du fichier Directory.Build.props correct : il suffit d'exécuter
dotnet new buildprops --use-artifacts et nous générerons tout ce dont vous avez besoin. Le fichier Directory.Build.props généré ressemble à ceci :
Code:
1
2
3
4
5
6
| <Project>
<!-- See https://aka.ms/dotnet/msbuild/customize for more details on customizing your build -->
<PropertyGroup>
<ArtifactsPath>$(MSBuildThisFileDirectory)artifacts</ArtifactsPath>
</PropertyGroup>
</Project> |
Template Engine : expérience sécurisée avec les paquets de Nuget.org
Dans .NET 8, nous intégrons plusieurs fonctionnalités liées à la sécurité de NuGet.org dans le moteur de modèles, en particulier dans l'expérience
dotnet new.
Améliorations
- Empêche le téléchargement de paquets à partir de flux http:\Nmais autorise les surcharges avec l'option --force.
L'équipe NuGet a mis en place un plan d'action pour passer progressivement à une approche sécurisée par défaut. Vous pouvez en savoir plus sur leur plan, et les délais impliqués, dans l'article du blog
HTTPS Everywhere. Pour soutenir cet objectif, nous allons commencer à générer des erreurs par défaut lorsqu'une source non-HTTPS est utilisée. Cela peut être remplacé par
--force pour la version 8 de .NET, mais le plan actuel est de supprimer ce drapeau pour la version 9 de .NET, en accord avec le calendrier de HTTPS Everywhere.
- Notifier un client si un paquet de modèles a des vulnérabilités lors des vérifications install/update/outdated, et exiger --force pour installer les versions vulnérables.
- Ajouter des données aux commandes de recherche et de désinstallation qui indiquent si un modèle est installé à partir d'un paquetage dont le préfixe est réservé dans NuGet.org.
- Ajout d'informations sur le propriétaire du paquetage du modèle. La propriété est vérifiée par le portail Nuget et peut être considérée comme une caractéristique digne de confiance.
NuGet : vérification des paquets signés sous Linux
À partir du SDK .NET 8 Preview 4, NuGet vérifie par défaut les paquets signés sous Linux. La vérification reste activée sous Windows et désactivée sous macOS.
Pour la plupart des utilisateurs de Linux, la vérification devrait fonctionner de manière transparente. Toutefois, les utilisateurs disposant d'un paquet de certificats racine situé dans
/etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem peuvent constater des échecs de confiance accompagnés de NU3042.
Les utilisateurs peuvent refuser la vérification en définissant la variable d'environnement
DOTNET_NUGET_SIGNATURE_VERIFICATION sur
false.
NuGet : Audit des dépendances des paquets pour les vulnérabilités de sécurité
https://github.com/NuGet/Home/issues/8087
https://github.com/NuGet/Home/pull/12310
dotnet restore produira un rapport sur les vulnérabilités de sécurité avec le nom du paquetage affecté, la gravité de la vulnérabilité et un lien vers l'avis pour plus de détails lorsque vous optez pour l'audit de sécurité NuGet.
Activation de l'audit de sécurité
À tout moment, si vous souhaitez recevoir des rapports d'audit de sécurité, vous pouvez opter pour l'expérience en définissant la propriété MSBuild suivante dans un fichier
.csproj ou MSBuild en cours d'évaluation dans le cadre de votre projet :
Code:
<NuGetAudit>true</NuGetAudit>
En outre, assurez-vous que le registre central de NuGet.org est défini comme l'une de vos sources de paquets afin de récupérer l'ensemble de données sur les vulnérabilités connues :
Code:
1
2
3
| <packageSources>
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
</packageSources> |
dotnet add package
Lorsque vous essayez d'ajouter un paquetage qui a une vulnérabilité connue,
dotnet restore sera exécuté implicitement et vous le fera savoir par un avertissement.
dotnet restore
Lorsque vous restaurez vos paquets via
dotnet restore, vous verrez des avertissements pour chaque paquet et avis affecté.
Codes d'avertissement
Pièce jointe 638863
Définition d'un niveau d'audit de sécurité
Vous pouvez définir la propriété MSBuild
<NuGetAuditLevel> au niveau souhaité pour lequel l'audit échouera. Les valeurs possibles sont
low,
moderate,
high et
critical. Par exemple, si vous ne voulez voir que les avis
moderate,
high et
critical, vous pouvez définir ce qui suit :
Code:
<NuGetAuditLevel>moderate</NuGetAuditLevel>
Bibliothèques : Améliorations de l'UTF8
Avec .NET 8 Preview 4, nous avons introduit la nouvelle interface
IUtf8SpanFormattable, qui, comme sa cousine
ISpanFormattable, peut être mise en œuvre sur un type pour permettre l'écriture d'une représentation de type chaîne de caractères de ce type vers une étendue de destination. Alors que
ISpanFormattable cible UTF16 et
Span<char>,
IUtf8SpanFormattable cible UTF8 et
Span<byte>. Il a également été mis en œuvre pour tous les types primitifs (et d'autres), avec exactement la même logique partagée (grâce à des interfaces abstraites statiques), qu'il s'agisse de
string, de
Span<char> ou de
Span<byte>, ce qui signifie qu'il prend totalement en charge tous les formats (y compris le spécificateur binaire "B" qui est également nouveau dans .NET 8 Preview 4) et toutes les cultures. Cela signifie que vous pouvez désormais formater directement en UTF8 à partir de
Byte,
Complex,
Char,
DateOnly,
DateTime,
DateTimeOffset,
Decimal,
Double,
Guid,
Half,
IPAddress,
IPNetwork,
Int16,
Int32,
Int64,
Int128,
IntPtr,
NFloat,
SByte,
Single,
Rune,
TimeOnly,
TimeSpan,
UInt16,
UInt32,
UInt64,
UInt128,
UIntPtr, et
Version.
En outre, les nouvelles méthodes
Utf8.TryWrite fournissent désormais une contrepartie basée sur UTF8 aux méthodes
MemoryExtensions.TryWrite UTF16 existantes. Ces méthodes s'appuient sur la prise en charge du gestionnaire de chaînes interpolées introduite dans .NET 6 et C# 10, de sorte que vous pouvez utiliser la syntaxe des chaînes interpolées pour formater une expression complexe directement dans une plage d'octets UTF8, par ex.
Code:
1
2
| static bool FormatHexVersion(short major, short minor, short build, short revision, Span<byte> utf8Bytes, out int bytesWritten) =>
Utf8.TryWrite(utf8Bytes, CultureInfo.InvariantCulture, $"{major:X4}.{minor:X4}.{build:X4}.{revision:X4}", out bytesWritten); |
L'implémentation reconnaît
IUtf8SpanFormattable sur les valeurs de format et utilise leurs implémentations pour écrire leurs représentations UTF8 directement dans l'étendue de destination.
L'implémentation utilise également la nouvelle méthode
Encoding.TryGetBytes, qui, avec son homologue
Encoding.TryGetChars, prend en charge l'encodage/décodage dans un span de destination tant que le span est suffisamment long pour contenir l'état résultant, et renvoie false au lieu de lancer une exception si ce n'est pas le cas.
Nous nous attendons à ce que d'autres améliorations de l'UTF8, y compris, mais sans s'y limiter, des améliorations de la performance de cette fonctionnalité, apparaissent dans les prochains aperçus de .NET 8.
Introduction de l'abstraction de temps
L'introduction de la classe abstraite
TimeProvider ajoute l'abstraction de temps, qui permet de simuler le temps dans les scénarios de test. Cette fonctionnalité est également prise en charge par d'autres fonctions qui s'appuient sur la progression temporelle, telles que
Task.Delay et
Task.Async. Cela signifie que même les opérations de Task peuvent être facilement simulées à l'aide de l'abstraction de temps. L'abstraction prend en charge les opérations temporelles essentielles telles que la récupération de l'heure locale et de l'heure UTC, l'obtention d'un horodatage pour la mesure des performances et la création de temporisateurs.
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
| public abstract class TimeProvider
{
public static TimeProvider System { get; }
protected TimeProvider()
public virtual DateTimeOffset GetUtcNow()
public DateTimeOffset GetLocalNow()
public virtual TimeZoneInfo LocalTimeZone { get; }
public virtual long TimestampFrequency { get; }
public virtual long GetTimestamp()
public TimeSpan GetElapsedTime(long startingTimestamp)
public TimeSpan GetElapsedTime(long startingTimestamp, long endingTimestamp)
public virtual ITimer CreateTimer(TimerCallback callback, object? state,TimeSpan dueTime, TimeSpan period)
}
public interface ITimer : IDisposable, IAsyncDisposable
{
bool Change(TimeSpan dueTime, TimeSpan period);
}
public partial class CancellationTokenSource : IDisposable
{
public CancellationTokenSource(TimeSpan delay, TimeProvider timeProvider)
}
public sealed partial class PeriodicTimer : IDisposable
{
public PeriodicTimer(TimeSpan period, TimeProvider timeProvider)
}
public partial class Task : IAsyncResult, IDisposable
{
public static Task Delay(System.TimeSpan delay, System.TimeProvider timeProvider)
public static Task Delay(System.TimeSpan delay, System.TimeProvider timeProvider, System.Threading.CancellationToken cancellationToken)
public Task WaitAsync(TimeSpan timeout, TimeProvider timeProvider)
public Task WaitAsync(TimeSpan timeout, TimeProvider timeProvider, CancellationToken cancellationToken)
}
public partial class Task<TResult> : Task
{
public new Task<TResult> WaitAsync(TimeSpan timeout, TimeProvider timeProvider)
public new Task<TResult> WaitAsync(TimeSpan timeout, TimeProvider timeProvider, CancellationToken cancellationToken)
} |
En outre, nous avons rendu l'abstraction disponible dans .NET 8.0 et créé une bibliothèque netstandard 2.0 appelée Microsoft.Bcl.TimeProvider. Cela permet d'utiliser l'abstraction sur les versions prises en charge du .NET Framework et des versions antérieures de .NET.
Code:
1
2
3
4
5
6
7
8
9
10
| namespace System.Threading.Tasks
{
public static class TimeProviderTaskExtensions
{
public static Task Delay(this TimeProvider timeProvider, TimeSpan delay, CancellationToken cancellationToken = default)
public static Task<TResult> WaitAsync<TResult>(this Task<TResult> task, TimeSpan timeout, TimeProvider timeProvider, CancellationToken cancellationToken = default)
public static Tasks.Task WaitAsync(this Task task, TimeSpan timeout, TimeProvider timeProvider, CancellationToken cancellationToken = default)
public static CancellationTokenSource CreateCancellationTokenSource(this TimeProvider timeProvider, TimeSpan delay)
}
} |
Exemples d'utilisation
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
| // Get System time
DateTimeOffset utcNow= TimeProvider.System.GetUtcNow();
DateTimeOffset localNow = TimeProvider.System.GetLocalNow();
// Create a time provider that work with a time zone different than the local time zone
private class ZonedTimeProvider : TimeProvider
{
private TimeZoneInfo _zoneInfo;
public ZonedTimeProvider(TimeZoneInfo zoneInfo) : base()
{
_zoneInfo = zoneInfo ?? TimeZoneInfo.Local;
}
public override TimeZoneInfo LocalTimeZone { get => _zoneInfo; }
public static TimeProvider FromLocalTimeZone(TimeZoneInfo zoneInfo) => new ZonedTimeProvider(zoneInfo);
}
// Create a time using a time provider
ITimer timer = timeProvider.CreateTimer(callBack, state, delay, Timeout.InfiniteTimeSpan);
// Measure a period using the system time provider
long providerTimestamp1 = TimeProvider.System.GetTimestamp();
long providerTimestamp2 = TimeProvider.System.GetTimestamp();
var period = GetElapsedTime(providerTimestamp1, providerTimestamp2); |
https://github.com/dotnet/runtime/issues/36617
System.Runtime.Intrinsics.Vector512 et AVX-512
La prise en charge SIMD est un élément essentiel de .NET depuis de nombreuses années, depuis que nous l'avons introduite pour la première fois dans .NET Framework. Dans .NET Core 3.0, nous avons étendu cette prise en charge pour inclure les API intrinsèques matérielles spécifiques à la plate-forme pour x86/x64. .NET 8 ne fait pas exception à la règle et continue de renforcer son support en introduisant
System.Runtime.Intrinsics.Vector512<T> et son accélération sur le matériel x86/x64 avec la prise en charge de l'AVX-512.
AVX-512 lui-même apporte plusieurs fonctionnalités clés dont la Preview 4 ajoute la prise en charge des trois premières. La dernière est encore en cours de développement et nous espérons pouvoir partager plus de détails à une date ultérieure :
- Prise en charge des opérations vectorielles sur 512 bits
- Prise en charge de 16 registres SIMD supplémentaires
- Prise en charge d'instructions supplémentaires disponibles pour les vecteurs 128 bits, 256 bits et 512 bits
- Prise en charge des opérations vectorielles masquées
Si votre matériel prend en charge cette fonctionnalité,
Vector512.IsHardwareAccelerated indiquera désormais
true. Nous avons également exposé plusieurs classes spécifiques aux plates-formes dans l'espace de noms
System.Runtime.Intrinsics.X86, notamment
Avx512F (Foundational),
Avx512BW (Byte and Word),
Avx512CD (Conflict Detection),
Avx512DQ (Doubleword and Quadword) et
Avx512Vbmi (Vector Byte Manipulation Instructions). Ces instructions suivent le même schéma général que les autres ISA en ce sens qu'elles exposent une propriété
IsSupported et une classe imbriquée
X64 pour les instructions disponibles uniquement pour les processus 64 bits. De plus, nous avons maintenant une classe imbriquée
VL dans chacune d'elles qui expose les extensions
Avx512VL (Vector Length) pour le jeu d'instructions correspondant.
En raison des deuxième et troisième caractéristiques clés énumérées ci-dessus, même si vous n'utilisez pas explicitement les instructions spécifiques
Vector512 ou
Avx512F dans votre code, vous bénéficierez probablement de cette fonctionnalité. En effet, le JIT est en mesure de tirer parti des fonctionnalités implicites lors de l'utilisation de
Vector128<T> ou
Vector256<T>, ce qui inclut tous les endroits de la BCL qui utilisent des intrinsèques matérielles en interne, comme la plupart des opérations exposées par
Span<T> et
ReadOnlySpan<T>, la plupart des API mathématiques exposées pour les types primitifs, et bien d'autres encore.
Améliorations de l'AOT natif
Nous avons mis à jour le modèle de
console par défaut et ajouté le support d'AOT dès le départ. Il est maintenant possible d'invoquer
dotnet new console --aot pour créer un projet configuré pour la compilation AOT. La configuration du projet ajoutée par
--aot a trois effets :
- La publication du projet avec, par exemple, dotnet publish ou Visual Studio générera un exécutable autonome natif avec AOT natif.
- Cela activera les analyseurs de compatibilité basés sur Roslyn pour le découpage, l'AOT et le fichier unique qui marqueront les parties potentiellement problématiques de votre projet (s'il y en a) dans l'éditeur de votre choix.
- Il permettra l'émulation de l'AOT lors du débogage, de sorte que lorsque vous déboguez votre projet sans compilation de l'AOT, vous obtenez une expérience similaire à celle de l'AOT. Cela permet de s'assurer que, par exemple, l'utilisation de Reflection.Emit dans un package NuGet qui n'a pas été annoté pour AOT (et qui a donc été manqué par l'analyseur de compatibilité) ne vous surprendra pas lorsque vous essayez de publier le projet avec AOT pour la première fois.
Nous continuons également à améliorer les fondamentaux tels que le débit d'exécution, l'utilisation de la mémoire et la taille sur disque avec Native AOT. Dans l'aperçu 4, nous ajoutons un moyen de communiquer une préférence d'optimisation telle que la vitesse ou la taille. Les paramètres par défaut tentent de trouver le bon équilibre entre ces deux options, mais nous introduisons maintenant un moyen de spécifier la façon de faire les compromis.
Par exemple, l'optimisation du résultat de
dotnet new console --aot pour la taille sur Windows x64 permet de réaliser les économies suivantes dans l'aperçu 4 :
Il s'agit de la taille d'une application entièrement autonome qui comprend le moteur d'exécution (y compris le GC) et toutes les bibliothèques de classes nécessaires.
Dans l'aperçu 4, nous avons observé que l'optimisation de la vitesse permet d'améliorer le débit de 2 à 3 % pour les charges de travail réelles.
Prise en charge de la version de la distribution Linux
Nous avons annoncé précédemment que nous mettions à jour les versions de distro Linux prises en charge pour .NET 8. Ces changements sont inclus dans l'aperçu 4, en particulier la version de la
glibc ciblée par .NET 8.
.NET 8 est conçu pour Ubuntu 16.04, pour toutes les architectures. C'est principalement important pour définir la version minimale de la
glibc pour .NET 8. .NET 8 ne démarrera pas sur les versions de distro qui incluent une
glibc plus ancienne, comme Ubuntu 14.04 ou Red Hat Enterprise Linux 7.
Nous sommes également en train de mettre à jour la version Linux de .NET 8 pour utiliser clang 16. Nous prévoyons d'inclure cette modification dans l'aperçu 5. Nous ne ferons pas d'annonce séparée pour cette modification.
Il n'y a pas d'autres changements significatifs. Nous continuerons à prendre en charge .NET sous Linux sur les architectures Arm32, Arm64 et x64.
System.Text.Json : Remplissage des membres en lecture seule
À partir de .NET 8 Preview 4, System.Text.Json introduit la possibilité de désérialiser sur des propriétés ou des champs en lecture seule.
Nous avons également introduit une option qui permet aux développeurs de l'activer pour toutes les propriétés qui sont capables de remplir - par exemple, les convertisseurs personnalisés peuvent ne pas être compatibles avec cette fonctionnalité :
Code:
1
2
3
4
| JsonSerializerOptions options = new()
{
PreferredObjectCreationHandling = JsonObjectCreationHandling.Populate
}; |
Pour les applications existantes qui souhaiteraient utiliser cette fonctionnalité mais dont la compatibilité pose problème, il est également possible de l'activer de manière granulaire en plaçant l'attribut
[JsonObjectCreationHandling(JsonObjectCreationHandling.Populate)] sur le type dont les propriétés doivent être renseignées.
Par exemple, pour activer le remplissage pour toutes les propriétés d'une classe spécifique :
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
| using System.Text.Json;
using System.Text.Json.Serialization;
JsonSerializerOptions options = new()
{
WriteIndented = true,
// Instead of granular control we could also enable this globally like this:
// PreferredObjectCreationHandling = JsonObjectCreationHandling.Populate
};
CustomerInfo customer = JsonSerializer.Deserialize<CustomerInfo>("""{"Person":{"Name":"John"},"Company":{"Name":"John and Son"}}""", options)!;
Console.WriteLine(JsonSerializer.Serialize(customer, options));
class PersonInfo
{
// there is nothing here to be populated since string cannot be re-used
public required string Name { get; set; }
public string? Title { get; set; }
}
class CompanyInfo
{
public required string Name { get; set; }
public string? Address { get; set; }
public string? PhoneNumber { get; set; }
public string? Email { get; set; }
}
// notes:
// - attribute does not apply to the `CustomerInfo` class itself: i.e. properties of type `CustomerInfo` wouldn't be auto-populated
// - automatic rules like these can be implemented with contract customization
// - attribute do apply to `Person` and `Company` properties
// - attribute can also be placed on individual properties
[JsonObjectCreationHandling(JsonObjectCreationHandling.Populate)]
class CustomerInfo
{
private const string NA = "N/A";
// note how neither of these have setters
public PersonInfo Person { get; } = new PersonInfo() { Name = "Anonymous", Title = "Software Developer" };
public CompanyInfo Company { get; } = new CompanyInfo() { Name = NA, Address = NA, PhoneNumber = NA, Email = NA };
} |
Le résultat ci-dessus est identique à celui que l'on obtiendrait avec l'option globale :
Code:
1
2
3
4
5
6
7
8
9
10
11
12
| {
"Person": {
"Name": "John",
"Title": "Software Developer"
},
"Company": {
"Name": "John and Son",
"Address": "N/A",
"PhoneNumber": "N/A",
"Email": "N/A"
}
} |
à titre de comparaison, nous aurions vu notre entrée, mais comme il n'y avait pas de propriété définissable
Person ou
Company à désérialiser, nous aurions ignoré complètement l'entrée et la sortie n'aurait montré que les valeurs par défaut :
Code:
1
2
3
4
5
6
7
8
9
10
11
12
| {
"Person": {
"Name": "Anonymous",
"Title": "Software Developer"
},
"Company": {
"Name": "N/A",
"Address": "N/A",
"PhoneNumber": "N/A",
"Email": "N/A"
}
} |
Autres notes concernant le remplissage des membres en lecture seule
- Pour plus d'informations, voir le problème original de la conception : https://github.com/dotnet/runtime/issues/78556
- Les structures peuvent également être alimentées, mais l'alimentation se fait en créant d'abord une copie, puis en la réinitialisant à la propriété, et ces propriétés nécessitent donc également des fixateurs (setters).
- Le peuplement des collections se fait de manière additive - la collection existante avec tout son contenu est traitée comme l'objet d'origine et tous les éléments existants sont donc préservés - ce comportement peut être modifié par la personnalisation du contrat et/ou les rappels de désérialisation.
Améliorations de System.Text.Json
JsonSerializer.IsReflectionEnabledByDefault
https://github.com/dotnet/runtime/pull/83844
La classe
JsonSerializer expose un certain nombre de méthodes de sérialisation et de désérialisation qui acceptent un paramètre optionnel
JsonSerializerOptions. Si elles ne sont pas spécifiées, ces méthodes utiliseront par défaut le sérialiseur basé sur la réflexion. Dans le contexte des applications AOT natives, ce défaut peut créer des problèmes en ce qui concerne la taille de l'application : même si l'utilisateur prend soin de passer une valeur
JsonSerializerOptions générée par la source, il en résultera toujours que les composants de réflexion seront enracinés par l'outil de découpage.
System.Text.Json est désormais livré avec le commutateur de fonctionnalité
System.Text.Json.JsonSerializer.IsReflectionEnabledByDefault qui contrôle le comportement par défaut des méthodes
JsonSerializer. Le fait de définir le commutateur sur
false au moment de la publication permet désormais d'éviter l'enracinement accidentel des composants de réflexion. Il convient de noter qu'avec l'interrupteur désactivé, ce code
Code:
JsonSerializer.Serialize(new { Value = 42 });
échouera désormais avec une exception
NotSupportedException. Un
JsonSerializerOptions configuré devra être passé explicitement pour que la méthode fonctionne.
En outre, la valeur du commutateur de fonctionnalité est reflétée dans la propriété
JsonSerializer.IsReflectionEnabledByDefault qui est traitée comme une constante de temps de liaison. Les auteurs de bibliothèques construites au-dessus de System.Text.Json peuvent s'appuyer sur cette propriété pour configurer leurs valeurs par défaut sans enraciner accidentellement des composants de réflexion :
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| static JsonSerializerOptions GetDefaultOptions()
{
if (JsonSerializer.IsReflectionEnabledByDefault)
{
// This branch has a dependency on DefaultJsonTypeInfo
// but will get trimmed away by the linker if the feature switch is disabled.
return new JsonSerializerOptions
{
TypeInfoResolver = new DefaultJsonTypeInfoResolver(),
PropertyNamingPolicy = JsonNamingPolicy.KebabCase,
}
}
return new() { PropertyNamingPolicy = JsonNamingPolicy.KebabCaseLower } ;
} |
JsonSerializerOptions.TypeInfoResolverChain
https://github.com/dotnet/runtime/issues/83095
Lorsqu'elle a été livrée en .NET 7, la fonction de personnalisation des contrats a ajouté la prise en charge du chaînage des générateurs de sources au moyen de la méthode
JsonTypeInfoResolver.Combine :
Code:
1
2
3
4
| var options = new JsonSerializerOptions
{
TypeInfoResolver = JsonTypeInfoResolver.Combine(ContextA.Default, ContextB.Default, ContextC.Default);
}; |
D'après les commentaires que nous avons reçus, cette approche pose quelques problèmes d'utilisation :
- Elle nécessite la spécification de tous les composants chaînés dans un site d'appel - les résolveurs ne peuvent pas être ajoutés à la chaîne après coup.
- L'implémentation du chaînage étant abstraite derrière l'implémentation d'un résolveur IJsonTypeInfoResolver, il n'existe aucun moyen pour les utilisateurs d'introspecter la chaîne ou d'en supprimer des composants.
La classe
JsonSerializerOptions comprend désormais une propriété
TypeInfoResolverChain qui est complémentaire de
TypeInfoResolver :
Code:
1
2
3
4
5
6
7
| namespace System.Text.Json;
public partial class JsonSerializerOptions
{
public IJsonTypeInfoResolver? TypeInfoResolver { get; set; }
public IList<IJsonTypeInfoResolver> TypeInfoResolverChain { get; }
} |
L'instance d'options telle que définie dans l'exemple original peut maintenant être manipulée comme suit :
Code:
1
2
3
| options.TypeInfoResolverChain.Count; // 3
options.TypeInfoResolverChain.RemoveAt(0);
options.TypeInfoResolverChain.Count; // 2 |
Il convient de noter que les propriétés
TypeInfoResolver et
TypeInfoResolverChain sont toujours synchronisées, de sorte qu'une modification apportée à l'une d'entre elles entraînera une mise à jour de l'autre.
Obsolescence de JsonSerializerOptions.AddContext
https://github.com/dotnet/runtime/issues/83280
La propriété JsonSerializerOptions.AddContext a été remplacée par les propriétés
TypeInfoResolver et
TypeInfoResolverChain, elle est donc marquée comme obsolète.
Prise en charge des types unspeakable
https://github.com/dotnet/runtime/issues/82457
Les types générés par le compilateur ou "unspeakable" ont été difficiles à prendre en charge dans les scénarios de génération de source faiblement typée. Dans .NET 7, l'application suivante
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| object value = Test();
JsonSerializer.Serialize(value, MyContext.Default.Options);
async IAsyncEnumerable<int> Test()
{
for (int i = 0; i < 10; i++)
{
await Task.Delay(1000);
yield return i;
}
}
[JsonSerializable(typeof(IAsyncEnumerable<int>))]
internal partial class MyContext : JsonSerializerContext {} |
échoue avec l'erreur
Code:
Metadata for type 'Program+<<<Main>$>g__Test|0_5>d' was not provided by TypeInfoResolver of type 'MyContext'
En effet, le type
Program+<<<Main>$>g__Test|0_5>d généré par le compilateur ne peut pas être explicitement spécifié par le générateur de source.
À partir de l'aperçu 4, System.Text.Json effectue la résolution de l'ancêtre le plus proche lors de l'exécution afin de déterminer le super-type le plus approprié pour sérialiser la valeur (dans ce cas,
IAsyncEnumerable<int>).
JsonSerializerOptions.TryGetTypeInfo
https://github.com/dotnet/runtime/pull/84411
L'aperçu 4 inclut désormais une variante
Try- de la méthode GetTypeInfo qui renvoie false si aucune métadonnée n'a été trouvée pour le type spécifié.
Codegen
Allocation de registres consécutifs
Dans cette version preview, nous avons introduit une nouvelle fonctionnalité dans notre allocateur de registres appelée allocation de "registres consécutifs". Avant d'entrer dans les détails de ce qu'elle implique et pourquoi elle était nécessaire, examinons d'abord ce qu'est l'allocation de registre et comment elle fonctionne dans RyuJIT.
L'algorithme d'allocation de registre utilisé dans RyuJIT est basé sur une approche "Linear Scan". Il parcourt le programme pour identifier la durée de vie de toutes les variables, appelées "intervalles" dans la littérature, et assigne un seul registre à chaque variable à chaque utilisation. Pour déterminer le meilleur registre à affecter à un point donné, l'algorithme doit identifier les variables qui sont actives à ce point et qui ne se chevauchent pas avec d'autres variables. Il sélectionne ensuite un registre parmi un ensemble de registres libres disponibles, en utilisant une heuristique pour déterminer le meilleur ensemble de registres au point d'affectation. Si aucun registre n'est disponible parce qu'ils sont tous affectés à des intervalles, l'algorithme identifie le meilleur registre qui peut être "déversé" et affecté à cet endroit. Le déversement consiste à stocker la valeur d'un registre sur la pile et à la récupérer plus tard en cas de besoin, ce qui est une opération coûteuse que l'allocateur de registres tente de minimiser.
L'Arm64 possède deux instructions, TBL et TBX, qui sont utilisées pour la recherche de vecteur de table. Ces instructions prennent un "tuple" comme l'un de leurs opérandes, qui peut contenir 2, 3 ou 4 entités. Dans le
PR# 80297, nous avons ajouté deux ensembles d'API, VectorTableLookup et VectorTableLookupExtension, sous l'espace de noms AdvSimd pour ces instructions. Cependant, ces instructions exigent que toutes les entités du n-uplet soient présentes dans des registres consécutifs. Pour mieux comprendre cette exigence, prenons un exemple.
Code:
1
2
3
4
5
6
7
8
9
| public static Vector128<byte> Test(float f)
{
var a = Produce1();
var b = Produce2();
var c = a + b;
var d = c + a;
var e = d + b;
d = AdvSimd.Arm64.VectorTableLookup((d, e, e, b), c);
} |
Voici le code généré pour la méthode.
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| movz x0, #0xD1FFAB1E // code for helloworld:Produce1():System.Runtime.Intrinsics.Vector128`1[ubyte]
movk x0, #0xD1FFAB1E LSL #16
movk x0, #0xD1FFAB1E LSL #32
ldr x0, [x0]
blr x0
str q0, [fp, #0x20] // [V01 loc0]
movz x0, #0xD1FFAB1E // code for helloworld:Produce2():System.Runtime.Intrinsics.Vector128`1[ubyte]
movk x0, #0xD1FFAB1E LSL #16
movk x0, #0xD1FFAB1E LSL #32
ldr x0, [x0]
blr x0
ldr q16, [fp, #0x20] // [V01 loc0]
add v17.16b, v16.16b, v0.16b
str q17, [fp, #0x10] // [V03 loc2]
add v16.16b, v17.16b, v16.16b
add v18.16b, v16.16b, v0.16b
mov v17.16b, v18.16b
mov v19.16b, v0.16b
ldr q20, [fp, #0x10] // [V03 loc2]
tbl v16.16b, {v16.16b, v17.16b, v18.16b, v19.16b}, v20.16b
add v0.16b, v0.16b, v16.16b |
Dans l'exemple donné, VectorTableLookup() prend un tuple composé de 4 vecteurs d, e, e, et b, qui sont passés dans les registres consécutifs v16 à v19. Même si la deuxième et la troisième valeur sont la même variable e, elles sont toujours passées dans des registres différents v17 et v18. Cela introduit la complexité de trouver non seulement plusieurs registres libres (ou occupés) (2, 3 ou 4) pour les instructions tbl et tbx, mais aussi des registres consécutifs. Afin de répondre à cette nouvelle exigence, notre algorithme a dû être mis à jour à différentes étapes, comme la vérification à l'avance si des registres consécutifs sont libres lors de l'assignation d'un registre à la première entité du tuple, l'assurance que les registres assignés sont consécutifs si les variables ont déjà des registres assignés et qu'ils ne sont pas consécutifs, et l'ajout de scénarios de tests de stress pour gérer les registres alternatifs lorsqu'ils sont disponibles. Dans le
PR #85189, @MihaZupan a utilisé le VectorTableLookup dans la méthode IndexOf de ProbabilisticMap et a obtenu une amélioration de 30%.
Optimisation de l'accès aux champs ThreadStatic
L'accès aux champs marqués avec
ThreadStatic devait passer par des appels d'aide qui accédaient au stockage local du thread (TLS) du thread et du module en cours avant d'accéder aux données du champ. Dans le
PR #82973, nous avons intégré tout ce code et ainsi, la valeur du champ peut être récupérée sans passer par l'aide. Cela permet de multiplier par 10 les performances d'accès aux champs.
Arm64
Nous avons continué à améliorer la qualité du code d'Arm64 et nos amis @SwapnilGaikwad et @a74nh d'Arm ont apporté de bonnes contributions à cette version.
- Dans le PR #84350, les paires de "str wzr" ont été optimisées et remplacées par "str xzr".
- Dans le PR #84135, les optimisations peephole de ldp/stp ont été activées pour les registres SIMD.
- Dans le PR #83458, un chargement a été remplacé par une instruction mov moins chère lorsque cela était possible.
- Dans le PR #79283, les conditions dans la clause if ont été combinées avec des chaînes de comparaison.
- Dans le PR #82031, on a commencé à utiliser cinc au lieu de csel quand c'était possible.
- Dans le PR #84667, combiner 'neg' et 'cmp' en 'cmn'.
- Dans le PR #84605, combiner les opérations cmp et shift en une seule opération cmp.
- Dans le PR #83694, ajouter IsVNNeverNegative (a amélioré tous les arcs, mais a eu un impact important sur ARM64).
Jusqu'à présent, l'optimisation de la paire load/store peephole n'était pas effectuée si l'une des valeurs provenait d'une variable locale. La PR #84399 a corrigé cette limitation et activé l'optimisation peephole de manière générale.
L'opérateur
>>> est optimisé pour les intrinsèques ShiftRightLogical sur Arm64 dans le
PR#85258.
Vectorisation du code
JIT/NativeAOT peut maintenant dérouler et vectoriser automatiquement diverses opérations mémoire telles que la comparaison, la copie et la mise à zéro avec SIMD (y compris les instructions AVX-512 sur x64 !) s'il peut déterminer leurs tailles au moment de la compilation :
- PR#83255 a rendu la mise à zéro de stackalloc 2 à 3 fois plus rapide avec SIMD
- PR#83638, PR#83740 et PR#84530 ont activé l'auto-vectorisation pour diverses opérations de type "copy buffer".
- Le PR#83945 a fait de même pour les comparaisons, y compris SequenceEqual et StartsWith pour tous les types de primitives. Un bon exemple d'un motif que le JIT peut maintenant vectoriser automatiquement est l'extrait suivant :
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
| bool CopyFirst50Items(ReadOnlySpan<int> src, Span<int> dst) =>
src.Slice(0, 50).TryCopyTo(dst);
```csharp
```asm
; Method CopyFirst50Items
push rbp
vzeroupper
mov rbp, rsp
cmp edx, 50 ;; src.Length >= 50 ?
jb SHORT G_M1291_IG05
xor eax, eax
cmp r8d, 50 ;; dst.Length >= 50 ?
jb SHORT G_M1291_IG04
vmovdqu zmm0, zmmword ptr [rsi]
vmovdqu zmm1, zmmword ptr [rsi+40H]
vmovdqu zmm2, zmmword ptr [rsi+80H]
vmovdqu xmm3, xmmword ptr [rsi+B8H]
vmovdqu zmmword ptr [rcx], zmm0
vmovdqu zmmword ptr [rcx+40H], zmm1
vmovdqu zmmword ptr [rcx+80H], zmm2
vmovdqu xmmword ptr [rcx+B8H], xmm3
mov eax, 1
G_M1291_IG04:
pop rbp
ret
G_M1291_IG05:
call [System.ThrowHelper:ThrowArgumentOutOfRangeException()]
int3
; Total bytes of code: 96 |
Ici, le JIT a utilisé 3 registres ZMM (AVX-512) pour effectuer une opération de type memmove en ligne (même si src et dst se chevauchent). Un codegen similaire sera généré pour les données constantes à la compilation, par exemple les littéraux utf8 :
Code:
1
2
| bool WriteHeader(Span<int> dst) => "text/html"u8.CopyTo(dst);
bool StartsWithHeader(Span<int> dst) => dst.StartsWith("text/html"u8); |
Optimisations générales
- PR#83911 Les initialisations statiques sont maintenant moins coûteuses dans NativeAOT.
- PR#84213 et PR#84231 : amélioration de l'élimination des contrôles pour les motifs arr[arr.Length - cns] et arr[index % arr.Length].
- L'optimisation de la substitution vers l'avant est activée pour plus de cas tels que les petits types, PR#83969.
- Amélioration de certains cas de déversements lors de l'allocation des registres avec PR#85251.
- PR#84427 a amélioré l'extensibilité de l'instrumentation PGO.
- Nous avons continué à améliorer les capacités d'optimisation des boucles JIT. Dans l'aperçu 4, nous avons amélioré le calcul des ensembles d'accessibilité, PR#84204.
Résumé
L'aperçu 4 de .NET 8 contient de nouvelles fonctionnalités et améliorations passionnantes qui n'auraient pas été possibles sans le travail acharné et le dévouement d'une équipe diversifiée d'ingénieurs chez Microsoft et d'une communauté open source passionnée. Nous tenons à remercier sincèrement tous ceux qui ont contribué à .NET 8 jusqu'à présent, que ce soit par des contributions au code, des rapports de bogues ou des commentaires.
Vos contributions ont joué un rôle déterminant dans la réalisation des avant-premières de .NET 8, et nous sommes impatients de continuer à travailler ensemble pour construire un avenir meilleur pour .NET et l'ensemble de la communauté technologique.
