Partager via

Nouveautés du Kit de développement logiciel (SDK) et des outils pour .NET 8

  • Article

Cet article décrit les nouvelles fonctionnalités du Kit de développement logiciel (SDK) .NET et des outils pour .NET 8.

Kit SDK

Cette section comprend les sous-rubriques suivantes :

Évaluation de projet basée sur CLI

MSBuild inclut une nouvelle fonctionnalité qui facilite l’incorporation de données de MSBuild dans vos scripts ou outils. Les commandes CLI telles que dotnet publish disposent des nouveaux indicateurs suivants pour obtenir les données à utiliser entre autres dans les pipelines CI.

Indicateur Description
--getProperty:<PROPERTYNAME> Récupère la propriété MSBuild avec le nom spécifié.
--getItem:<ITEMTYPE> Récupère les éléments MSBuild du type spécifié.
--getTargetResults:<TARGETNAME> Récupère les sorties de l’exécution de la cible spécifiée.

Les valeurs sont écrites dans la sortie standard. Plusieurs valeurs complexes ou multiples sont générées au format JSON, comme le montrent les exemples suivants.

>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",
        ...
    ]
  }
}

Sortie de build du terminal

dotnet build offre une nouvelle option pour produire une sortie de build plus moderne. Cette sortie de l’enregistreur d’événements de terminal regroupe les erreurs avec le projet dont elles proviennent, différencie mieux les différentes infrastructures cibles pour les projets multi-ciblés et fournit des informations en temps réel sur ce que fait le build. Pour choisir la nouvelle sortie, utilisez l’option --tl. Pour plus d’informations sur cette option, consultez Options de build dotnet.

Chemins de sortie simplifiés

.NET 8 introduit une option permettant de simplifier le chemin de sortie et la structure de dossiers pour les sorties de build. Auparavant, les applications .NET produisaient un ensemble profond et complexe de chemins de sortie pour différents artefacts de build. La nouvelle structure de chemin de sortie simplifiée rassemble toutes les sorties de build dans un emplacement commun, ce qui facilite l’anticipation des outils.

Pour plus d’informations, consultez Disposition de sortie des artefacts.

Commande dotnet workload clean

.NET 8 introduit une nouvelle commande pour nettoyer les packs de charge de travail qui peuvent être créés via plusieurs mises à jour du kit de développement logiciel (SDK) .NET ou Visual Studio. Si vous rencontrez des problèmes lors de la gestion des charges de travail, envisagez d’utiliser workload clean pour restaurer en toute sécurité un état connu avant de réessayer. La commande a deux modes :

  • dotnet workload clean

    Exécute le nettoyage de la mémoire de charges de travail pour les charges de travail basées sur des fichiers ou MSI, ce qui nettoie les packs orphelins. Les packs orphelins proviennent des versions désinstallées du kit de développement logiciel (SDK) .NET ou des packs pour lesquels les enregistrements d’installation du pack n’existent plus.

    Si Visual Studio est installé, la commande répertorie également les charges de travail que vous devez nettoyer manuellement à l’aide de Visual Studio.

  • dotnet workload clean --all

    Ce mode est plus agressif et nettoie chaque pack sur l’ordinateur qui est du type d’installation de charge de travail SDK actuel (et qui ne provient pas de Visual Studio). Il supprime également tous les enregistrements d’installation de la charge de travail pour la bande de fonctionnalités du kit de développement logiciel (SDK) .NET en cours d’exécution et ci-dessous.

Ressourcesdotnet publish et dotnet pack

Étant donné que les commandes dotnet publish et dotnet pack sont destinées à produire des ressources de production, elles produisent désormais des ressources Release par défaut.

La sortie suivante montre le comportement différent entre dotnet build et dotnet publish, et comment vous pouvez revenir à la publication de ressources Debug en affectant la valeur false à la propriété PublishRelease.

/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/

Pour plus d’informations, consultez ’dotnet pack’ utilise la configuration Release et ’dotnet publish’ utilise la configuration Release.

Audit de sécurité dotnet restore

À compter de .NET 8, vous pouvez choisir de rechercher les vulnérabilités connues lorsque les packages de dépendances sont restaurés. Cet audit produit un rapport sur les vulnérabilités de sécurité avec le nom du package affecté, la gravité de la vulnérabilité et un lien vers l’avis pour plus de détails. Lorsque vous exécutez dotnet add ou dotnet restore, les avertissements NU1901-NU1904 s’affichent pour toutes les vulnérabilités détectées. Pour plus d’informations, consultez Audit pour les vulnérabilités de sécurité.

Moteur de modèle

Le moteur de modèle offre une expérience plus sécurisée dans .NET 8 en intégrant certaines des fonctionnalités liées à la sécurité de NuGet. Les améliorations incluent :

  • Empêcher le téléchargement de packages à partir de flux par défaut http://. Par exemple, la commande suivante ne parvient pas à installer le package de modèle, car l’URL source n’utilise pas HTTPS.

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

    Vous pouvez remplacer cette limitation à l’aide de l’indicateur --force.

  • Pour dotnet new, dotnet new install et dotnet new update, recherchez les vulnérabilités connues dans le package de modèle. Si des vulnérabilités sont détectées et que vous souhaitez continuer, vous devez utiliser l’indicateur --force.

  • Pour dotnet new, fournissez des informations sur le propriétaire du package de modèle. La propriété est vérifiée par le portail NuGet et peut être considérée comme une caractéristique fiable.

  • Pour dotnet search et dotnet uninstall, indiquez si un modèle est installé à partir d’un package « approuvé », c’est-à-dire qu’il utilise un préfixe réservé.

Source Link est désormais inclus dans le Kit de développement logiciel (SDK) .NET. L’objectif est qu’en regroupant Source Link dans le Kit de développement logiciel (SDK), au lieu d’exiger un package <PackageReference> distinct, d’autres packages incluent ces informations par défaut. Ces informations offrent aux développeurs une meilleure expérience IDE.

Remarque

En tant qu’effet secondaire de cette modification, les informations de commit sont incluses dans la valeur InformationalVersion des bibliothèques et applications générées, même celles qui ciblent .NET 7 ou version antérieure. Pour plus d’informations, consultez Source Link inclus dans le Kit SDK .NET.

SDK de build source

Le Kit de développement logiciel (SDK) intégré à la distribution Linux (build source) permet désormais de créer des applications autonomes à l’aide des packages du runtime de build source. Le package d’exécution spécifique à la distribution est fourni avec le Kit de développement logiciel (SDK) de build source. Pendant le déploiement autonome, ce package d’exécution groupé est référencé, activant ainsi la fonctionnalité pour les utilisateurs.

Prise en charge native d’AOA

L’option de publication en tant qu’AOA natif a été introduite pour la première fois dans .NET 7. La publication d’une application avec AOA natif crée une version entièrement autonome de votre application qui n’a pas besoin d’un runtime ; tout est inclus dans un fichier unique. .NET 8 apporte les améliorations suivantes à la publication AOA native :

  • Ajoute la prise en charge des architectures x64 et Arm64 sur macOS.

  • Réduit les tailles des applications AOA natives sur Linux jusqu’à 50 %. Le tableau suivant montre la taille d’une application « Hello World » publiée avec AOA natif qui inclut l’intégralité du runtime .NET sur .NET 7 par rapport à .NET 8 :

    Système d’exploitation .NET 7 .NET 8
    Linux x64 (avec -p:StripSymbols=true) 3,76 Mo 1,84 Mo
    Windows x64 2,85 Mo 1,77 Mo

  • Vous permet de spécifier une préférence d’optimisation : taille ou vitesse. Par défaut, le compilateur choisit de générer du code rapide tout en étant attentif à la taille de l’application. Toutefois, vous pouvez utiliser la propriété <OptimizationPreference> MSBuild pour optimiser spécifiquement l’un ou l’autre. Pour plus d’informations, consultez Optimiser les déploiements AOT.

Modèle d’application console

Le modèle d’application console par défaut inclut désormais la prise en charge d’AOT prête à l’emploi. Pour créer un projet configuré pour la compilation AOT, exécutez simplement dotnet new console --aot. La configuration du projet ajoutée par --aot a trois effets :

  • Génère un exécutable autonome natif avec AOA natif lorsque vous publiez le projet, par exemple, avec dotnet publish ou Visual Studio.
  • Active les analyseurs de compatibilité pour le découpage, AOT et un fichier unique. Ces analyseurs vous alertent sur des parties potentiellement problématiques de votre projet (le cas échéant).
  • Active l’émulation au moment du débogage d’AOT afin que lorsque vous déboguez votre projet sans compilation AOT, vous bénéficiez d’une expérience similaire à AOT. Par exemple, si vous utilisez System.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é), l’émulation signifie que vous n’aurez aucune surprise lorsque vous essayez de publier le projet avec AOT.

Cibler des plateformes de type iOS avec AOA natif

.NET 8 commence à activer la prise en charge AOA native pour les plateformes de type iOS. Vous pouvez maintenant générer et exécuter des applications .NET iOS et .NET MAUI avec AOA natif sur les plateformes suivantes :

  • ios
  • iossimulator
  • maccatalyst
  • tvos
  • tvossimulator

Les tests préliminaires montrent que la taille de l’application sur le disque diminue d’environ 35 % pour les applications iOS .NET qui utilisent AOA natif au lieu de Mono. La taille de l’application sur le disque pour les applications iOS .NET MAUI diminue de jusqu’à 50 %. En outre, le temps de démarrage est également plus rapide. Les applications iOS .NET ont un temps de démarrage environ 28 % plus rapide, tandis que les performances de démarrage d’applications iOS .NET MAUI sont environ 50 % mieux qu’avec Mono. La prise en charge de .NET 8 est expérimentale et n’est que la première étape de la fonctionnalité dans son ensemble. Pour plus d’informations, consultez le billet de blog sur l’amélioration des performances de MAUI .NET 8 .

La prise en charge AOT native est disponible en tant que fonctionnalité par abonnement destinée au déploiement d’applications ; Mono est toujours le runtime par défaut pour le développement et le déploiement d’applications. Pour créer et exécuter une application .NET MAUI avec AOA natif sur un appareil iOS, utilisez dotnet workload install maui pour installer la charge de travail .NET MAUI et dotnet new maui -n HelloMaui pour créer l’application. Ensuite, définissez la propriété MSBuild PublishAot sur true dans le fichier projet.

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

Lorsque vous définissez la propriété requise et que vous exécutez dotnet publish comme indiqué dans l’exemple suivant, l’application est déployée à l’aide de l’AOA natif.

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

Limites

Toutes les fonctionnalités iOS ne sont pas compatibles avec l’AOA natif. De même, toutes les bibliothèques couramment utilisées dans iOS ne sont pas compatibles avec NativeAOT. En plus des limitations existantes du déploiement AOA natif, la liste suivante présente certaines des autres limitations lors du ciblage de plateformes de type iOS :

  • L’utilisation d’AOA natif est activée uniquement pendant le déploiement de l’application (dotnet publish).
  • Le débogage de code managé n’est pris en charge qu’avec Mono.
  • La compatibilité avec le framework .NET MAUI est limitée.

Compilation AOT pour les applications Android

Pour réduire la taille de l’application, les applications .NET et .NET MAUI qui ciblent Android utilisent le mode de compilation AOT profilé lorsqu’elles sont conçues en mode Mise en production. La compilation AOT profilée affecte moins de méthodes que la compilation AOT standard. .NET 8 introduit la propriété <AndroidStripILAfterAOT> qui vous permet d’opter pour une compilation AOT supplémentaire pour les applications Android afin de réduire encore plus la taille de l’application.

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

Par défaut, le paramètre AndroidStripILAfterAOT pour true remplace le paramètre par défaut AndroidEnableProfiledAot, ce qui permet à (presque) toutes les méthodes compilées par AOT d’être découpées. Vous pouvez également utiliser les découpages AOT et IL profilés en définissant explicitement les deux propriétés sur true :

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

Applications Windows à build croisées

Lorsque vous générez des applications qui ciblent Windows sur des plateformes non-Windows, l’exécutable résultant est maintenant mis à jour avec toutes les ressources—Win32 spécifiées, par exemple, l’icône d’application, le manifeste, les informations de version.

Auparavant, les applications devaient être créées sur Windows pour disposer de ces ressources. La résolution de cet écart dans la prise en charge des builds croisées est une demande populaire, car il s’agit d’un point de douleur important affectant à la fois la complexité de l’infrastructure et l’utilisation des ressources.

.NET sur Linux

Bases de référence de prise en charge minimale pour Linux

Les bases de référence de prise en charge minimale pour Linux ont été mises à jour pour .NET 8. .NET est généré en ciblant Ubuntu 16.04, pour toutes les architectures. Cela est surtout important pour définir la version glibc minimale pour .NET 8. .NET 8 ne parvient pas à démarrer sur les versions de distribution qui incluent un glibc plus ancien, comme Ubuntu 14.04 ou Red Hat Enterprise Linux 7.

Pour plus d’informations, consultez Red Hat Enterprise Linux Family support.

Générer votre propre .NET sur Linux

Dans les versions .NET précédentes, vous pouviez générer .NET à partir de la source, mais il vous fallait créer un « tarball source » à partir du commit de dépôt dotnet/installer qui correspondait à une version. Dans .NET 8 ce n’est plus nécessaire, et vous pouvez générer .NET sur Linux directement à partir du dépôt dotnet/dotnet. Ce dépôt utilise dotnet/source-build pour générer des runtimes, outils et SDK .NET. Il s’agit de la même build que celle utilisée par Red Hat et Canonical pour générer .NET.

La génération dans un conteneur est l’approche la plus simple pour la plupart des utilisateurs, car les images conteneur dotnet-buildtools/prereqs contiennent toutes les dépendances requises. Pour plus d’informations, consultez les instructions de génération.

Vérification de la signature NuGet

À partir de .NET 8, NuGet vérifie les packages signés sur Linux par défaut. NuGet continue également de vérifier les packages signés sur Windows.

La plupart des utilisateurs ne doivent pas remarquer la vérification. Toutefois, si vous disposez d’un bundle de certificats racine existant dans /etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem, vous pouvez voir des échecs d’approbation accompagnés d’un avertissement NU3042.

Vous pouvez désactiver la vérification en définissant la variable d’environnement DOTNET_NUGET_SIGNATURE_VERIFICATION sur false.

Analyse du code

.NET 8 inclut plusieurs nouveaux analyseurs et correctifs de code pour vous aider à vérifier que vous utilisez correctement et efficacement les API de bibliothèque .NET. Le tableau suivant récapitule les nouveaux analyseurs.

Identificateur de la règle Category Description
CA1856 Performances Se déclenche lorsque l’attribut ConstantExpectedAttribute n’est pas appliqué correctement à un paramètre.
CA1857 Performances Se déclenche lorsqu’un paramètre est annoté avec ConstantExpectedAttribute, mais que l’argument fourni n’est pas une constante.
CA1858 Performances Pour déterminer si une chaîne commence par un préfixe donné, Il est préférable d’appeler String.StartsWith que d’appeler String.IndexOf et de comparer le résultat à zéro.
CA1859 Performances Cette règle recommande de mettre à niveau le type des variables locales, des champs, des propriétés, des paramètres de méthode et des types de retour de méthode à partir de types d’interface ou abstraits vers des types concrets lorsque cela est possible. L’utilisation de types concrets permet d’obtenir du code de meilleure qualité.
CA1860 Performances Pour déterminer si un type de collection comporte des éléments, il est préférable d’utiliser Length, Count ou IsEmpty plutôt que d’appeler Enumerable.Any.
CA1861 Performances Les tableaux constants passés en tant qu’arguments ne sont pas réutilisés lorsqu’ils sont appelés à plusieurs reprises, ce qui implique qu’un nouveau tableau est créé à chaque fois. Pour améliorer les performances, vous pouvez extraire le tableau vers un champ en lecture seule statique.
CA1865-CA1867 Performances La surcharge char est une surcharge plus performante pour une chaîne avec un seul char.
CA2021 Fiabilité Enumerable.Cast<TResult>(IEnumerable) et Enumerable.OfType<TResult>(IEnumerable) nécessitent des types compatibles pour fonctionner correctement. Les conversions étendues et définies par l’utilisateur ne sont pas prises en charge avec les types génériques.
CA1510-CA1513 Maintenabilité Les assistants de levée sont plus simples et plus efficaces qu’un bloc if construisant une nouvelle instance d’exception. Ces quatre analyseurs ont été créés pour les exceptions suivantes : ArgumentNullException, ArgumentException, ArgumentOutOfRangeException et ObjectDisposedException.

Diagnostics

Rechargement à chaud C# prend en charge la modification des génériques

À compter de .NET 8, Rechargement à chaud C# prend en charge la modification des types génériques et des méthodes génériques. Lorsque vous déboguez des applications console, bureau, mobile ou WebAssembly avec Visual Studio, vous pouvez appliquer des modifications aux classes génériques et aux méthodes génériques dans du code C# ou dans des pages Razor Pages. Pour plus d’informations, consultez la liste complète des modifications prises en charge par Roslyn.

Voir aussi