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 annule le changement controversé de .NET après le tollé de la communauté open source
.NET 6 inclura désormais le rechargement à chaud sur plusieurs plateformes

Le , par Stéphane le calme

79PARTAGES

7  0 
Microsoft revient sur sa décision de supprimer une fonctionnalité clé de sa prochaine version .NET 6, après un tollé général de la communauté open source. Il y a quelques jours, l'éditeur a décidé de supprimer un élément clé de Hot Reload dans la prochaine version de .NET 6, une fonctionnalité qui permet aux développeurs de modifier le code source pendant qu'une application est en cours d'exécution et de voir immédiatement les résultats. C'est une fonctionnalité que beaucoup attendaient avec impatience d'utiliser dans Visual Studio Code et sur plusieurs plateformes, jusqu'à ce que Microsoft prenne une décision controversée de dernière minute de la verrouiller à Visual Studio 2022.

L'expérience .NET Hot Reload a été annoncée pour la première fois dans Visual Studio 2019 version 16.11 (Preview 1) et via les outils de ligne de commande dotnet watch dans .NET 6 (Preview 4). Avec Hot Reload, vous pouvez désormais modifier le code source géré de vos applications pendant que l'application est en cours d'exécution, sans avoir besoin de mettre manuellement en pause ou d'atteindre un point d'arrêt. Effectuez simplement une modification prise en charge pendant l'exécution de votre application et, dans la nouvelle expérience Visual Studio, utilisez le bouton « Appliquer les modifications de code » pour appliquer vos modifications.


Hot Reload fonctionne avec de nombreux types de projets existants et à venir tels que WPF, Windows Forms, les Preview .NET MAUI, les applications ASP.NET Core code-behind, les applications console, WinUI 3 (débogueur géré requis) et bien d'autres. Cette prise en charge est très large avec l'expérience de base de tout projet alimenté par les environnements d'exécution .NET Framework ou CoreCLR.

Avec Hot Reload, l'objectif de Microsoft est de rendre cette expérience disponible quelle que soit la manière dont vous préférez lancer votre application. Avec la version d'aujourd'hui, vous pouvez désormais utiliser cette expérience via l'expérience de débogage Visual Studio entièrement intégrée ou l'outil de ligne de commande dotnet watch, avec plus d'options à venir dans les versions ultérieures.

Mise à jour vers la prise en charge du rechargement à chaud via dotnet watch

Il y a quelques jours, dans un billet de blog, Dmitry Lyalin, Principal Program Manager, .NET (Hot Reload, XAML Tooling & .NET MAUI) indiquait que l'expérience complète de Hot Reload sera livré avec Visual Studio 2022 :

« Plus tôt cette année, nous avons annoncé .NET Hot Reload, un projet ambitieux visant à proposer Hot Reload au plus grand nombre de développeurs .NET possible. Nous avons commencé ce voyage avec un premier aperçu disponible dans Visual Studio 2019 et promis beaucoup plus à venir dans Visual Studio 2022 où l'expérience complète serait livrée. Je suis ravi d'utiliser ce billet de blog pour vous tenir au courant de nos progrès vers cet objectif et de toutes les merveilleuses fonctionnalités qui arriveront le 8 novembre 2021 lorsque nous publierons en disponibilité générale.

« Pour tous ceux qui découvrent Hot Reload, voici une introduction rapide. L'expérience Hot Reload dans Visual Studio fonctionne à la fois pour les applications managées .NET et C++ natives (fait amusant, nous n'avions pas prévu à l'origine de prendre en charge C++ dans la première version, mais nous y sommes parvenus !).

« Quel que soit le type d'application sur laquelle vous travaillez, notre objectif avec Hot Reload est de vous économiser autant de redémarrages d'applications que possible entre les modifications, ce qui vous rend plus productif en réduisant le temps que vous passez à attendre que les applications soient reconstruites, redémarrées, re- accédez à l'emplacement précédent où vous étiez dans l'application elle-même, etc. Nous y parvenons en vous permettant de modifier les fichiers de code de vos applications et d'appliquer ces modifications de code immédiatement à l'application en cours d'exécution, également appelée "recharge à chaud" ».

Lors de son annonce, une partie à susciter la polémique, notamment :

« Tout au long de l'année dernière, nous avons travaillé pour permettre la meilleure expérience de rechargement à chaud possible dans Visual Studio 2022 et .NET 6. Une partie de notre objectif était d'explorer également la mise à disposition de cette fonctionnalité aux clients via une variété de mécanismes tels que l'apport de la pleine la puissance de Hot Reload à autant de développeurs .NET et C++ que possible lors de l'exécution via le débogueur Visual Studio 2022, la prise en charge de Hot Reload lors de l'exécution d'applications .NET 6 sans le débogueur, et la prise en charge très basique de Hot Reload que nous avons ajoutée aux outils .NET SDK via dotnet watch.

« Au fur et à mesure que nous réfléchissons à ce qui a été accompli et à ce qui nous attend encore, le retard continue de croître. Cela inclut de nombreux scénarios de grande valeur qui profiteront au plus grand nombre de développeurs, y compris des domaines d'intérêt tels que .NET MAUI, Blazor, l'ajout de la prise en charge de plus de types de modifications, une expérience plus optimisée lors de l'utilisation d'applications XAML, et bien plus encore.

« Compte tenu de ces considérations, nous avons décidé qu'à partir de la prochaine version en disponibilité générale .NET 6, nous activerons la fonctionnalité de rechargement à chaud uniquement via Visual Studio 2022 afin que nous puissions nous concentrer sur la fourniture des meilleures expériences au plus grand nombre d'utilisateurs. Nous continuerons également à ajouter Hot Reload à Visual Studio pour Mac dans une future version ».

Les développeurs l'ont interprété de différentes manières. Aussi, dans un soucis de clarification, Lyalin a indiqué : « Pour clarifier les choses, nous ne publions pas Hot Reload en tant que fonctionnalité de l'outil dotnet watch. Nous investissons toute notre énergie dans Visual Studio 2022 et travaillons pour prendre en charge le rechargement à chaud dans Visual Studio pour Mac dans une future version ».

Cette précision a entraîné de vives critiques au sein de la communauté des développeurs, poussant l'équipe à rectifier sa trajectoire. Dans un billet de blog, Scott Hunter, Director Program Management, .NET s'est excusé au nom de l'équipe, demandant de l'indulgence, et a annoncé qu'elle revenait sur sa décision :

« La semaine dernière, notre article de blog et la suppression de la capacité de rechargement à chaud du référentiel .NET SDK ont suscité de nombreux retours de la communauté.

« Tout d'abord, nous voulons nous excuser. Nous avons fait une erreur en exécutant notre décision et avons pris plus de temps que prévu pour répondre à la communauté. Nous avons approuvé le Pull Request visant à réactiver ce chemin de code et il fera parti de la version en disponibilité générale .NET 6.

« En tant qu'équipe, nous nous engageons à ce que .NET soit une plateforme ouverte et la développons de manière transparente. Le fait même que nous ayons décidé d'adopter une posture ouverte par défaut dès le départ pour développer la fonctionnalité Hot Reload en est la preuve. Cela dit, comme toute équipe de développement, nous devons de temps en temps examiner la qualité, le temps, les ressources pour faire des compromis tout en continuant à progresser. La grande majorité des développeurs .NET utilisent Visual Studio et nous voulons nous assurer que VS offre la meilleure expérience pour .NET 6.

« Le temps étant de plus en plus court pour la publication des versions .NET 6 et Visual Studio 2022, nous avons choisi de nous concentrer d'abord sur l'introduction de Hot Reload vers VS 2022. Nous avons fait une erreur en exécutant ce plan dans la façon dont il a été exécuté. Dans notre effort de portée, nous avons fini par supprimer le code source par inadvertance au lieu de simplement ne pas appeler ce chemin de code. Nous avons sous-estimé le nombre de développeurs qui dépendent de cette capacité dans leurs environnements dans tous les scénarios, et comment la CLI était utilisée avec Visual Studio pour stimuler la productivité de la boucle interne par beaucoup.

« Nous sommes toujours à l'écoute des commentaires de nos clients pour répondre à leurs besoins. Merci d'avoir fait entendre vos commentaires. Nous sommes désolés d'avoir bouleversé tant de membres de la communauté à cause de ce changement sur de nombreux paramètres, notamment le timing et l'exécution.

« Notre volonté est de créer un écosystème ouvert et dynamique pour .NET. Comme c'est le cas pour de nombreuses entreprises, nous apprenons à équilibrer les besoins de la communauté OSS et à être un sponsor d'entreprise pour .NET. Parfois, nous ne comprenons pas bien. Lorsque nous ne le faisons pas, le mieux que nous puissions faire est d'apprendre de nos erreurs et de mieux avancer ».

Frameworks et scénarios d'application pris en charge

« Depuis que nous avons annoncé cette fonctionnalité en mai 2021, une question très courante était "Est-ce que Hot Reload fonctionnera avec mon combo d'applications .NET (framework/version) ?", nous avons fait d'énormes progrès pour répondre OUI dans la plupart des situations, ici sont les points forts :
  • Lorsque vous utilisez Visual Studio 2022 et démarrez votre application avec le débogueur, l'expérience de base de rechargement à chaud fonctionne avec la plupart des types d'applications .NET et de versions de framework, cela inclut .NET Framework, .NET Core et .NET 5+ (pour C# et VB. NET le cas échéant). Les types d'applications prises en charge incluent le Web (modifications de code), le bureau, le mobile, le cloud et d'autres types de projets. La règle clé ici est que si vous utilisez le débogueur, supposez que Hot Reload est disponible et essayez-le !
  • Lorsque vous utilisez Visual Studio 2022 mais que vous n'utilisez pas le débogueur (par exemple, en utilisant CTRL-F5 pour démarrer l'application), le rechargement à chaud est désormais disponible même sans le débogueur lors du ciblage de la plupart des types d'applications .NET 6. Cela signifie que les applications ne ciblant pas .NET 6 (.NET 5 ou inférieur) ne prendront pas en charge le scénario «*pas de débogueur*» et doivent utiliser le débogueur pour obtenir la prise en charge du rechargement à chaud.
  • Lorsque vous utilisez Visual Studio 2022 avec une application .NET 6, la plupart des types de scénarios sont pris en charge. Cela ne se limite pas simplement au scénario « sans débogueur » mentionné ci-dessus, il inclut également la prise en charge des types de projets tels que .NET MAUI et Blazor et plus généralement l'édition des fichiers Razor et CSS Hot Reload dans les applications ASP.NET. Il inclut également d'autres optimisations mineures dans des frameworks d'applications supplémentaires. L'utilisation à la fois de Visual Studio 2022 et la mise à jour de vos applications vers .NET 6 vous offriront définitivement l'expérience de rechargement à chaud la plus puissante et nous espérons que vous l'essayerez.

Visual Studio 2022 lors de l'utilisation du débogueur

Lors de l'utilisation de Visual Studio 2022 et du démarrage de l'application avec le débogueur, Hot Reload fonctionne avec la plupart des frameworks d'applications, y compris les types d'applications typiques tels que Console, Windows Forms (WinForms), WPF, UWP, WinUI 3 et la plupart des types de sites Web ASP.NET projets (pour les modifications de code-behind), y compris ASP.NET MVC, Web API et même des projets Web Forms plus anciens. WinUI 3 utilise par défaut le débogage en mode mixte qui ne prend pas en charge le rechargement à chaud. Vous pouvez modifier cela dans les paramètres du projet en activant le débogueur géré qui permettra au rechargement à chaud de fonctionner correctement.

Cette liste n'est également qu'un exemple. La vraie réponse est partout où vous avez .NET et que vous utilisez le débogueur managé Visual Studio, vous devriez obtenir une prise en charge de base du rechargement à chaud.

Cela signifie que même des projets tels que Azure Functions fonctionneront parfaitement dans ce scénario. Microsoft vous encourage à essayer votre combinaison et à l'informer si vous rencontrez des problèmes.

Lors de l'utilisation de Visual Studio 2022 mais sans utiliser le débogueur

Le rechargement à chaud est désormais disponible sans le débogueur lors du ciblage de la plupart des types d'applications .NET 6, y compris les types de projets tels que Console, WPF, Windows Forms (WinForms), ASP.NET Core MVC, Web API et Blazor. Microsoft sait que certains développeurs ont une bonne raison ou une préférence pour démarrer leurs applications sans le débogueur et espère que cette fonctionnalité supplémentaire leur donnera une valeur pour peu ou pas d'impact sur le temps de démarrage.

Cette fonctionnalité est exclusive à .NET 6+ et les applications ne ciblant pas .NET 6 (.NET 5 ou inférieur) ne prendront pas en charge le scénario « pas de débogueur » et doivent utiliser le débogueur pour accéder à la fonctionnalité de rechargement à chaud.

Sachez également que tous les types de projets ne seront pas pris en charge pour le scénario « pas de débogueur » dans la première version. Spécifiquement:
  • Les applications .NET MAUI et WinUI 3 continueront de fonctionner uniquement avec le rechargement à chaud lors de l'utilisation du débogueur. Microsoft espère améliorer cette situation dans une future version, mais n'est pas encore en mesure de communiquer un calendrier précis.
  • Les applications UWP ne sont pas non plus prises en charge pour le rechargement à chaud sans le débogueur, c'est par conception et il n'y a actuellement aucun plan pour améliorer cela.

Lors de l'utilisation de Visual Studio 2022 avec une application .NET 6, la plupart des types de scénarios sont pris en charge

Les développeurs capables d'utiliser à la fois Visual Studio 2022 et de travailler sur des applications qui ciblent .NET 6 bénéficieront de l'expérience de rechargement à chaud la plus aboutie et la plus performante.

Voici les points saillants de ce qui est pris en charge :
  • Applications .NET MAUI (iOS, Android et WinUI), y compris les applications .NET MAUI standard et .NET MAUI Blazor Hybrid
  • Applications Blazor (Serveur et WebAssembly). Dans la version Visual Studio 2022 en disponibilité générale, la prise en charge du rechargement à chaud pour Blazor WebAssembly lors de l'utilisation du débogueur Visual Studio n'est pas encore activée. Vous pouvez toujours obtenir un rechargement à chaud si vous démarrez votre application via Visual Studio sans le débogueur, et Microsoft travaille pour résoudre ce problème dans la prochaine mise à jour de Visual Studio.
  • Édition de fichiers Razor dans les sites Web Blazor et ASP.NET Core standard
  • Rechargement à chaud CSS
  • Possibilité d'obtenir la prise en charge du rechargement à chaud lors de l'exécution d'applications sans le débogueur.
  • Les développeurs ciblant .NET 6 continueront à bénéficier d'améliorations supplémentaires dans les futures mises à jour de Visual Studio 2022, la bande de fonctionnalités .NET et les versions majeures. Ce n'est que le début*!

Scénarios non pris en charge

Même dans la version finale, il y aura toujours des scénarios non pris en charge que vous devez connaître :
  • Les applications Xamarin.Forms ne prendront pas en charge le rechargement à chaud .NET dans les scénarios iOS et Android. Vous obtiendrez un rechargement à chaud lorsque vous ciblerez une application UWP. C'est par conception, et Microsoft ne prévoie pas d'apporter d'autres améliorations.
  • Les applications créées à l'aide de F# ou celles ciblant .NET Native ne prendront pas en charge le rechargement à chaud. (Remarque : XAML Hot Reload continuera d'être disponible et pris en charge pour les clients Xamarin.Forms sur le dernier SDK) Il existe d'autres limitations mineures connues et Microsoft va faire des communications sur certains problèmes et documents GitHub avec plus de détails dans les semaines à venir.

Source : Microsoft

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

Avatar de Stéphane le calme
Chroniqueur Actualités https://www.developpez.com
Le 09/11/2021 à 11:06
Microsoft annonce la sortie de C# 10 dans le cadre de .NET 6 et Visual Studio 2022.
C# 10 apporte des améliorations aux expressions lambda et plusieurs fonctionnalités

« Aujourd'hui, nous sommes heureux d'annoncer la sortie de C# 10 dans le cadre de .NET 6 et Visual Studio 2022 », a indiqué Kathleen Dollard, Principal Program Manager, .NET. Voici les améliorations et nouveautés apportées par cette version.

Utilisations globales et implicites

Les directives using simplifient la façon dont vous travaillez avec les espaces de noms. C# 10 inclut une nouvelle directive using global et des utilisations implicites pour réduire le nombre d'utilisations que vous devez spécifier en haut de chaque fichier.

Directives global using

Si le mot-clé global apparaît avant une directive using, cette utilisation s'applique à l'ensemble du projet*:

Code C# : Sélectionner tout
global using System;

Vous pouvez utiliser n'importe quelle fonctionnalité de using dans une directive using global. Par exemple, l'ajout de static importe un type et rend les membres du type et les types imbriqués disponibles dans tout votre projet. Si vous utilisez un alias dans votre directive using, cet alias affectera également l'ensemble de votre projet*:

Code C# : Sélectionner tout
1
2
global using static System.Console;
global using Env = System.Environment;

Vous pouvez mettre using global dans n'importe quel fichier .cs, y compris Program.cs ou un fichier spécifiquement nommé comme globalusings.cs. Le périmètre de using global est la compilation en cours, qui correspond généralement au projet en cours.

modificateur static

La directive using static nomme un type dont les membres statiques et les types imbriqués vous pouvez accéder sans spécifier de nom de type. La directive using static a été introduite avec C# 6. Sa syntaxe est la suivante :

Code C# : Sélectionner tout
using static <nom de type complet>;

Le <nom de type complet> est le nom du type dont les membres statiques et les types imbriqués peuvent être référencés sans spécifier de nom de type. Si vous ne fournissez pas de nom de type qualifié complet (le nom d’espace de noms complet avec le nom de type), C# génère l’erreur de compilateur CS0246: « le type ou le nom d’espace de noms’type/espace de noms’est introuvable (une directive using ou une référence d'assemblage est-elle manquante ?) ».

La directive using static s’applique à tout type ayant des membres statiques (ou des types imbriqués), même s’il a également des membres d’instance. Toutefois, les membres d’instance ne peuvent être appelés que par l’instance du type.

Vous pouvez accéder aux membres statiques d'un type sans devoir qualifier l'accès avec le nom du type :

Code C# : Sélectionner tout
1
2
3
4
5
6
7
8
9
using static System.Console;
using static System.Math;
class Program
{
    static void Main()
    {
        WriteLine(Sqrt(3*3 + 4*4));
    }
}

En général, quand vous appelez un membre statique, vous indiquez le nom du type, ainsi que le nom du membre. Entrer plusieurs fois le même nom de type pour appeler des membres du type peut produire du code détaillé et peu clair. Par exemple, la définition suivante d’une classe Circle fait référence à de nombreux membres de la classe Math :

Code C# : 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
using System;
 
public class Circle
{
   public Circle(double radius)
   {
      Radius = radius;
   }
 
   public double Radius { get; set; }
 
   public double Diameter
   {
      get { return 2 * Radius; }
   }
 
   public double Circumference
   {
      get { return 2 * Radius * Math.PI; }
   }
 
   public double Area
   {
      get { return Math.PI * Math.Pow(Radius, 2); }
   }
}

En éliminant la nécessité de référencer explicitement la classe Math chaque fois qu’un membre est référencé, la directive using static génère du code plus propre :

Code C# : 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
using System;
using static System.Math;
 
public class Circle
{
   public Circle(double radius)
   {
      Radius = radius;
   }
 
   public double Radius { get; set; }
 
   public double Diameter
   {
      get { return 2 * Radius; }
   }
 
   public double Circumference
   {
      get { return 2 * Radius * PI; }
   }
 
   public double Area
   {
      get { return PI * Pow(Radius, 2); }
   }
}

using static importe uniquement les membres statiques accessibles et les types imbriqués déclarés dans le type spécifié. Les membres hérités ne sont pas importés. vous pouvez importer à partir de n’importe quel type nommé avec une directive using static, y compris Visual Basic modules. Si des fonctions de niveau supérieur F# apparaissent dans les métadonnées comme membres statiques d’un type nommé dont le nom est un identificateur C# valide, les fonctions F# peuvent être importées.

using static rend les méthodes d'extension déclarées dans le type spécifié disponibles pour la recherche de méthode d'extension. Toutefois, les noms des méthodes d’extension ne sont pas importés dans la portée pour une référence non qualifiée dans le code.

Les méthodes portant le même nom et qui sont importées à partir de différents types par différentes directives using static dans la même unité de compilation ou le même espace de noms forment un groupe de méthodes. La résolution de surcharge au sein de ces groupes de méthodes suit des règles C# normales.

L’exemple suivant utilise la directive using static pour que les membres statiques des classes Console, Math et String soient disponibles sans que vous ayez à spécifier leur nom de type :

Code C# : 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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
using System;
using static System.Console;
using static System.Math;
using static System.String;
 
class Program
{
   static void Main()
   {
      Write("Enter a circle's radius: ");
      var input = ReadLine();
      if (!IsNullOrEmpty(input) && double.TryParse(input, out var radius)) {
         var c = new Circle(radius);
 
         string s = "\nInformation about the circle:\n";
         s = s + Format("   Radius: {0:N2}\n", c.Radius);
         s = s + Format("   Diameter: {0:N2}\n", c.Diameter);
         s = s + Format("   Circumference: {0:N2}\n", c.Circumference);
         s = s + Format("   Area: {0:N2}\n", c.Area);
         WriteLine(s);
      }
      else {
         WriteLine("Invalid input...");
      }
   }
}
 
public class Circle
{
   public Circle(double radius)
   {
      Radius = radius;
   }
 
   public double Radius { get; set; }
 
   public double Diameter
   {
      get { return 2 * Radius; }
   }
 
   public double Circumference
   {
      get { return 2 * Radius * PI; }
   }
 
   public double Area
   {
      get { return PI * Pow(Radius, 2); }
   }
}
// The example displays the following output:
//       Enter a circle's radius: 12.45
//
//       Information about the circle:
//          Radius: 12.45
//          Diameter: 24.90
//          Circumference: 78.23
//          Area: 486.95

Dans cet exemple, la directive using static aurait également pu être appliquée au type Double. L’ajout de cette directive permet d’appeler la méthode TryParse(String, Double) sans spécifier de nom de type. Toutefois, l’utilisation de TryParse sans nom de type crée un code moins lisible, puisqu’il est nécessaire de vérifier les directives using static pour déterminer la méthode du type numérique que TryParse appelle.


ImplicitUsing

La fonctionnalité ImplicitUsing ajoute automatiquement des directives global using communes pour le type de projet que vous créez. Pour activer les utilisations implicites, définissez la propriété ImplicitUsings dans votre fichier .csproj*:

Code XML : Sélectionner tout
1
2
3
4
<PropertyGroup>
    <!-- Other properties like OutputType and TargetFramework -->
    <ImplicitUsings>enable</ImplicitUsings>
</PropertyGroup>

Les utilisations implicites sont activées dans les nouveaux modèles .NET 6.

L'ensemble spécifique de directives d'utilisation globales incluses dépend du type d'application que vous créez. Par exemple, les utilisations implicites d'une application console ou d'une bibliothèque de classes sont différentes de celles d'une application ASP.NET.

Combiner les fonctionnalités using

Les directives using traditionnelles en haut de vos fichiers, les directives using globales et les utilisations implicites fonctionnent bien ensemble. Les utilisations implicites vous permettent d'inclure les espaces de noms .NET appropriés au type de projet que vous créez avec une seule ligne dans votre fichier de projet. Les directives d'utilisation globales vous permettent d'inclure des espaces de noms supplémentaires pour les rendre disponibles tout au long de votre projet. Les directives using en haut de vos fichiers de code vous permettent d'inclure des espaces de noms utilisés par quelques fichiers seulement dans votre projet.

Quelle que soit la façon dont elles sont définies, les directives using supplémentaires augmentent la possibilité d'ambiguïté dans la résolution de noms. Si vous rencontrez ce problème, envisagez d'ajouter un alias ou de réduire le nombre d'espaces de noms que vous importez. Par exemple, vous pouvez remplacer les directives using globales par des directives using explicites en haut d'un sous-ensemble de fichiers.

Si vous devez supprimer des espaces de noms qui ont été inclus via des utilisations implicites, vous pouvez les spécifier dans votre fichier projet*:

Code XML : Sélectionner tout
1
2
3
<ItemGroup>
  <Using Remove="System.Threading.Tasks" />
</ItemGroup>

Vous pouvez également ajouter un espace de noms qui se comporte comme s'il s'agissait de directives using globales, vous pouvez ajouter des éléments Using à votre fichier projet, par exemple*:

Code XML : Sélectionner tout
1
2
3
<ItemGroup>
  <Using Include="System.IO.Pipes" />
</ItemGroup>

Espaces de noms qui portent sur un fichier

De nombreux fichiers contiennent du code pour un seul espace de noms. À partir de C# 10, vous pouvez inclure un espace de noms en tant qu'instruction, suivi d'un point-virgule et sans les accolades*:

Code C# : Sélectionner tout
1
2
3
4
namespace MyCompany.MyNamespace;
 
class MyClass // Note: no indentation
{ ... }

Cela simplifie le code et supprime un niveau d'imbrication. Une seule déclaration d'espace de noms à portée de fichier est autorisée, et elle doit intervenir avant que les types ne soient déclarés.

Le mot clé namespace est utilisé pour déclarer une portée qui contient un ensemble d’objets connexes. Vous pouvez utiliser un espace de noms pour organiser les éléments de code et créer des types globaux uniques.

Code C# : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
namespace SampleNamespace
{
    class SampleClass { }
 
    interface ISampleInterface { }
 
    struct SampleStruct { }
 
    enum SampleEnum { a, b }
 
    delegate void SampleDelegate(int i);
 
    namespace Nested
    {
        class SampleClass2 { }
    }
}

Les déclarations d’espaces de noms avec étendue de fichier vous permettent de déclarer que tous les types d’un fichier se trouvent dans un espace de noms unique. Les déclarations d’espaces de noms avec étendue de fichier sont disponibles avec C# 10. L’exemple suivant est similaire à l’exemple précédent, mais utilise une déclaration d’espace de noms avec étendue de fichier :

Code C# : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
using System;
 
namespace SampleFileScopedNamespace;
 
class SampleClass { }
 
interface ISampleInterface { }
 
struct SampleStruct { }
 
enum SampleEnum { a, b }
 
delegate void SampleDelegate(int i);

L’exemple précédent n’inclut pas d’espace de noms imbriqué. Les espaces de noms de portée de fichier ne peuvent pas inclure de déclarations d’espaces de noms supplémentaires. Vous ne pouvez pas déclarer un espace de noms imbriqué ou un deuxième espace de noms de portée de fichier :

Code C# : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
namespace SampleNamespace;
 
class AnotherSampleClass
{
    public void AnotherSampleMethod()
    {
        System.Console.WriteLine(
            "SampleMethod inside SampleNamespace");
    }
}
 
namespace AnotherNamespace; // Not allowed!
 
namespace ANestedNamespace // Not allowed!
{
   // declarations...
}

Améliorations des expressions lambda et des groupes de méthodes

Microsoft a apporté plusieurs améliorations aux types et à la syntaxe entourant les lambdas. L'entreprise s'attend à ce que ceux-ci soient largement utiles, et l'un des scénarios de conduite a été de rendre les API ASP.NET minimales encore plus simples.

Types naturels pour les lambdas

Les expressions lambda ont maintenant parfois un type « naturel ». Cela signifie que le compilateur peut souvent déduire le type de l'expression lambda.

Jusqu'à présent, une expression lambda devait être convertie en un délégué ou un type d'expression. Dans la plupart des cas, vous utiliserez l'un des types de délégués surchargés Func<...> ou Action<...> dans la BCL*:

Code C# : Sélectionner tout
Func<string, int> parse = (string s) => int.Parse(s);

À partir de C# 10, cependant, si un lambda n'a pas un tel « type cible », l'éditeur va essayer d'en calculer un pour vous*:

Code C# : Sélectionner tout
var parse = (string s) => int.Parse(s);

Vous pouvez survoler var parse dans votre éditeur et voir que le type est toujours Func<string, int>. En général, le compilateur utilisera un délégué Func ou Action disponible, s'il en existe un approprié. Sinon, il synthétisera un type délégué (par exemple, lorsque vous avez des paramètres ref ou que vous avez un grand nombre de paramètres).

Tous les lambdas n'ont pas de types naturels - certains n'ont tout simplement pas assez d'informations sur les types. Par exemple, omettre les types de paramètres laissera le compilateur incapable de décider quel type de délégué utiliser*:

Code C# : Sélectionner tout
var parse = s => int.Parse(s); // ERROR: Not enough type info in the lambda

Le type naturel des lambdas signifie qu'ils peuvent être affectés à un type plus faible, tel que objet ou Delegate*:

Code C# : Sélectionner tout
1
2
object parse = (string s) => int.Parse(s);   // Func<string, int>
Delegate parse = (string s) => int.Parse(s); // Func<string, int>

En ce qui concerne les arbres d'expression, Microsoft fait une combinaison de typage «*cible*» et «*naturel*». Si le type cible est LambdaExpression ou l'Expression non générique (type de base pour toutes les arborescences d'expressions) et que lambda a un type délégué naturel D, l'éditeur produira à la place une Expression<D>*:

Code C# : Sélectionner tout
1
2
LambdaExpression parseExpr = (string s) => int.Parse(s); // Expression<Func<string, int>>
Expression parseExpr = (string s) => int.Parse(s);       // Expression<Func<string, int>>

Types naturels pour les groupes de méthodes

Les groupes de méthodes (c'est-à-dire les noms de méthodes sans listes d'arguments) ont maintenant aussi parfois un type naturel. Vous avez toujours pu convertir un groupe de méthodes en un type délégué compatible*:

Code C# : Sélectionner tout
1
2
Func<int> read = Console.Read;
Action<string> write = Console.Write;

Maintenant, si le groupe de méthodes n'a qu'une seule surcharge, il aura un type naturel*:

Code C# : Sélectionner tout
1
2
var read = Console.Read; // Just one overload; Func<int> inferred
var write = Console.Write; // ERROR: Multiple overloads, can't choose

Source : Microsoft

Voir aussi

Microsoft présente Visual Studio 2022, la prochaine version majeure de Visual Studio. La première Public Preview sera disponible cet été
Visual Studio 2022 Preview 4 est disponible et s'accompagne d'améliorations sur la productivité personnelle et d'équipe, le chargement à chaud dans ASP.NET Core et la gestion de thèmes
Visual Studio 2022 64-bit Preview 2 est disponible, elle apporte de nouvelles fonctionnalités et permet de créer des applications multiplateformes
Visual Studio 2022 Preview 3 est disponible et s'accompagne de la possibilité d'effectuer des tests à distance sur plusieurs plateformes, ainsi que d'une amélioration du thème sombre
Microsoft améliore l'expérience .NET Hot Reload sur Visual Studio 2022, la version de son éditeur qui va bénéficier de l'expérience complète
8  0 
Avatar de youtpout978
Expert confirmé https://www.developpez.com
Le 09/11/2021 à 14:20
Citation Envoyé par Issam Voir le message
heuuu, il n'y a pas de version 2018
Je pense il veut dire 2008
0  0