L'aperçu 3 de .NET 8 est désormais disponible. Elle inclut des changements dans les chemins de génération, les charges de travail, les Microsoft.Extensions et les conteneurs. Elle inclut également des améliorations de performance dans le JIT, pour Arm64, et le PGO dynamique. Si vous avez manqué l'aperçu de mars, vous pouvez lire l'article sur l'aperçu 2.Vous pouvez télécharger .NET 8 Preview 3 pour Linux, macOS et Windows.
.NET 8 a été testé avec la version 17.6 Preview 3. Si vous souhaitez essayer .NET 8 avec la famille de produits Visual Studio, nous vous recommandons d'utiliser les builds du canal de prévisualisation. La prise en charge de .NET 8 par Visual Studio for Mac n'est pas encore disponible.
Jetons un coup d'œil à quelques-unes des nouvelles fonctionnalités.
SDK
Plusieurs améliorations ont été apportées au SDK, ainsi qu'une modification majeure.
Les améliorations apportées au SDK .NET sont les suivantes :
Chemin de sortie simplifié
Les applications .NET peuvent être construites de différentes manières et, par conséquent, les utilisateurs de la plateforme se sont familiarisés avec un ensemble très profond et complexe de chemins de sortie pour différents artefacts de construction. Des dossiers tels que bin, obj, publish, et les nombreuses permutations et dispositions différentes de ceux-ci constituent la mémoire musculaire de nombreux développeurs .NET. Le concept de répertoires par projet pour ces sorties est tout aussi fort. Cependant, au fil du temps, nous avons reçu des commentaires de la part d'utilisateurs de longue date et de nouveaux utilisateurs de .NET, selon lesquels cette disposition est :
- Difficile à utiliser parce que la disposition peut changer radicalement par le biais de modifications relativement simples de MSBuild.
- Difficile pour les outils d'anticiper car la disposition par projet ne permet pas de s'assurer que vous avez obtenu les sorties pour chaque projet.
Pour relever ces deux défis et rendre les sorties de compilation plus faciles à utiliser et plus cohérentes, le SDK .NET a introduit une option qui crée une structure de chemin de sortie plus unifiée et simplifiée.
Le nouveau chemin de sortie se concentre sur :
- Le rassemblement de toutes les sorties de compilation dans un emplacement commun.
- La séparation des sorties de compilation par projet dans cet emplacement commun.
- L'aplatissement de la structure globale des sorties de compilation à un maximum de trois niveaux de profondeur.
Pour opter pour la nouvelle disposition des chemins de sortie, vous devez définir la propriété UseArtifactsOutput dans un fichier Directory.Build.props. La façon la plus simple de commencer est d'exécuter dotnet new buildprops à la racine de votre référentiel, d'ouvrir le fichier Directory.Build.props généré, puis d'ajouter ce qui suit au PropertyGroup de ce fichier :
| Code : | Sélectionner tout |
<UseArtifactsOutput>true</UseArtifactsOutput>
À partir de ce moment, la sortie de la compilation pour tous les projets sera placée dans le répertoire .artifacts à la racine du référentiel. Ceci est configurable - il suffit de définir la propriété ArtifactsPath dans votre fichier Directory.Build.props à n'importe quel répertoire que vous préférez. Si vous ne souhaitez pas utiliser .artifacts par défaut, nous serions ravis d'entendre vos commentaires lors de la discussion sur la conception.
La disposition du répertoire .artifacts sera de la forme <ArtifactsPath>\<Type de sortie>\<Nom du projet>\<Pivots>, où :
- Type of Output est utilisé pour regrouper différentes catégories de sorties de compilation comme les binaires, les fichiers intermédiaires/générés, les applications publiées ou les paquets NuGet, et
- Pivots est utilisé pour aplanir toutes les différentes options qui sont utilisées pour différencier les builds, comme Configuration et RuntimeIdentifier.
Voici quelques exemples de chemins qui seraient créés sous le nouveau format :
- .artifacts\bin\debug - Le chemin de sortie de la compilation pour un projet simple lorsque vous exécutez dotnet build.
- .artifacts\obj\debug - Le chemin de sortie intermédiaire pour un projet simple lorsque vous exécutez dotnet build.
- .artifacts\bin\MyApp\debug_net8.0 - Le chemin de sortie de la compilation pour la compilation net8.0 d'un projet multi-cibles.
- .artifacts\publish\MyApp\release_linux-x64 - Le chemin de publication pour une application simple lors de la publication pour linux-x64.
- .artifacts\package\release - Le dossier dans lequel la version .nupkg sera créée pour un projet.
Nous pensons que cette structure de sortie unifiée répond aux préoccupations que nous avons entendues de la part des utilisateurs et nous donne une base sur laquelle nous pouvons construire pour l'avenir. Les sections Type of Output et Pivots nous permettent d'ajouter de nouveaux types de sorties ou de constructions sans modifier radicalement la présentation à l'avenir. L'ancrage de toutes les sorties dans un seul dossier facilite l'inclusion, l'ignorance ou la manipulation des sorties de construction par les outils. Nous aimerions connaître votre expérience de l'activation et de l'utilisation de la nouvelle présentation dans le cadre de cette enquête SurveyMonkey.
Commande dotnet workload clean
Au fil des mises à jour du SDK .NET et de Visual Studio, il est possible que les workload packs (les unités de fonctionnalité, les outils et les modèles qui composent une charge de travail) soient oubliés. Cela peut se produire pour un certain nombre de raisons, mais dans tous les cas, c'est une source de confusion pour les utilisateurs finaux. Certains utilisateurs vont jusqu'à supprimer manuellement les répertoires de charge de travail de leur emplacement d'installation du SDK, ce que l'équipe SDK ne recommande vraiment pas ! Au lieu de cette mesure drastique, nous avons implémenté dans cette version préliminaire une nouvelle commande pour aider à nettoyer les packs de charge de travail restants.
La nouvelle commande est la suivante :
| Code : | Sélectionner tout |
dotnet workload clean
La prochaine fois que vous rencontrerez des problèmes dans la gestion des charges de travail, pensez à utiliser dotnet workload clean pour restaurer en toute sécurité un état connu avant de réessayer.
clean a deux modes d'opération, qui sont discutés ci-dessous.
dotnet workload clean
Exécute le garbage collection de la charge de travail pour les charges de travail basées sur des fichiers ou des MSI. Dans ce mode, le garbage collection se comporte normalement, nettoyant uniquement les paquets orphelins eux-mêmes.
Il nettoiera les paquets orphelins provenant de versions désinstallées du SDK .NET ou de paquets pour lesquels les enregistrements d'installation n'existent plus. Il ne le fera que pour la version donnée du SDK ou pour une version plus ancienne. Si une version plus récente du SDK est installée, vous devrez répéter la commande.
Si Visual Studio est installé et gère également des charges de travail, dotnet workload clean répertorie toutes les charges de travail Visual Studio installées sur la machine et signale qu'elles doivent être désinstallées via Visual Studio plutôt que via l'interface de gestion du SDK .NET. Cela permet de comprendre pourquoi certaines charges de travail ne sont pas nettoyées/désinstallées après l'exécution de dotnet workload clean.
dotnet workload clean --all
Contrairement à workload clean, workload clean --all exécute le garbage collection de manière irrégulière, ce qui signifie qu'il nettoie chaque pack existant sur la machine qui ne provient pas de Visual Studio et qui est du type d'installation de la charge de travail SDK actuelle (soit basée sur des fichiers, soit basée sur MSI).
Pour cette raison, il supprime également tous les enregistrements d'installation de charge de travail pour la bande de fonctionnalités du SDK .NET en cours d'exécution et les bandes inférieures. workload clean ne supprime pas encore les enregistrements d'installation, car les manifestes sont actuellement le seul moyen de faire correspondre un pack à l'ID de la charge de travail, mais les fichiers manifests peuvent ne pas exister pour les packs orphelins.
Exécution
Les améliorations suivantes ont été apportées au moteur d'exécution et aux bibliothèques.
ValidateOptionsResultBuilder
Le ValidateOptionsResultBuilder facilite la création d'un objet ValidateOptionsResult, qui est nécessaire pour implémenter IValidateOptions.Validate(String, TOptions). Ce constructeur vous permet d'accumuler plusieurs erreurs, ce qui vous permet de voir tous les problèmes en même temps et de les résoudre en conséquence. Grâce à ce nouvel outil, vous gagnerez du temps et de l'énergie en rationalisant le processus de validation.
Voici un exemple d'utilisation :
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 | ValidateOptionsResultBuilder builder = new();
builder.AddError("Error: invalid operation code");
builder.AddResult(ValidateOptionsResult.Fail("Invalid request parameters"));
builder.AddError("Malformed link", "Url");
// Build ValidateOptionsResult object has accumulating multiple errors.
ValidateOptionsResult result = builder.Build();
// Reset the builder to allow using it in new validation operation.
builder.Clear(); |
Présentation du générateur de source de liaison de configuration
La configuration d'une application dans ASP.NET Core est réalisée à l'aide d'un ou plusieurs fournisseurs de configuration. Les fournisseurs de configuration lisent des données (sous forme de paires clé-valeur) à partir d'une variété de sources telles que les fichiers de paramètres (par exemple, appsettings.json), les variables d'environnement, Azure Key Vault, etc.
Au cœur de ce mécanisme se trouve ConfigurationBinder, une classe d'extension qui fournit les méthodes Bind et Get qui mappent les valeurs de configuration (instances IConfiguration) vers des objets fortement typés. Bind prend une instance, tandis que Get en crée une pour le compte de l'appelant. L'approche actuelle utilise la réflexion, ce qui pose des problèmes pour l'élagage et l'AOT natif.
Dans .NET 8, nous utilisons un générateur de source qui génère des implémentations de liaison sans réflexion et compatibles avec AOT. Le générateur recherche les appels Configure, Bind et Get à partir desquels nous pouvons récupérer des informations sur les types.
L'exemple suivant montre un code qui invoque la liaison :
| Code : | Sélectionner tout |
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 | using Microsoft.AspNetCore.Builder;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
WebApplicationBuilder builder = WebApplication.CreateBuilder(args);
IConfigurationSection section = builder.Configuration.GetSection("MyOptions");
// !! Configure call - to be replaced with source-gen'd implementation
builder.Services.Configure<MyOptions>(section);
// !! Get call - to be replaced with source-gen'd implementation
MyOptions options0 = section.Get<MyOptions>();
// !! Bind call - to be replaced with source-gen'd implementation
MyOptions options1 = new MyOptions();
section.Bind(myOptions1);
WebApplication app = builder.Build();
app.MapGet("/", () => "Hello World!");
app.Run();
public class MyOptions
{
public int A { get; set; }
public string S { get; set; }
public byte[] Data { get; set; }
public Dictionary<string, string> Values { get; set; }
public List<MyClass> Values2 { get; set; }
}
public class MyClass
{
public int SomethingElse { get; set; }
} |
Lorsque le générateur est activé dans un projet, les méthodes générées sont implicitement choisies par le compilateur, au détriment des implémentations préexistantes du framework basées sur la réflexion. Pour activer le générateur de source, téléchargez la dernière version preview de Microsoft.Extensions.Configuration.Binder. Le générateur est désactivé par défaut. Pour l'utiliser, ajoutez la propriété suivante à votre fichier de projet :
| Code : | Sélectionner tout |
1 2 3 | <PropertyGroup>
<EnableMicrosoftExtensionsConfigurationBinderSourceGenerator>true</EnableMicrosoftExtensionsConfigurationBinderSourceGenerator>
</PropertyGroup> |
Conteneurs
Nous continuons à améliorer les capacités et l'expérience d'utilisation de .NET dans les conteneurs. Dans cette version, nous nous concentrons sur la sécurité et le ciblage d'architectures multiples.
Création d'images de conteneurs multiplateformes
Il est désormais courant d'utiliser régulièrement des machines Arm64 et x64. Les machines x64 existent depuis des décennies, mais les machines de dév Arm64 (comme les Mac d'Apple) et les nœuds cloud Arm64 sont relativement récents. Docker prend en charge l'utilisation et la construction d'images multiplateformes qui fonctionnent dans plusieurs environnements. Nous avons développé un nouveau modèle qui vous permet de mélanger les architectures avec les images .NET que vous construisez.
Imaginez que vous êtes sur un Apple Mac et que vous voulez cibler un service cloud x64 dans Azure. Vous pouvez créer l'image en utilisant le commutateur --platform comme suit.
| Code : | Sélectionner tout |
docker build --pull -t app --platform linux/amd64 .
En utilisant le nouveau modèle, vous ne mettrez à jour qu'une seule ligne dans votre fichier Docker (l'étape de construction) :
| Code : | Sélectionner tout |
FROM --platform=$BUILDPLATFORM mcr.microsoft.com/dotnet/sdk:8.0-preview-alpine AS build
Nous avons également mis à jour le SDK (dans la Preview 3) pour prendre en charge les valeurs $TARGETARCH et ajouter l'argument -a lors de la restauration. Vous pouvez le constater dans l'exemple suivant.
| Code : | Sélectionner tout |
1 2 3 4 5 | RUN dotnet restore -a $TARGETARCH # copy everything else and build app COPY aspnetapp/. . RUN dotnet publish -a $TARGETARCH --self-contained false --no-restore -o /app |
Cette approche permet de produire des applications plus optimisées d'une manière qui s'intègre bien avec les valeurs --platform de Docker.
Variable d'environnement pour la valeur UID de l'utilisateur non-root
Nous avons ajouté une variable d'environnement pour l'UID de l'utilisateur non root que nous avons ajouté dans la Preview 1. Nous avons réalisé que le test Kubernetes runAsNonRoot exigeait que l'utilisateur du conteneur soit défini par l'UID et non par le nom. En même temps, nous voulions éviter aux développeurs d'avoir à appliquer un numéro spécial à des milliers de Dockerfiles (collectivement). Au lieu de cela, nous exposons cette valeur - 64198 - dans une variable d'environnement.
Vous pouvez voir cela utilisé dans ce Dockerfile :
| Code : | Sélectionner tout |
USER $APP_UID
C'est le modèle que nous recommandons pour .NET 8.
Lorsque vous construisez une image de conteneur avec USER défini de cette manière, vous verrez ce qui suit dans les métadonnées du conteneur.
| Code : | Sélectionner tout |
1 2 | $ docker inspect app | jq .[-1].Config.User "64198" |
Vous pouvez voir comment cette variable d'environnement est définie.
| Code : | Sélectionner tout |
1 2 3 4 | $ docker run --rm -it mcr.microsoft.com/dotnet/runtime bash -c "export | grep APP" declare -x APP_UID="64198" $ docker run --rm -it mcr.microsoft.com/dotnet/runtime cat /etc/passwd | tail -n 1 app:x:64198:64198::/home/app:/bin/sh |
Nous entrerons bientôt dans les détails de ce modèle dans un article sur Kubernetes.
Résumé
.NET 8 Preview 3 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.
Source : Microsoft
Et vous ?
Que pensez-vous des nouveautés apportées par ce nouvel apercu de .NET 8 ? Vous seront-elles utiles dans vos projets ?Voir aussi
Microsoft publie .NET 8 Preview 2, le second aperçu de la dernière version du framework, et apporte plusieurs nouvelles fonctionnalités dans les bibliothèques Microsoft publie .NET 8 Preview 1, le premier aperçu de la nouvelle version du framework, et ajoute plusieurs nouveautés dont l'extension de Native AOT à plus de scénarios et le support pour Linux Microsoft dévoile les mises à jour apportées à ASP.NET Core dans .NET 8 Preview 2, dont l'ajout de Blazor QuickGrid et de plusieurs améliorations de performance 
