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

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

SDK

Cette section contient les sous-rubriques suivantes :

• Évaluation de projet basée sur l’interface CLI
• Sortie de compilation du terminal
• Chemins de sortie simplifiés
• Commande 'dotnet workload clean'
• Ressources « dotnet publish » et « dotnet pack »
• dotnet restore audit de sécurité
• Template engine
• Lien source
• Kit SDK de construction à partir du code source

Évaluation de projet basée sur l’interface CLI

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

Flag	Descriptif
--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é.
--getTargetResult:<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 illustré dans 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 compilation du terminal

dotnet build a une nouvelle option pour produire une sortie de build plus modernisée. Cette sortie de Terminal Logger regroupe les erreurs avec le projet dont elles proviennent, distingue mieux les différents frameworks cibles pour les projets multi-ciblés et fournit des informations en temps réel sur ce que fait la compilation. Pour choisir la nouvelle sortie, utilisez l’option --tl . Pour plus d’informations sur cette option, consultez les options de génération 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 la gestion des outils.

Pour plus d’informations, consultez la disposition de sortie Artifacts.

Commande dotnet workload clean

.NET 8 introduit une nouvelle commande pour nettoyer les fardeaux de travail qui pourraient subsister après plusieurs mises à jour du SDK .NET ou de 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 la collecte de déchets des charges de travail pour les charges de travail basées sur des fichiers ou sur MSI, ce qui nettoie les paquets orphelins. Les packs orphelins proviennent des versions désinstallées du Kit de développement logiciel (SDK) .NET ou des packs où 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 la charge de travail sdk actuelle (et ce n’est pas à partir 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.

dotnet publish et dotnet pack ressources

É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 les différences de comportement entre dotnet build et dotnet publish, et comment vous pouvez rétablir la publication des ressources Debug en définissant la propriété de PublishRelease à false.

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

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

dotnet restore audit de sécurité

À compter de .NET 8, vous pouvez choisir de vérifier 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 trouvées. Pour plus d’informations, consultez Audit pour les vulnérabilités de sécurité.

Moteur de template

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 http:// flux par défaut. 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, vérifiez les vulnérabilités connues dans le paquet 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

Le lien source est désormais inclus dans le Kit de développement logiciel (SDK) .NET. L’objectif est qu’en regroupant le lien source dans le Kit de développement logiciel (SDK), au lieu d’exiger un package distinct <PackageReference> , d’autres packages incluront ces informations par défaut. Ces informations améliorent l’expérience IDE pour les développeurs.

Note

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

Kit de développement logiciel pour génération depuis le code source

Le Kit de développement logiciel (SDK) intégré à la distribution Linux (source-build) a désormais la possibilité de générer des applications autonomes à l’aide des packages d’exécution de build source. Le package d’exécution spécifique à cette distribution est fourni avec le Kit de développement logiciel (SDK) source-build. Pendant le déploiement autonome, ce package d’exécution groupé sera référencé, ce qui permet aux utilisateurs d’activer la fonctionnalité.

Modèle d’application console AOT natif

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

• Génère un exécutable autonome natif avec AOT 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 seul fichier. 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.

.NET sur Linux

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

Les bases de référence de prise en charge minimales pour Linux ont été mises à jour pour .NET 8. .NET est conçu pour cibler Ubuntu 16.04, pour toutes les architectures. Il est principalement important de définir la version minimale glibc pour .NET 8. .NET 8 ne démarre pas sur les versions de distribution qui incluent une glibc plus ancienne, telle qu’Ubuntu 14.04 ou Red Hat Enterprise Linux 7.

Pour plus d’informations, consultez la prise en charge de la famille Red Hat Enterprise Linux.

Créer votre propre .NET sur Linux

Dans les versions précédentes de .NET, vous pouvez générer .NET à partir de la source, mais il vous a fallu créer un « tarball source » à partir de la validation du dépôt dotnet/installer correspondant à une version. Dans .NET 8, cela n’est plus nécessaire et vous pouvez générer .NET sur Linux directement à partir du dépôt dotnet/dotnet . Ce référentiel utilise dotnet/source-build pour générer des runtimes, des outils et des kits sdk .NET. Il s’agit de la même build que Red Hat et Canonical utilisent pour générer .NET.

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

Vérification de la signature NuGet

À compter 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 situé à l’emplacement /etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem, vous pouvez voir des échecs d’approbation accompagnés d’avertissement NU3042.

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

Analyse du code

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

ID de règle	Catégorie	Descriptif
CA1856	Performance	Se déclenche lorsque l’attribut ConstantExpectedAttribute n’est pas appliqué correctement sur un paramètre.
CA1857	Performance	Se déclenche lorsqu’un paramètre est annoté avec ConstantExpectedAttribute , mais que l’argument fourni n’est pas une constante.
CA1858	Performance	Pour déterminer si une chaîne commence par un préfixe donné, il est préférable d’appeler String.StartsWith plutôt que d’appeler String.IndexOf, puis de comparer le résultat avec zéro.
CA1859	Performance	Cette règle recommande de mettre à niveau le type de variables locales, de champs, de propriétés, de paramètres de méthode et de retour de méthodes des types d’interface ou abstraits vers des types concrets lorsque cela est possible. L’utilisation de types concrets conduit à un code généré de meilleure qualité.
CA1860	Performance	Pour déterminer si un type de collection a des éléments, il est préférable d’utiliser Length, Countou IsEmpty plutôt d’appeler Enumerable.Any.
CA1861	Performance	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, envisagez d’extraire le tableau dans un champ en lecture seule statique.
CA1865-CA1867	Performance	La surcharge de caractère est plus performante pour une chaîne contenant un seul caractère.
CA2021	Reliability	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 assistances de levée sont plus simples et plus efficaces qu’un if bloc qui construit une nouvelle instance d’exception. Ces quatre analyseurs ont été créés pour les exceptions suivantes : ArgumentNullException, ArgumentExceptionet ArgumentOutOfRangeExceptionObjectDisposedException.

Diagnostiques

Le rechargement à chaud de C# prend en charge la modification des génériques

À compter de .NET 8, le 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 des pages Razor. Pour plus d’informations, consultez la liste complète des modifications prises en charge par Roslyn.

Voir aussi

• Nouveautés de .NET 8