IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Anthony

11PARTAGES

3  0 
Bienvenue à .NET 8 ! Le premier aperçu est prêt à être téléchargé : demandez votre copie du premier aperçu de .NET 8 et commencez à créer des applications dès aujourd'hui. Faites défiler vers le bas pour voir la liste des fonctionnalités incluses dans cet aperçu. .NET 8 est une version de support à long terme (LTS). Ce billet de blog couvre les principaux thèmes et objectifs qui déterminent la priorité et la sélection des améliorations à développer. Les versions d'aperçu et les versions candidates de .NET 8 seront livrées tous les mois. Comme d'habitude, la version finale sera livrée en novembre à l'occasion de la conférence .NET.

Les versions de .NET comprennent des produits, des bibliothèques, un moteur d'exécution et des outils, et représentent une collaboration entre plusieurs équipes au sein et en dehors de Microsoft. Les thèmes plus larges abordés dans ce billet de blog n'englobent pas tous les scénarios et investissements clés pour .NET 8. Ils représentent de vastes domaines, mais ne sont qu'une partie de l'ensemble des travaux importants réalisés pour .NET 8. Nous prévoyons d'importants investissements dans ASP.NET Core, Blazor, EF Core, WinForms, WPF et d'autres plateformes.

Bienvenue à .NET 8

À la fin de l'année dernière, nous avons livré .NET 7, le résultat d'une collaboration entre l'équipe .NET et l'incroyable communauté qui a soutenu la version avec plus de 28 000 contributions de plus de 10 000 membres de la communauté. .NET 7 est le cadre de choix pour la création d'applications aujourd'hui. La version unifie la plate-forme avec un support natif pour ARM64 et un support amélioré pour Linux. Elle contribue à la modernisation de vos applications grâce à des outils tels que .NET MAUI, qui permet de créer des applications mobiles et de bureau multiplateformes à partir de la même base de code. Il inclut des améliorations de la performance des API et facilite la création et le déploiement d'applications natives distribuées en nuage. .NET 7 simplifie l'expérience de création d'applications en réduisant la quantité de code nécessaire grâce aux améliorations apportées à C# 11 et en permettant de créer et de configurer des API avec seulement quelques lignes de code. Les nombreuses améliorations apportées aux outils, des tunnels de développement qui facilitent le débogage des intégrations d'API en nuage à la création de conteneurs directement à partir du SDK .NET, aident les développeurs à être plus productifs.

Nous mettrons à jour les nouveautés de .NET 8 tout au long de la version. Il décrira les principales fonctionnalités de l'ensemble de la version, tandis que les articles de blog se concentreront sur les nouvelles fonctionnalités de chaque version préliminaire.

Vous pouvez lire ce que nous avons livré dans la première version préliminaire en faisant défiler la page. Tout d'abord, jetons un coup d'œil sur ce qu'est la vision pour .NET 8.

La meilleure plateforme et les meilleurs outils pour les développeurs natifs du cloud

Nous pensons que les développeurs .NET doivent être en mesure de transférer rapidement leurs applications vers le cloud, de les faire évoluer sans compromettre les performances et de les faire évoluer en fonction des données et des commentaires exploitables concernant les applications en production. Nous allons investir pour faciliter la gestion de l'expérience complète de bout en bout, du développement et des tests locaux à l'intégration et au déploiement continus. Notre objectif est de faciliter la mise en œuvre d'architectures de microservices et la création et le déploiement de conteneurs.

Une expérience formidable grâce à l'utilisation de MAUI et Blazor hybrides pour le développement multiplateforme mobile et bureau

À l'époque de .NET 7, nous avons publié le SDK .NET Multi-platform App UI (MAUI) et la prise en charge des outils Visual Studio. .NET MAUI fournit un cadre pour la création d'applications natives pour les appareils mobiles et de bureau qui fonctionnent sous Android, iOS, macOS et Windows avec un seul code C#. Outre la prise en charge de l'interface utilisateur XAML, vous pouvez également utiliser Blazor pour créer des applications hybrides avec des composants d'interface utilisateur Razor qui peuvent accéder aux plates-formes natives des appareils et être partagés entre le mobile, le bureau et le Web. L'équipe .NET prévoit de s'appuyer sur ces expériences et de se concentrer sur l'amélioration de la qualité, de la stabilité, des performances et de l'intégration du SDK et des outils.

Momentum : l'accent est mis sur la qualité et les performances, en fonction de vos commentaires

Chaque version de .NET apporte des améliorations en termes de performances, de qualité, de stabilité et de facilité d'utilisation des API, des bibliothèques et des frameworks qui composent l'écosystème .NET actif et en pleine expansion. Bon nombre de ces améliorations ont été identifiées et classées par ordre de priorité par les clients et les membres de la communauté. .NET 8 suivra la même tendance, en s'appuyant sur vos commentaires très appréciés pour nous aider à guider notre vision et à nous concentrer sur nos objectifs.

Soyez à niveau et restez à jour

L'assistance à la mise à niveau de .NET est un outil précieux qui aide les développeurs à faire migrer leurs applications des anciennes versions de .NET Framework vers les nouvelles versions. La dernière version de cet outil est dotée de fonctionnalités améliorées qui prennent en charge de nouveaux scénarios et traitent davantage de cas. Grâce à cet outil, les développeurs peuvent désormais mettre à niveau leurs applications vers .NET 6 ou .NET 7 en toute simplicité.

L'outil peut détecter et suggérer automatiquement les modifications à apporter au code pour assurer la compatibilité avec les nouvelles versions du framework. En outre, il peut gérer des scénarios plus complexes, comme la mise à niveau d'applications qui utilisent des bibliothèques tierces et l'intégration de nouvelles fonctionnalités de la plate-forme. Ces améliorations font de l'assistance à la mise à niveau de .NET un outil indispensable pour les développeurs qui souhaitent maintenir leurs applications à jour et tirer parti des dernières fonctionnalités de .NET. Cet outil a récemment été introduit en tant qu'extension de Visual Studio pour vous aider à effectuer la mise à niveau depuis le confort de Visual Studio.

Cibler .NET 8

Pour cibler .NET 8, vous devez d'abord vous assurer que le SDK .NET 8 est installé à partir du site officiel de Microsoft. Ensuite, vous pouvez créer un nouveau projet et préciser que vous souhaitez cibler .NET 8 en définissant le cadre cible approprié dans les paramètres du projet.

Vous pouvez également mettre à jour un projet existant pour cibler .NET 8 en modifiant le cadre cible dans les propriétés du projet. Pour ce faire, cliquez avec le bouton droit de la souris sur le projet dans Visual Studio ou votre IDE préféré, sélectionnez "Propriétés", puis l'onglet "Application". À partir de là, vous pouvez choisir la version du framework cible que vous souhaitez utiliser. Ceci définira le framework cible approprié :

Code : Sélectionner tout
<TargetFramework>net8.0</TargetFramework>

Gardez à l'esprit que cibler .NET 8 peut nécessiter des modifications de votre code ou de vos dépendances, car il peut y avoir des changements dans les API ou d'autres fonctionnalités des versions précédentes de .NET. Nous vous conseillons de consulter la documentation et les notes de mise à jour de .NET 8 pour vous assurer que votre code et vos dépendances sont compatibles avec la nouvelle version.

Nouveautés de .NET 8 Preview 1

Notre premier aperçu regorge de nouvelles fonctionnalités que vous pouvez essayer dès aujourd'hui. Voici un résumé de ce à quoi vous pouvez vous attendre.

Native AOT

Les premières fonctions NativeAOT ont été livrées dans .NET 7 et ciblaient les applications console. La compilation Ahead-of-Time (AOT) est une fonctionnalité importante de .NET qui peut avoir un impact significatif sur les performances des applications .NET. L'équipe .NET se concentrera sur l'affinage de certains éléments fondamentaux pour .NET 8 tels que la taille. La publication d'une application avec Native AOT crée une version entièrement autonome de votre application qui n'a pas besoin d'un runtime séparé car tout est inclus dans un seul fichier. Depuis l'aperçu 1, ce fichier unique est plus petit. En fait, les versions Linux sont maintenant jusqu'à 50 % plus petites.

Voici les tailles d'une application "Hello, World" avec Native AOT qui inclut l'intégralité du runtime .NET :


Native AOT continuera à s'étendre et à cibler d'autres scénarios d'application dans .NET 8.

Au cas où vous ne seriez pas familier avec AOT, voici quelques avantages qu'il procure :

  • Empreinte mémoire réduite : Le code compilé par AOT nécessite moins de mémoire que le code compilé par JIT, car le compilateur JIT génère du code intermédiaire qui n'est pas nécessaire dans les applications compilées par AOT. Cela peut être particulièrement bénéfique pour les appareils disposant d'une mémoire limitée, tels que les systèmes embarqués et les appareils mobiles.
  • Amélioration du temps de démarrage : Le code compilé par AOT démarre plus rapidement que le code compilé par JIT, car il élimine la nécessité pour le compilateur JIT de générer du code intermédiaire et d'optimiser le code pour l'environnement matériel et logiciel spécifique. Cela peut être particulièrement bénéfique pour les applications qui doivent démarrer rapidement, comme les services système, les "fonctions" sans serveur et les tâches d'arrière-plan.
  • Amélioration de l'autonomie de la batterie : Le code compilé AOT consomme moins d'énergie par rapport au code compilé JIT, car il élimine la nécessité pour le compilateur JIT de générer du code intermédiaire et d'optimiser le code pour l'environnement matériel et logiciel spécifique. Cela peut être particulièrement bénéfique pour les appareils qui dépendent des batteries, comme les appareils mobiles.

Images de conteneurs .NET

Les développeurs .NET peuvent utiliser des images de conteneur pour empaqueter et déployer leurs applications dans un format léger et portable qui fonctionne dans différents environnements et peut être facilement déployé dans le nuage. Le Preview 1 comprend les améliorations suivantes dans la façon dont les images de conteneurs peuvent être utilisées pour les applications .NET :

Mise à jour de la distribution Linux par défaut vers Debian 12 : Les images de conteneurs utilisent maintenant Debian 12 (Bookworm), la version LTS (Long-term support) qui a été livrée plus tôt cette année. Afin de donner à notre communauté suffisamment de temps pour la transition, nous essayons de l'adopter avec le Preview 1.

Changement de balisage : les images de conteneur de l'aperçu .NET 8 utiliseront le balisage 8.0-preview (et non 8.0) et passeront à 8.0 avec les versions candidates. L'objectif de cette approche est de décrire plus clairement les versions préliminaires comme telles. Ce changement a été effectué suite à une demande de la communauté.

Exécuter les images de conteneurs avec des utilisateurs non root : Bien que les images de base des conteneurs soient presque toujours configurées pour s'exécuter avec l'utilisateur root - un paramètre qui tend à être conservé en production - ce n'est pas toujours la meilleure approche. Cependant, il est difficile de configurer chaque application pour qu'elle ait un utilisateur différent, et les images de conteneurs ne sont pas fournies avec un utilisateur non root approprié aux charges de travail des conteneurs.

.NET 8 offre une meilleure solution. À partir de l'aperçu 1, toutes les images de conteneurs que nous publions pourront être utilisées par un utilisateur non root. Voici un exemple de la ligne unique utilisée pour exécuter un conteneur en tant que non-root pour Dockerfiles :

Code : Sélectionner tout
USER app

En outre, vous pouvez maintenant lancer des images de conteneur avec -u app. Le port par défaut est passé du port 80 au port 8080. Il s'agit d'un changement de rupture qui était nécessaire afin d'activer le scénario non-root, puisque le port 80 est un port privilégié.

Runtime et bibliothèques

Méthodes utilitaires pour travailler avec l'aléatoire

System.Random et System.Security.Cryptography.RandomNumberGenerator ont tous deux gagné des méthodes utilitaires pour choisir de manière aléatoire des éléments dans l'ensemble d'entrée ("avec remplacement", appelées GetItems, et pour rendre aléatoire l'ordre d'une portée, appelées Shuffle.

La méthode Shuffle est utile pour réduire le biais de formation dans l'apprentissage automatique (ainsi, la première chose n'est pas toujours la formation et la dernière chose est toujours le test) :

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
YourType[] trainingData = LoadTrainingData();

Random.Shared.Shuffle(trainingData);


IDataView sourceData = mlContext.Data.LoadFromEnumerable(trainingData);

DataOperationsCatalog.TrainTestData split = mlContext.Data.TrainTestSplit(sourceData);
model = chain.Fit(split.TrainSet);

IDataView predictions = model.Transform(split.TestSet);
...

On joue à un jeu ? Que diriez-vous de Simon ?

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
private static ReadOnlySpan<Button> s_allButtons = new[]
{
    Button.Red,
    Button.Green,
    Button.Blue,
    Button.Yellow,
};

...

Button[] thisRound = Random.Shared.GetItems(s_allButtons, 31);
// rest of game goes here ...

System.Numerics et System.Runtime.Intrinsics

Nous avons réimplémenté Vector256<T> pour qu'en interne il soit 2x Vector128<T> ops quand c'est possible. Cela permet une accélération partielle de certaines fonctions lorsque Vector128.IsHardwareAccelerated == true mais Vector256.IsHardwareAccelerated == false, comme sur Arm64.

Ajout de l'implémentation gérée initiale de Vector512<T>. Tout comme l'élément de travail précédent, ceci est implémenté de manière interactive comme 2x Vector256<T> ops (et donc indirectement comme 4x Vector128 ops). Cela permet une accélération partielle de certaines fonctions même lorsque Vector512.IsHardwareAccelerated == false.
- NOTE : Il n'y a pas encore d'accélération directe pour Vector512, même si le matériel sous-jacent le supporte. Une telle fonctionnalité devrait être activée dans un futur aperçu.

Réécriture de Matrix3x2 et Matrix4x4 pour mieux profiter de l'accélération matérielle. Cela a permis d'améliorer les performances jusqu'à 48 fois pour certains benchmarks. Des améliorations de 6 à 10 fois étaient plus courantes.
- NOTE : Des améliorations pour Quaternion et Plane seront apportées dans la Preview 2.

Les Intrinsèques matérielles sont maintenant annotées avec l'attribut ConstExpected. Cela permet aux utilisateurs de savoir quand le matériel sous-jacent attend une constante et donc quand une valeur non constante peut nuire aux performances de manière inattendue.

Ajout de l'API Lerp à IFloatingPointIeee754<TSelf> et donc à float (System.Single), double (System.Double), et System.Half. Cela permet d'effectuer efficacement et correctement une interpolation linéaire entre deux valeurs.

Améliorations de JSON

Nous continuons à améliorer System.Text.Json, en nous concentrant sur l'amélioration des performances et de la fiabilité du générateur de code source s'il est utilisé avec ASP.NET Core dans les applications NativeAOT. La liste suivante présente les nouvelles fonctionnalités livrées avec l'aperçu 1 :

  • Gestion des membres manquants

Il est maintenant possible de configurer le comportement de désérialisation des objets, lorsque la charge utile JSON sous-jacente comprend des propriétés qui ne peuvent pas être mappées à des membres du type POCO désérialisé. Ceci peut être contrôlé en définissant une valeur JsonUnmappedMemberHandling, soit en tant qu'annotation sur le type POCO lui-même, globalement sur JsonSerializerOptions ou programmatiquement en personnalisant le contrat JsonTypeInfo pour les types concernés :

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
JsonSerializer.Deserialize<MyPoco>("""{"Id" : 42, "AnotherId" : -1 }"""); 

// JsonException : The JSON property 'AnotherId' could not be mapped to any .NET member contained in type 'MyPoco'.

[JsonUnmappedMemberHandling(JsonUnmappedMemberHandling.Disallow)]
public class MyPoco
{
   public int Id { get; set; }
}

  • Support du générateur de sources pour les propriétés required et init

Le générateur de sources prend désormais en charge la sérialisation des types avec des propriétés required et init, comme c'est actuellement le cas dans la sérialisation basée sur la réflexion.

  • Prise en charge de la hiérarchie des interfaces

System.Text.Json prend désormais en charge la sérialisation des propriétés des hiérarchies d'interface :

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
IDerived value = new Derived { Base = 0, Derived =1 };

JsonSerializer.Serialize(value); // {"Base":0,"Derived":1}

public interface IBase
{
  public int Base { get; set; }
}

public interface IDerived : IBase
{
  public int Derived { get; set; }
}

public class Derived : IDerived
{
  public int Base { get; set; }
  public int Derived { get; set; }
}

  • Snake Case et Kebab Case

La bibliothèque est maintenant livrée avec des politiques de nommage pour les conversions de noms de propriétés snake_case et kebab-case. Elles peuvent être utilisées de la même manière que la politique de nommage existante camelCase :

Code : Sélectionner tout
1
2
3
var options = new JsonSerializerOptions { PropertyNamingPolicy = JsonNamingPolicy.SnakeCaseLower };

JsonSerializer.Serialize(new { PropertyName = "value" }, options); // { "property_name" : "value" }

Les politiques de nommage suivantes sont maintenant disponibles :

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
namespace System.Text.Json;

public class JsonNamingPolicy
{
  public static JsonNamingPolicy CamelCase { get; }
  public static JsonNamingPolicy KebabCaseLower { get; }
  public static JsonNamingPolicy KebabCaseUpper { get; }
  public static JsonNamingPolicy SnakeCaseLower { get; }
  public static JsonNamingPolicy SnakeCaseUpper { get; }
}

  • Ajout des API JsonSerializer.MakeReadOnly() et IsReadOnly

La classe JsonSerializerOptions a toujours utilisé la sémantique du gel, mais jusqu'à présent, le gel ne pouvait être effectué qu'implicitement en passant l'instance à l'une des méthodes JsonSerializer. L'ajout des nouvelles API permet aux utilisateurs de contrôler explicitement quand leur instance JsonSerializerOptions doit être gelée :

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
public class MySerializer
{
  private JsonSerializerOptions Options { get; }

  public MySerializer()
  {
        Options = new JsonSerializerOptions(JsonSerializerDefaults.Web) { Converters = { new MyCustomConverter() } };
        Options.MakeReadOnly(); // Make read-only before exposing the property.
  }
}

Nouveaux types axés sur les performances dans les bibliothèques de base
Plusieurs nouveaux types ont été ajoutés aux bibliothèques de base pour permettre aux développeurs d'améliorer les performances de leur code dans des scénarios courants.

Le nouvel espace de noms System.Collections.Frozen fournit des collections FrozenDictionary<TKey, TValue> et FrozenSet<T>. Ces types fournissent une surface immuable telle que, une fois créée, aucune modification n'est autorisée sur les clés ou les valeurs. Cela permet aux collections de mieux optimiser les opérations de lecture ultérieures (par exemple, TryGetValue) en fonction des données fournies, en choisissant de prendre plus de temps lors de la construction pour optimiser tous les accès futurs. Ceci est particulièrement utile pour les collections alimentées lors de la première utilisation et ensuite persistées pour la durée d'un service à longue durée de vie, par exemple.

Code : Sélectionner tout
1
2
3
4
5
6
7
8
private static readonly FrozenDictionary<string, bool> s_configurationData =

    LoadConfigurationData().ToFrozenDictionary(optimizeForReads: true);
...
if (s_configurationData.TryGetValue(key, out bool setting) && setting)
{
    Process();
}

Le type existant ImmutableArray<T>.Builder a également gagné une nouvelle méthode pour convertir efficacement son contenu en un ImmutableArray<T>. .NET 8 introduit DrainToImmutable(), qui renvoie le contenu actuel sous forme de tableau immuable et réinitialise la collection du constructeur à un tableau de longueur nulle, en choisissant l'approche la plus efficace pour ce faire. Cette méthode peut être utilisée au lieu d'appeler conditionnellement ToImmutable() ou MoveToImmutable() en fonction du nombre d'éléments.

Le nouveau type IndexOfAnyValues<T> est un autre exemple de nouveau type qui aide le développeur à investir un peu de temps au départ en échange d'une exécution beaucoup plus rapide par la suite. En plus de nouvelles méthodes comme IndexOfAnyInRange, de nouvelles surcharges de IndexOfAny ont été ajoutées et acceptent une instance IndexOfAnyValues<T>, qui peut être créée pour représenter un ensemble de valeurs T à rechercher. La création de cette instance permet de dériver toutes les données nécessaires afin d'optimiser les recherches ultérieures. Par exemple, si vous recherchez régulièrement toutes les lettres et tous les chiffres ASCII, ainsi que quelques caractères de ponctuation, vous auriez pu écrire précédemment :

Code : Sélectionner tout
1
2
3
private static readonly char[] s_chars = "-.0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz".ToCharArray();
...
int i = str.IndexOfAny(s_chars);

Cependant, cela nécessite soit de ne faire aucune sorte de vectorisation pour améliorer l'efficacité de la recherche, soit de prendre du temps à chaque invocation d'IndexOfAny pour calculer l'état nécessaire pour accélérer l'opération. Maintenant, au lieu de cela, il peut être écrit comme :

Code : Sélectionner tout
1
2
3
private static readonly IndexOfAnyValues<char> s_chars = IndexOfAnyValues.Create("-.0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz");
...
int i = str.AsSpan().IndexOfAny(s_chars);

précalculer tout cet état une fois de telle sorte qu'il soit disponible pour être réutilisé à chaque invocation ultérieure de IndexOfAny.
Ce schéma se répète à nouveau avec le nouveau type CompositeFormat. .NET prend depuis longtemps en charge le formatage des chaînes de caractères par le biais d'API telles que string.Format et StringBuilder.AppendFormat, par exemple :

Code : Sélectionner tout
1
2
static string GetMessage(int min, int max) => 
    string.Format(CultureInfo.InvariantCulture, "Range from {0} to {1}", min, max);

C# 6 a ajouté la prise en charge de l'interpolation de chaînes de caractères, puis C# 10, en conjonction avec .NET 6, a considérablement amélioré l'efficacité de ces opérations, permettant d'écrire la même opération sous la forme suivante :

Code : Sélectionner tout
1
2
static string GetMessage(int min, int max) =>
    string.Create(CultureInfo.InvariantCulture, $"Range from {min} to {max}");

mais en effectuant tout le travail qui peut être précalculé (par exemple, l'analyse de la chaîne de format) au moment de la compilation plutôt qu'à chaque invocation de string.Format. Cependant, cela nécessite que la chaîne de format soit connue au moment de la compilation afin qu'elle puisse être analysée au moment de la compilation... qu'en est-il si elle n'est pas connue avant l'exécution, par exemple si elle est chargée à partir d'un fichier de ressources ou d'un autre moyen dynamique ? Pour cela, .NET 8 ajoute le type CompositeFormat. Comme pour IndexOfAnyValues<T>, il permet d'effectuer une opération qui, autrement, devrait être réalisée à chaque utilisation, et de l'extraire pour la réaliser une seule fois.

Code : Sélectionner tout
1
2
3
4
private static readonly CompositeFormat s_rangeMessage = CompositeFormat.Parse(LoadRangeMessageResource());
...
static string GetMessage(int min, int max) =>
    string.Format(CultureInfo.InvariantCulture, s_rangeMessage, min, max);

Ces nouvelles surcharges prennent également en charge les arguments génériques, afin d'éviter les surcharges de mise en boîte associées au fait de tout prendre comme object.

.NET 8 Preview 1 prend également en charge de nouveaux algorithmes de hachage axés sur les performances, notamment les nouveaux types XxHash3 et XxHash128 qui fournissent des implémentations des algorithmes de hachage rapides XXH3 et XXH128.

SDK .NET

dotnet publish et dotnet pack produisent des actifs Release par défaut

Les verbes Publish et Pack sont destinés à produire des actifs de production, ce qui signifie qu'ils doivent produire des actifs de version. Dans .NET 8, ils le feront par défaut. Les gens demandaient cela depuis un certain temps. Désolé que cela ait pris tant de temps !

Cette fonctionnalité est contrôlée par les propriétés booléennes PublishRelease et PackRelease. Elles ont la valeur true par défaut.

Il est plus facile de démontrer cette fonctionnalité avec dotnet publish :

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
/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/

Notez que PublishRelease et PackRelease existent également dans .NET 7 à partir du SDK 7.0.200. Elles sont optionnelles dans .NET 7 et doivent être définies sur true pour fournir le même comportement.

Support Linux

Construisez votre propre .NET à partir de dotnet/dotnet

.NET peut maintenant être construit sous Linux directement à partir du dépôt dotnet/dotnet. Il utilise dotnet/source-build pour construire les moteurs d'exécution, les outils et les SDK .NET. Il s'agit du même build que Red Hat et Canonical utilisent pour construire .NET, par exemple. Au fil du temps, nous l'étendrons pour prendre en charge macOS et Windows.

La construction dans un conteneur sera l'approche la plus facile pour de nombreuses personnes, puisque nos images de conteneur dotnet-buildtools/prereqs contiennent toutes les dépendances requises.

Nous appelons ce nouveau référentiel "Virtual Mono Repository" (VMR). Il présente les avantages d'un vrai dépôt mono mais est une projection régulièrement mise à jour des nombreux dépôts existants dans lesquels les contributeurs travaillent (plus efficacement) chaque jour. Nous pensons que la séparation entre le VMR et les "working repos" beaucoup plus petits est l'avenir du projet .NET. Nous pensons que les fonctionnalités transversales seront plus faciles à construire dans le VMR, mais nous n'en sommes pas encore là.

Nous considérons cette nouvelle approche comme une avancée significative dans l'accessibilité à la construction de .NET en tant que produit complet à partir des sources.

Avant .NET 8, la construction à partir de la source était possible, mais nécessitait la création d'un "tarball source" à partir du commit dotnet/installer qui correspondait à une version. Cela n'est plus nécessaire. Le dépôt aura des balises correspondant à chaque version, ainsi que les branches main et release/8.0-previewN qui suivent continuellement l'état du produit.

.NET 8 + images de conteneurs Ubuntu Chiseled

Nous publions des images Ubuntu Chiseled avec .NET 8. Ce type d'image est destiné aux développeurs qui souhaitent bénéficier des avantages de l'informatique de type appliance, encore plus qu'avec les conteneurs ordinaires. Nous nous attendons à ce que les images ciselées Ubuntu soient prises en charge en production par Canonical et Microsoft au moment de la sortie de .NET 8.

Nous prévoyons de livrer les images dotnet/monitor exclusivement en tant qu'Ubuntu Chiseled, à partir de .NET 8. C'est remarquable car les images de moniteurs sont les seules images d'applications de production que nous publions.

Les images ciselées présentent de nombreux avantages :

  • Images ultra-petites (taille et surface d'attaque réduites)
  • Pas de gestionnaire de paquets (évite toute une catégorie d'attaques)
  • Pas de shell (évite toute une série d'attaques)
  • Non-root (évite toute une classe d'attaques)

Les images ciselées sont actuellement publiées dans nos dépôts nocturnes, pour les versions .NET 6 et .NET 7.

Support Linux et cible de la baseline

Nous mettons à jour nos baselines minimales pour Linux pour .NET 8. Il y a trois changements notables.

  • Le produit .NET sera construit en ciblant Ubuntu 16.04, pour toutes les architectures. C'est principalement important pour définir la version minimale de la glibc pour .NET 8. Par exemple, à cause de ce changement, .NET 8 ne pourra même pas démarrer sur Ubuntu 14.04, par exemple.
  • Pour Red Hat Enterprise Linux (RHEL), nous prendrons en charge RHEL 8+, en abandonnant RHEL 7.
  • Nous ne publierons une déclaration de prise en charge que pour RHEL, mais nous souhaitons que cette prise en charge s'applique aux autres distributions de l'écosystème RHEL.

Il n'y a pas d'autres changements significatifs. Nous continuerons à prendre en charge Linux sur les architectures Arm32, Arm64 et x64.

Notez que ces changements ne s'appliquent qu'à la version Microsoft. Les organisations qui utilisent la construction à la source feront des choix différents, produisant généralement une construction pour et qui ne fonctionne qu'avec une seule version de distro, comme Ubuntu 24.04.

Ce qui suit présente la version de la glibc d'Ubuntu 16.04 et un modèle pour la découvrir pour d'autres distros.

Code : Sélectionner tout
1
2
3
4
5
6
$ docker run --rm ubuntu:16.04 ldd --version
ldd (Ubuntu GLIBC 2.23-0ubuntu11.3) 2.23
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

Clôture

En conclusion, .NET 8 Preview 1 est un témoignage de la puissance de la collaboration entre une équipe diversifiée d'ingénieurs chez Microsoft et une communauté open source très engagée. Les nouvelles fonctionnalités et les améliorations de .NET 8 sont le résultat direct du travail acharné et du dévouement de cette communauté, et nous sommes incroyablement reconnaissants de la contribution de chacun.

Nous sommes fiers de faire partie d'une communauté qui valorise l'inclusion et la diversité, et nous nous engageons à construire un écosystème technologique accessible à tous. Nous sommes convaincus qu'en travaillant ensemble, nous pouvons réaliser de grandes choses, et nous sommes impatients de voir ce que l'avenir réserve à .NET.

Nous tenons à remercier sincèrement tous ceux qui ont contribué à .NET 8 jusqu'à présent, que ce soit par des contributions de code, des rapports de bogue ou des commentaires. Vos contributions ont été déterminantes pour faire de .NET 8 Preview 1 une réalité, 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 premier aperçu de .NET 8 ?

Voir aussi :

.NET 7 est maintenant disponible en tant que plateforme de développement unifiée de Microsoft, et apporte des améliorations pour .NET MAUI et le support de .NET pour ARM64
Microsoft annonce la première version candidate de .NET 7, testé avec Visual Studio 17.4 Preview 2
Microsoft publie .NET 7 Preview 7, le dernier aperçu de la nouvelle version du framework avant la sortie de la première version candidate, cet aperçu apporte de nouvelles améliorations au framework

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de daerlnaxe
Membre éprouvé https://www.developpez.com
Le 01/04/2024 à 9:49
Je viens de tester, je ne m'y retrouve absolument plus du tout.

Je ne sais pas s'il me manque des éléments, les pages d'aide n'ont pas suivi sur le site de ce que je vois. Magnifique !!!

De simples custom command pour wpf ont déclenché un enfer.
0  0