Discussion :

[dfiad77pro]

Oui, l'EF est vraiment un vaste sujet, autant EF 6.3 peut être utilisé sous Windows avec .net CORE, autant EF core nécessite des améliorations, pour le database first faut vraiment faire du reverse et passer en code first ( sans les migration) donc tout faire à la main

[denisys]

salut sergio_is_back.

Oui, mais ce n’est pas simple, donc, c’est long a développer.
Dans ce que j’avais +- compris des annonces de : .Net Core 3.0
Tu pouvais porter une app développée sur Windows, sur les autres plateformes : Linux , Mac.
Hors dans ce que j’ai testé sur Unbutu 19x64 , lorsque tu lance la commande .Net Core 3.0 , pour créer un app WinForm => KO
En contre partie, lorsque je développe une app avec Visual Studio 2015 (avec une database sqlite), mono arrivera à interpréter le code , avec un message d’erreur .
Qui est très classique, en fait , et la résolution de cette problématique , consiste a installer :
• https://www.winehq.org/
• Redistribuable Visual C++ pour Visual Studio 2015 (https://www.microsoft.com/fr-fr/down....aspx?id=48145)

Mon contexte, est celui, ci.
J’installe mon app sur windows 7x86 , et je peux consommer cette app , lorsque j’utilise Ubuntu 16x86 , en dual boot.
Mais il est vrai , que ce n’est pas simple dans le portage d’application avec cette solution .
Sans compter , qu’il peut y avoir des options d’installation concernant des parties tiers a l’application.
Si tu ajoute un composant (type dll) qui a une relation avec MariaDB , par exemple , rien ,ne prouve , que le composant pourra agir et être opérationnel dans l’os porté.

En claire, on est loin de la formule de Lazarus : write once compile anywhere

Sans compté, que même pour l’option Lazarus , les contraintes existes.
En espérant t’avoir inspiré !!!

[Pol63]

Tu pouvais porter une app développée sur Windows, sur les autres plateformes : Linux , Mac.
Hors dans ce que j’ai testé sur Unbutu 19x64 , lorsque tu lance la commande .Net Core 3.0 , pour créer un app WinForm => KO

Microsoft avait été clair, .net core est multiplateforme mais ne supporte que console et web (pour l'instant)
le pack winforms/wpf n'est qu'une extension Windows de .net core 3, ils n'ont pas réécrit la partie rendu (et ils ne le feront pas)
on est encore quelques uns à espérer un Framework graphique pour .net core (s'il pouvait remplacer Xamarin ca m'arrangerait même, car c'est quand même moins cool que wpf)

ils veulent en effet éviter d'avoir 3 clr à gérer, donc Xamarin devrait basculer sur .net core, peut etre avec le Framework 5 (qui n'est que .net core 4) ou avant, on sait jamais
le .net Framework 4.8 je le vois pas trop basculer sur la clr de .net core auquel cas elle resterait comme elle est, mais je peux me tromper

[StringBuilder]

Tout ce que je vois, c'est que .NET 1.0 (pas Core) était annoncé en grandes pompes pour indiquer un code portable sur toutes les machines (il suffit que quelqu'un écrire un compilo, ce qu'à fait Novell à l'époque avec Mono).
Ensuite, voyant que WinForms serait compliqué à rendre multiplateforme, ils se sont lancé dans WPF et consors.
Mais la mayo n'a pris que sous Windows.
Alors pour séduire Linux, on lance .NET Core qui ne sait pas faire d'UI.
Et au final, on abandonne .NET tout court...

Bref, demain, si on veut faire une UI, on se retrouve de nouveau à faire du WinForm ou WPF sous Windows, et .NET Core ou pas, on retourne à la case départ... on a du code pas portable, tout du moins, pas plus portable qu'avant !

Microsoft a tout bien réécrit son framework, mais au final, en tant que développeur, on n'a rien gagné d'autre que de devoir migrer nos projets une fois de plus... sans toujours comprendre ce que signifie tout ce bordel puisqu'au final rien n'a changé.

[Leruas]

ça devient compliqué.
.NET CORE 3.0 semble ne plus être compatible avec les DLL .NET Framework classique (me le dire si je me trompe), alors qu'on pouvait utiliser le Framework .NET 4.7.x en .NET CORE 1.0 et .NET CORE 2.x (et donc intégrer dans notre projet, des DLL .NET Framework classique, non compatible avec .NET Standard (Core) )
.NET CORE 5.0 va semble t-il réintégrer cette compatibilité, je ne comprends pas la logique derrière.

[Pol63]

microsoft a aussi fait ca pour lui
.net core est beaucoup plus performant (j'ai pas encore fait de test de comparaison, on devrait migrer une appli sur la fin de l'année)
les applis sans UI desktop c'est très utilisé sur azure
et linux est plus performant que windows (à priori)
donc pour azure c'est tout bénef pour Microsoft d'avoir un Framework plus performant qui fonctionne sur linux

pour les développeurs on gagne quand même les perfs et le fait que le framework .net core peut etre intégré à notre appli
on a eut le cas chiant y a quelques mois ou ms a fait une maj de .net framework et notre appli s'est mise à bugger chez nos clients, et c'était bien un bug introduit par ms dans certains cas rares d'utilisation, donc on aurait pas eut ce problème avec le framework intégré (plutot qu'un framework unique pour une machine qui se met à jour sans tests !)
(plus toutes les classes qui ont été intégré à .net core et qui n'existent pas sur .net Framework, même si la réciproque est vraie)

en 2 ou 3 ans ils ont quand même abattu pas mal de boulot pour en arriver là (bonne couverture du fx normal et Windows et wpf inclus pour windows) donc je pense que les 2 prochaines années nous apporterons encore pas mal de chose
et c'est courageux (et surement utile) de reprendre tout à zéro pour reconstruire la même chose en mieux

après ms a bien précisé qu'il n'était pas forcément utile car pas toujours faisable de porter une application .net Framework vers .net core, ca prend énormément de temps
sur une équipe et un logiciel en cours de dev c'est faisable, sur un soft terminé avec un seul développeur pour maintenir ca ne l'est clairement pas
et ce n'est pas spécialement grave, le Framework 4.8 continuera de fonctionner longtemps (les applis vb6 qui ont 20 ans fonctionnent encore pas mal)

mais il n'y a pas de doute que c'est l'avenir, pour un nouveau projet c'est surement un bon choix

[StringBuilder]

.net core est beaucoup plus performant (j'ai pas encore fait de test de comparaison, on devrait migrer une appli sur la fin de l'année)
les applis sans UI desktop c'est très utilisé sur azure
et linux est plus performant que windows (à priori)
donc pour azure c'est tout bénef pour Microsoft d'avoir un Framework plus performant qui fonctionne sur linux

Sur ces points, je suis parfaitement d'accord.

Cependant, personnellement, ce que j'ai compris initialement de la philosophie même de .NET va à l'encontre de la façon dont ça se fait.

.NET c'est "tu codes avec ton langage préféré, sans jamais te soucier de la façon dont ça va tourner au final sur la machine du client".
D'où l'abandon des pointeurs, allocations mémoires, des types portant explicitement le nom CPU (word par exemple).
=> Je code mon programme, que ça tourne sur un x86, x64 ou ARM64, sauf si je commence à vouloir faire un codec de compression vidéo en temps réel (ce pour quoi .NET n'est pas du tout fait) je m'en tamponne, je vais avoir rigoureusement le même code.

Par extension, j'ai envie de dire que si le CLR ou les API qui sont utilisées "derrière le décor" changent, cela ne me concerne même pas.
Et par conséquent, .NET Core aurait, à mon sens, dû être une simple refonte de .NET tout court, sans pour autant que ce soit un Framework différent.

Et tout ce qui n'a pas été repris dans .NET Core aurait dû l'être, quite à être deprecated et avoir un impact négatif sur les performances et la portabilité : au moins, on pouvait suivre l'évolution du Framework sans devoir jeter d'un coup la moitié de son code.

[Pol63]

jeter la moitié de son code ca me parait un peu marseillais ...
il y a un analyseur qui te dis le pourcentage de ton code qui n'existe pas dans .net core 3
on a fait le test y a environ un an et je crois qu'on avait 97% de réutilisable
ce qui ne l'était pas c'était des broutilles comme l'utilisation d'app.config (ca se remplace vite par autre chose, surtout qu'on avait tout centralisé) et wcf server (la partie client existant dans .net core) et là on peut rester sur un exe .net Framework

[freesket]

Il existe une UI multiplateforme sour Xamarin : Xamarin.Forms
Ce framework propose une UI pour UWP, Android, IOS ET Linux, MacOS (en beta pour le moment) :
https://docs.microsoft.com/en-us/xam...latform/other/

Il est fort a parier que tout ceci terminera dans .Net 5.0...

[François DORIN]

Ce framework propose une UI pour UWP, Android, IOS ET Linux, MacOS (en beta pour le moment) :

Quand je vois le travail qu'il reste à faire, je parlerai plutôt d'alpha que de bêta. D'ailleurs, il y a quelques mois, ces plateformes étaient estampillées "Early Preview". Aujourd'hui, ce statut a disparu, on sait seulement quand un support est "stable".
Donc aujourd'hui, l'usage de Xamarin pour réaliser une application bureautique portable est plutôt limitée.

[Stéphane le calme]

.NET Core 3.1 est disponible, il s'agit d'une version prise en charge à long terme (LTS)
qui apporte des corrections et des améliorations à .NET Core 3.0

Microsoft a annoncé la disponibilité de .NET Core 3.1, deux mois après avoir publié .NET Core 3.0. Microsoft a précisé qu'il s'agit essentiellement d'un petit ensemble de corrections et d’améliorations apporté à .NET Core 3.0.

« La caractéristique la plus importante est que .NET Core 3.1 est une version prise en charge à long terme (LTS) qui sera prise en charge pendant trois ans. Comme par le passé, nous voulions prendre notre temps avant de publier la prochaine version LTS. Les deux mois supplémentaires (après .NET Core 3.0) nous ont permis de sélectionner et de mettre en œuvre le bon ensemble d’améliorations par rapport à une base déjà très stable. .NET Core 3.1 est maintenant prêt à être utilisé partout où votre imagination ou vos besoins professionnels le nécessitent ».

Les modifications apportées à .NET Core 3.1 concernaient principalement Blazor et Windows Desktop, les deux nouveaux et importants ajouts à .NET Core 3.0. Cela inclut la prise en charge de C ++ / CLI, une demande habituelle des développeurs ciblant Windows.

.NET Core 3.1 est pris en charge sur les systèmes d'exploitation suivants:

• Alpine à partir de la version 3.9 ;
• Debian à partir de la version 9 ;
• openSUSE à partir de la version 42.3 ;
• Fedora à partir de la version 26 ;
• Ubuntu à partir de la version 16.04 ;
• RHEL à partir de la version 6 ;
• SLES à partir de la version 12 ;
• macOS à partir de la version 10.13 ;
• Client Windows : 7, 8.1, 10 (à partir de la build 1607) ;
• Windows Server à partir du SP1 2012 R2.

L'éditeur précise que les applications Windows Forms et WPF ne sont fonctionnelles et prises en charge que sous Windows.

Côté support de puce :

• l'architecture x64 est prise en charge sous Windows, macOS et Linux ;
• l'architecture x86 est prise en charge uniquement sous Windows ;
• l'architecture ARM32 est prise en charge sous Windows et Linux ;
• l'architecture ARM64 est prise en charge sous Linux (à partir du kernel 4.14).

Les contrôles Windows Forms suivants ont été supprimés de .NET Core 3.1:

• DataGrid ;
• ToolBar ;
• ContextMenu ;
• Menu ;
• MainMenu ;
• MenuItem.

Ces contrôles ont été remplacés par des contrôles plus puissants dans .NET Framework 2.0 en 2005. Ils n'étaient plus disponibles par défaut dans Visual Studio Designer Toolbox depuis de nombreuses années. Par conséquent, Microsoft nous avons décidé de supprimer ces contrôles et de se concentrer uniquement sur les nouveaux.

Les remplacements suivants sont recommandés:

Ancien contrôle (API)	Remplacement recommandé	Autres API associées supprimées
DataGrid	DataGridView	DataGridCell, DataGridRow, DataGridTableCollection, DataGridColumnCollection, DataGridTableStyle, DataGridColumnStyle, DataGridLineStyle, DataGridParentRowsLabel, DataGridParentRowsLabelStyle, DataGridBoolColumn, DataGridTextBox, GridColumnStylesCollection, GridTableStylesCollection, HitTestType
ToolBar	ToolStrip	ToolBarAppearance
ToolBarButton	ToolStripButton	ToolBarButtonClickEventArgs, ToolBarButtonClickEventHandler, ToolBarButtonStyle, ToolBarTextAlign
ContextMenu	ContextMenuStrip
Menu	ToolStripDropDown, ToolstripDropDownMenu	MenuItemCollection
MainMenu	MenuStrip
MenuItem	ToolstripMenuItem

Microsoft indique que vous verrez des plantages de build si vous utilisez les contrôles qui ont été supprimés dans vos applications. En outre, si vous ouvrez des applications .NET Core 3.0 dans les dernières versions du concepteur de formulaires Windows .NET Core, des erreurs apparaîtront si vous utilisez ces contrôles. Aussi, l'éditeur recommande de mettre à jour vos applications vers .NET Core 3.1 et de passer aux contrôles alternatifs. Le remplacement des contrôles est un processus simple, il s'agit essentiellement de « rechercher et remplacer ».

L'éditeur tient quand même à s'excuser et à s'expliquer :

« Premièrement, nous aurions dû apporter ces modifications avant la publication de .NET Core 3.0, et nous nous en excusons. Nous essayons d'éviter les changements tardifs, et encore plus pour les changements brusques, et cela nous fait mal de le faire.

« Au fur et à mesure que nous progressions dans le projet de conception de Windows Forms, nous nous sommes rendus compte que ces contrôles n'étaient pas alignés sur la création d'applications modernes et ne devraient jamais faire partie du port .NET Core de Windows Forms. Nous avons également constaté qu’ils auraient besoin de plus de temps pour prendre en charge que ce qui était logique.

« Notre objectif est de continuer à améliorer Windows Forms pour une DPI, une accessibilité et une fiabilité élevées. Cette modification tardive était nécessaire pour nous permettre de nous concentrer sur cette tâche ».

C++ / CLI

Microsoft a ajouté la prise en charge de la création de composants C++ / CLI pouvant être utilisés à partir de .NET Core 3.0 dans Visual Studio 2019 16.4. Pour pouvoir utiliser C++ / CLI, vous devez installer le workload « Développement desktop avec C ++ » et le composant « Support C ++ / CLI ».

Ce composant ajoute quelques modèles que vous pouvez utiliser:

• CLR Class Library (.NET Core) ;
• CLR Empty Project (.NET Core).

Si vous ne les trouvez pas, recherchez-les simplement dans la boîte de dialogue Nouveau projet.

C++ / CLI n'est activé que sous Windows. Vous ne pouvez pas utiliser de composants C++ / CLI ciblés pour .NET Framework avec .NET Core ou inversement.

« Nous vous recommandons de passer à .NET Core 3.1 dès que possible. C’est une excellente version (due en grande partie à la version 3.0) qui apporte des améliorations à de nombreux aspects de .NET Core. C'est également une version de support à long terme (LTS) qui sera prise en charge pendant trois ans ».

Microsoft en a profité pour faire une mise à jour du cycle de vie concernant .NET Core:

• .NET Core 3.0 arrivera en fin de vie dans trois mois à compter d’aujourd’hui, le 3 mars 2020.
• .NET Core 2.2 arrivera en fin de vie le 23 décembre.
• .NET Core 2.1 sera pris en charge jusqu'en août 2021 (il s'agit également d'une version LTS).

Source : note de version, annonce Microsoft

[matthius]

J'ai pu rendre libre mon savoir faire RAD et BPM en comprenant que .NET était totalement inutile.

[Dasoft]

@matthius : ta totale ignorance démontre que ton savoir-faire n'est qu'à ses débuts

[matthius]

@matthius : ta totale ignorance démontre que ton savoir-faire n'est qu'à ses débuts

Les seuls outils RAD donc UML qui restent sont en Pascal. .NET a prit un chemin opposé au RAD.

[defZero]

Les seuls outils RAD donc UML qui restent sont en Pascal. .NET a prit un chemin opposé au RAD.

@matthius

Quel est le rapport entre UML, le dev RAD et Pascal ?
Entre RAD et Pascal, je peut supposé qu'il s'agit du lien entre l'IDE Delphi et le processus de dev RAD (le designer qui générait du code & ces binding), mais pour UML, tu m'as perdu .

[denisys]

Microsoft a annoncé la disponibilité de .NET Core 3.1, deux mois après avoir publié .NET Core 3.0.

Plus fort qu’Oracle et sa version trimestrielle du jdk 1.8 !!!

[Stéphane le calme]

Microsoft rappelle que .NET Core 3.0 va arriver en fin de vie le 3 mars 2020
et recommande de passer à .NET Core 3.1 qui est une version prise en charge à long terme (LTS)

En 2016, la première version de .NET Core a vu le jour avec pour but de créer une première version de .NET qui soit à la fois open source et multiplateforme (Windows, macOS et Linux). Microsoft a fait ce choix pour cibler les utilisateurs qui n’utilisent que les technologies open source et pour répondre aux besoins d’exécution des applications .Net sur des serveurs Linux. Dès sa première version, le framework open source est conçu pour que l’ensemble des opérations soient possibles via la ligne de commande. .Net Core 1 introduit la coexistence de multiples versions du framework open source sur le même poste de travail, ce, pour apporter réponse aux problèmes de compatibilité posés par une installation globale de .Net Framework.

.Net Core 2 fait l’objet de publication en juin 2017 avec le support de .Net Standard 2.0 ce qui permet au framework open source de glaner un supplément de près de 20 000 API. Ce tournant est notamment marqué par l’introduction du pack de compatibilité Windows – un paquet NuGet qui inclut plusieurs API réservées à Windows comme System.Drawing, System.DirectoryServices, etc. ASP.NET Core 2.0 a apporté Razor Pages et SignalR, deux frameworks qui manquaient dans .NET Core 1.0. L’Entity Framework a pour sa part ajouté le support du lazy loading.

Il a fallu attendre 2019 pour avoir .Net Core 3.0 en version générale. Cette nouvelle version majeure de la variante open source et multiplateforme de .NET Framework comprend de nombreuses améliorations, notamment l'ajout de Windows Forms et de Windows Presentation Foundation (WPF). Elle introduit aussi de nouvelles API JSON, la prise en charge d’ARM64 et des améliorations de performance générales. Notons également qu'elle embarque C# 8.0 :

• WPF et Windows Forms : Une des principales nouveautés de cette version est la prise en charge des applications desktop. Vous pouvez maintenant créer des applications Windows Forms et WPF avec .NET Core, sous Windows. Précisons que pour les applications de bureau de .NET Framework existantes, Microsoft a également veillé à faciliter leur migration vers .NET Core. Visual Studio 2019 16.3 prend en charge la création d'applications WPF qui ciblent .NET Core. Cela inclut de nouveaux templates, un concepteur XAML (similaire au concepteur XAML existant qui cible .NET Framework) et XAML Hot Reload.
  
• Support de C# 8.0 : Livré avec .NET Core 3.0, C# 8.0 apporte de nombreuses améliorations. Parmi les plus notables, on peut citer les types de référence nullables. Désormais, toute variable d'un type référence est considérée comme un type référence n'acceptant pas la valeur Null. Autrement dit, par défaut, ces types seront non nullables ! Mais vous pouvez faire en sorte que le type de la variable soit nullable en ajoutant "?" au nom de type pour le déclarer comme type de référence nullable. Le but de cette fonctionnalité est d'en finir avec les exceptions de référence null très fréquentes.
  
  C# 8.0 vient également avec les types Index et Range qui offrent une syntaxe concise pour spécifier des sous-plages dans un tableau, Span ou ReadOnlySpan. Un type Index peut être utilisé pour l’indexation. Vous pouvez en créer un à partir d'un int qui permet de compter depuis le début, ou avec un opérateur de préfixe ^ qui permet de compter depuis la fin.
  
  

  Code C# :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  3
  4
  5
   
  Index i1 = 3;  // numéro 3 depuis le début
  Index i2 = ^4; // numéro 4 depuis la fin
  int[] a = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 }; 
  Console.WriteLine($"{a[i1]}, {a[i2]}"); // "3, 6"

  
  Un type Range est quant à lui composé de deux index, un pour le début et un pour la fin, et il peut être écrit avec une expression de plage (C#) x..y.
  
  

  Code C# :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
   
  var slice = a[i1..i2]; // { 3, 4, 5 }

• C# 8.0 inclut bien d'autres fonctionnalités comme les flux asynchrones, les déclarations using, les expressions Switch, les modèles récursifs (les modèles contenant d'autres modèles), l'implémentation par défaut des membres d'une interface, etc.
• Prise en charge JSON intégrée rapide : les utilisateurs de .NET se sont largement appuyés sur Json.NET et d’autres bibliothèques JSON populaires. Mais .NET Core 3.0 inclut une nouvelle famille d’API JSON permettant des scénarios de lecture/écriture (Utf8JsonReader et Utf8JsonWriter), l’accès aléatoire avec un modèle objet document (JsonDocument) et un sérialiseur (JsonSerializer). Les nouvelles API sont conçues pour répondre à de nombreux scénarios identiques, mais avec moins de mémoire et une exécution plus rapide. Microsoft souhaitait en effet créer une nouvelle API JSON qui tirait parti de toutes les nouvelles fonctionnalités de performance de .NET Core et qui offrait des performances appropriées. Mais il n’était pas possible de faire cela dans une base de code existante telle que Json.NET tout en maintenant la compatibilité.

Sur les bases posées avec .Net Core 3, Microsoft entend produire un environnement d’exécution .Net unique et une infrastructure partout. En d’autres termes, Microsoft va vers un seul .Net à l’avenir. Ce dernier pourra être utilisé pour cibler plusieurs (sinon toutes) plateformes : Windows, Linux, MacOS, iOS, Android, tvOS, watchOS et WebAssembly, etc. Ce futur se nomme .Net 5 – la prochaine version de .Net Core 3. La première préversion de .Net 5 sera disponible dans la première moitié devrait être disponible au premier semestre 2020. La version finale est attendue en novembre 2020. Microsoft prévoit ensuite de publier une version majeure de .Net une fois par an, ce, tous les mois de novembre.

.NET Core 3.0 arrivera en fin de vie le 3 mars 2020

Dans un billet de blog, Microsoft a annoncé que .NET Core 3.0 arrivera en fin de vie le 3 mars 2020 et recommande de passer à .NET Core 3.1. Cette dernière, qui est une version prise en charge à long terme (LTS), a été publiée en décembre 2019.

« La caractéristique la plus importante est que .NET Core 3.1 est une version prise en charge à long terme (LTS) qui sera prise en charge pendant trois ans. Comme par le passé, nous voulions prendre notre temps avant de publier la prochaine version LTS. Les deux mois supplémentaires (après .NET Core 3.0) nous ont permis de sélectionner et de mettre en œuvre le bon ensemble d’améliorations par rapport à une base déjà très stable. .NET Core 3.1 est maintenant prêt à être utilisé partout où votre imagination ou vos besoins professionnels le nécessitent ».

Les modifications apportées à .NET Core 3.1 concernaient principalement Blazor et Windows Desktop, les deux nouveaux et importants ajouts à .NET Core 3.0. Cela inclut la prise en charge de C ++ / CLI, une demande habituelle des développeurs ciblant Windows.

.NET Core 3.1 est pris en charge sur les systèmes d'exploitation suivants:

• Alpine à partir de la version 3.9 ;
• Debian à partir de la version 9 ;
• openSUSE à partir de la version 42.3 ;
• Fedora à partir de la version 26 ;
• Ubuntu à partir de la version 16.04 ;
• RHEL à partir de la version 6 ;
• SLES à partir de la version 12 ;
• macOS à partir de la version 10.13 ;
• Client Windows : 7, 8.1, 10 (à partir de la build 1607) ;
• Windows Server à partir du SP1 2012 R2.

L'éditeur précise que les applications Windows Forms et WPF ne sont fonctionnelles et prises en charge que sous Windows.

Côté support de puce :

• l'architecture x64 est prise en charge sous Windows, macOS et Linux ;
• l'architecture x86 est prise en charge uniquement sous Windows ;
• l'architecture ARM32 est prise en charge sous Windows et Linux ;
• l'architecture ARM64 est prise en charge sous Linux (à partir du kernel 4.14).

Les contrôles Windows Forms suivants ont été supprimés de .NET Core 3.1:

• DataGrid ;
• ToolBar ;
• ContextMenu ;
• Menu ;
• MainMenu ;
• MenuItem.

Ces contrôles ont été remplacés par des contrôles plus puissants dans .NET Framework 2.0 en 2005. Ils n'étaient plus disponibles par défaut dans Visual Studio Designer Toolbox depuis de nombreuses années. Par conséquent, Microsoft nous avons décidé de supprimer ces contrôles et de se concentrer uniquement sur les nouveaux.

Les remplacements suivants sont recommandés:

Ancien contrôle (API)	Remplacement recommandé	Autres API associées supprimées
DataGrid	DataGridView	DataGridCell, DataGridRow, DataGridTableCollection, DataGridColumnCollection, DataGridTableStyle, DataGridColumnStyle, DataGridLineStyle, DataGridParentRowsLabel, DataGridParentRowsLabelStyle, DataGridBoolColumn, DataGridTextBox, GridColumnStylesCollection, GridTableStylesCollection, HitTestType
ToolBar	ToolStrip	ToolBarAppearance
ToolBarButton	ToolStripButton	ToolBarButtonClickEventArgs, ToolBarButtonClickEventHandler, ToolBarButtonStyle, ToolBarTextAlign
ContextMenu	ContextMenuStrip
Menu	ToolStripDropDown, ToolstripDropDownMenu	MenuItemCollection
MainMenu	MenuStrip
MenuItem	ToolstripMenuItem

Microsoft avait déjà communiqué la feuille de route suivante concernant .NET Core:

• .NET Core 3.0 arrivera en fin de vie le 3 mars 2020.
• .NET Core 2.2 arrivera en fin de vie le 23 décembre.
• .NET Core 2.1 sera pris en charge jusqu'en août 2021 (il s'agit également d'une version LTS).

Source : Microsoft