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 !

.NET Core 3.0 est disponible avec le support du développement d'applications Windows Desktop
C# 8.0, ARM64, une prise en charge JSON intégrée rapide et de nombreuses autres améliorations

Le , par Michael Guilloux

0PARTAGES

18  0 
Microsoft vient d’annoncer la publication de .NET Core 3.0. Cette tant attendue 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, entre de nombreuses autres nouveautés que nous ne pourrons présenter ici de manière exhaustive.

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.


Une application .NET Core Windows Forms

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. Le concepteur Windows Forms est quant à lui toujours en préversion et disponible en téléchargement séparé, en tant qu'extension Visual Studio. Il sera ajouté à Visual Studio dans une version ultérieure. Il ne prend actuellement en charge que les contrôles et les fonctionnalités de bas niveau les plus couramment utilisés. Microsoft ne recommande donc pas de porter vos applications Windows Forms vers .NET Core, en particulier si vous comptez sur le concepteur. Les développeurs sont plus invités à le tester afin de partager leurs avis... Soulignons que vous pouvez également créer et générer des applications de bureau en utilisant la CLI .NET.


Une application WPF affichée dans le nouveau concepteur

En plus de Windows Forms et WPF, le package System.Windows.Forms.DataVisualization (qui inclut le contrôle permettant de générer des graphiques) est disponible pour .NET Core. Vous pouvez donc maintenant inclure ce contrôle dans vos applications .NET Core WinForms.

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<T> ou ReadOnlySpan<T>. Un type Index peut être utilisé pour l’indexation. Vous pouvez en créer un à partir d'un intqui 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
1
2
3
4
5
  
Index i1 = 3;  // number 3 from beginning 
Index i2 = ^4; // number 4 from end 
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
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é.

Un nouveau SqlClient

SqlClient est le fournisseur de données que vous utilisez pour accéder à Microsoft SQL Server et à Azure SQL Database. Il va maintenant être publié et mis à jour en tant que package NuGet Microsoft.Data.SqlClient, et pris en charge à la fois pour les applications .NET Framework et .NET Core. En utilisant NuGet, il sera plus facile pour l’équipe SQL de fournir des mises à jour aux utilisateurs .NET Framework et .NET Core.

Support ARM et IoT

Microsoft a ajouté la prise en charge de Linux ARM64 dans cette version, après l’ajout de la prise en charge d’ARM32 pour Linux et Windows dans les versions .NET Core 2.1 et 2.2, respectivement. Raspberry Pi et les puces ARM sont désormais prises en charge pour permettre le développement IoT, y compris avec le débogueur Visual Studio distant. Vous pouvez déployer des applications qui écoutent des capteurs et afficher des messages ou des images sur un écran, le tout à l'aide des nouvelles API GPIO. ASP.NET peut être utilisé pour exposer des données en tant qu'API ou en tant que site permettant de configurer un périphérique IoT.

Compilation hiérarchisée

La compilation hiérarchisée est activée par défaut avec .NET Core 3.0. Cette fonctionnalité permet au runtime d’utiliser de manière plus adaptative le compilateur JIT pour obtenir de meilleures performances. Son principal avantage est d’autoriser les méthodes JIT avec un niveau de moins bonne qualité, mais plus rapide, ou avec un niveau de meilleure qualité, mais plus lent. Cela permet d’améliorer les performances d’une application quand elle passe par les différents stades de l’exécution, du démarrage à l’état stable.

Autres améliorations

On peut encore citer parmi les améliorations les plus importantes :
  • le support de HTTP/2 dans HttpClient ;
  • les applications .NET Core ont maintenant des exécutables par défaut : dans les versions précédentes, les applications devaient être lancées via la commande dotnet ;
  • la taille de tas par défaut du récupérateur de mémoire a été réduite, aboutissant à une diminution de la quantité de mémoire utilisée par .NET Core. Le récupérateur de mémoire a également été mis à jour afin de mieux utiliser un grand nombre de cœurs sur des machines de plus de 64 cœurs ;
  • .NET Core fonctionne mieux avec Docker, le ramasse-miettes et le pool de threads ont été mis à jour pour fonctionner beaucoup mieux lorsqu'un conteneur a été configuré pour une mémoire ou un processeur limité. Les images docker .NET Core également sont plus petites, en particulier celles du SDK ;
  • etc.

Il est important de mentionner que Visual Studio 2019 16.3 et Visual Studio pour Mac 8.3 ont également été publiés et que ce sont les versions requises pour utiliser .NET Core 3.0 avec Visual Studio.

Télécharger .NET Core 3.0 pour Windows, macOS ou Linux

Source : Microsoft

Voir aussi :

Bing.com tourne désormais sur .NET Core 2.1, un choix technique qui lui a permis de gagner en performance, mais aussi en agilité
Microsoft annonce la diffusion de mises à jour cumulatives pour .NET Framework à compter de la mise à jour Windows 10 octobre 2018
PowerShell Core 6.1 est disponible : support de .NET Core 2.1, compatibilité avec les modules Windows, cmdlets et rendu Markdown et plus
Visual Studio 2019 version 16.2 Preview 2 est disponible en téléchargement, et apporte des améliorations à la productivité .NET
Avec .NET 5, Microsoft voudrait produire un environnement d'exécution .NET unique et une infrastructure utilisable partout

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

Avatar de Dasoft
Membre actif https://www.developpez.com
Le 04/12/2019 à 10:33
@matthius : ta totale ignorance démontre que ton savoir-faire n'est qu'à ses débuts
3  0 
Avatar de micka132
Expert confirmé https://www.developpez.com
Le 30/09/2019 à 12:27
Citation Envoyé par dfiad77pro Voir le message
je doute que Microsoft investisse dans la création d'un Framework multi-plateforme…
En fait si, il y a Xamarin pour du multi-plateforme utile : le mobile.
Les IHM sur du linux desktop ca touche tellement peu de cas que c'est s'attirer beaucoup d’emmerde pour pas grand chose.
2  0 
Avatar de freesket
Membre du Club https://www.developpez.com
Le 01/10/2019 à 8:03
Xamarin.Forms est multiplateforme : Windows UWP, IOS, Android mais aussi (en preview pour le moment) Linux (GTK), MacOs et Windows desktop (WPF) :
https://docs.microsoft.com/en-us/xam...latform/other/
2  0 
Avatar de sergio_is_back
Expert éminent https://www.developpez.com
Le 17/10/2019 à 16:57
Citation Envoyé par denisys Voir le message
Etant déçus des résultat de .Net Core 3.0 , je préfère continuer a utiliser mono , pour le portage des applications WinForm , sur linux et mac .
https://www.mono-project.com/
Ce serai bien que tu développe un peu, ça pourrai toujours être intéressant de savoir pourquoi...
2  0 
Avatar de FatAgnus
Membre chevronné https://www.developpez.com
Le 26/09/2019 à 21:16
Citation Envoyé par kilroyFR Voir le message
Ca n'aura de réel intérêt que le jour ou ca ne fonctionnera pas QUE sous Windows (WPF/WinForms j'entends). Le reste c'est du détail.
Microsoft ne veut pas pas d'une implémentation multiplate-formes de Windows Forms ou WPF, c'est eux même qui l'écrivent sur la page Contributing Guide : « Nous n'avons pas non plus l'intention d'accepter des contributions qui fournissent des implémentations multiplate-formes pour Windows Forms ou WPF. ».
2  1 
Avatar de redcurve
Inactif https://www.developpez.com
Le 27/09/2019 à 21:01
Citation Envoyé par kilroyFR Voir le message
Ca n'aura de reel interet que le jour ou ca ne fonctionnera pas QUE sous windows (WPF/Winforms j'entends). Le reste c'est du detail.
Déjà winform ne fonctionnera jamais en dehors de Windows, et Wpf non plus. L'un est une flat api par dessus win32 le second utilise massivement directX.

Il a des mots clefs dans ces technologies comme Windows ou Win32... Ce qui laisse peu de doute concernant la portabilité.

Votre commentaire montre que vous ne semblez pas comprendre le fonctionnement des apis que utilisez ce qui est extrêmement inquiétant si vous êtes un professionnel.
2  1 
Avatar de StringBuilder
Expert éminent https://www.developpez.com
Le 01/10/2019 à 21:46
Citation Envoyé par micka132 Voir le message
Les IHM sur du linux desktop ca touche tellement peu de cas que c'est s'attirer beaucoup d’emmerde pour pas grand chose.
Oui et non.

En portant son SGBD SQL Server sous Linux, ainsi que son framework de développement .NET sous Linux, Microsoft s'ouvre clairement la voie vers ce système.
A ça, on combine le sous-système Linux pour Windows, et on en arrive à se demander quand des outils tels que Microsoft Office, qui sont déjà portés sous Mac OS... qui n'est qu'un Linux après-tout, seront enfin portés sous Linux.

Si je ne m'abuse, Visual Studio Code tourne sous Linux... pour quelle sombre raison SQL Server Management Studio, actuellement développé en .NET, ne serait pas porté sous Linux lui aussi ? C'est juste logique d'offrir un environnement complet de développement et d'administration SQL sous Linux.

Bref, si Microsoft ne se lance pas ouvertement dans le développement de logiciels grand public sous Linux, le simple fait d'avoir mis de côté le projet Mono au profit de .NET Core montre que Microsoft se recentre clairement sur Linux, et que l'objectif est bel et bien de ne pas seulement faire tourner ses langages sous Linux, mais bien de s'approprier Linux et devenir une plateforme de choix, y compris pour des projets 100% Linux. A partir de là, que ce soit Windows.Forms, WPF, UWP ou n'importe quoi de nouveau, Microsoft finira bien par se lancer dans les IHM multiplateforme.

Le simple fait que Microsoft développe en masse pour Android (qui, rappelons le, est basé sur Linux) montre bien cette volonté de ne plus devenir un choix des "windowsiens qui essaient de faire marcher leurs trucs ailleurs que sous Windows", mais bien une alternative réelle à Java... qui dispose d'IHM sur toutes les plateformes depuis toujours.
Actuellement, l'absence d'IHM portable est la seule réelle tare que traîne .NET face à Java.
1  0 
Avatar de dfiad77pro
Membre chevronné https://www.developpez.com
Le 02/10/2019 à 4:29
pour les databases Microsoft à un logiciel electron basé sur vscode (mais vraiment différent), ça ne remplace pas le management studio mais c'est un bon début.
https://github.com/microsoft/azuredatastudio
1  0 
Avatar de xarkam
Membre éprouvé https://www.developpez.com
Le 03/10/2019 à 20:32
Citation Envoyé par rt15 Voir le message
Bof. Désolé, je partage pas du tout cette analyse.

Accessoirement il me semble que le Java est complètement has been sur mobile (bouffé par javascript, Dart, Kotlin...) et de toute façon pour les interfaces graphiques, les librairies historiques portables Swing et JavaFX sont pas utilisées sur mobile.
Dart transpilé en java, Kotlin qui n'est qu'une surcouche pour apporter de la modernité à java.
Malgré que java passe pour un hasbeen sur mobile, sauf cordova, (il me semble que le reste transpile en java ou mettent un interpréteur), java sous android reste le best en terme de perf.

Citation Envoyé par rt15 Voir le message

Les applications desktop ça devient de plus en plus has been aussi, tout se fait de plus en plus dans le navigateur.
Par exemple pour Office, plutôt qu'un portage Linux, M$ a fait un portage (partiel) sur le web en proposant "Office Online"/"Office Web Apps"/"Office for the web"/"Office in a browser".
Mais bien sur. Pour des besoins ultra simple c'est ok, sinon office web ca vaut pas la peine. C'est plus un viewer web qu'autre chose.
Un exemple récent (avant hier), j'ai fait une présentation powerpoint via teams et j'ai eu besoin de faire une modification et ensuite grouper les éléments. Ca n'est pas dispo dans la version web.
Je pourrais dresser une liste assez longue de ce qui n'est pas dans les version web.
Quant à electron, prévoyons des machines dans le future avec 128gb ram vu comment sa prend des ressources.

Citation Envoyé par rt15 Voir le message

Le combat Java vs C# (pas seulement niveau appli desktop où ils n'ont jamais vraiment percé) va pas perdurer bien longtemps s'ils se font complètement démonter par pléthore de nouvelles technos (node.js...) et autres langages (Go...) qui sont vachement hypés.
Alors, pour ce qui est de la france, en dehors de php et java, nulle espoir. D'ailleurs en france on forme des dev php à tour de bras.
Dans le reste du monde, les dev c# sont hyper courtisés justement depuis le renouvellement de c#
(ma femme et moi sommes des dev c# et nous pourrions changer de boite tout les mois. Ca en devient lassant ces relances pour bosser chez l'un et l'autre)

Pour moi la guerre java vs c# n'existe plus depuis belle lurette. C# apporte plein de modernité dans le langage que n'a pas java.
Pourtant, java rattrape doucement son retard, mais les applications métiers restent encore sur java 8.

Blazor quant à lui apporte une manière de coder à la react. J'ai vu dernièrement une vidéo montrant du débug de code c# directement dans les devtools de edge chromium. Bluffant.
1  0 
Avatar de rt15
Membre éclairé https://www.developpez.com
Le 04/10/2019 à 15:28
Dart peut être transpilé vers javascript ou être exécuté par sa propre VM. Il n'y a pas de lien technique entre Dart et Java.

Kotlin dépend de la JVM, pas du langage Java. Le lien entre Kotlin et Java est techniquement le même qu'entre C# et VB.NET.

Java reste très utilisé et ne va pas disparaître du jour au lendemain. Mais il me semble sur le début de la pente du déclin. Côté mobile il n'est plus poussé par Google. Côté serveur, les grosses boîtes osent démarrer des nouveaux projets en nodejs. Et la politique d'Oracle vis à vis de Java est désespérante, mais c'est un autre sujet.

Pour le best en terme de perf à l'exécution sous Android il faut certainement oublier Java et se tourner vers le NDK.

Office dans le navigateur, c'est bien de la merde, on est d'accord. Je suis obligé d'utiliser de temps en temps Excel dans le navigateur et c'est très pénible car l'édition est très lente .
Mais c'est pas moi qui le pousse. C'est Microsoft :
Office Online is Now Simply Office
Why you should use Office for the web

Sauf grande surprise, Office (sans Wine) sous Linux, c'est pas pour demain.
De toute façon sous Linux les applis Desktop, c'est un peu la merde à développer. Trop de distributions. Une appli GTK dans un environnement de bureau KDE ou une appli QT dans un environnement GNOME, c'est réputé hideux...
Electron idem, ce n'est pas moi qui ait poussé Microsoft à le choisir pour Visual Studio Code.
Le choix d'architecture est très osé de se basé sur Electron donc Chromium, donc du Google, donc du concurrent.
D'un côté cela montre une ouverture de M$, d'un autre côté, ça leur fait un peu perdre en crédibilité de ne pas faire du Dogfooding.
Mais bon au moins ils ont utilisé leur TypeScript.
C'est comme le choix d'utiliser Chromium dans Edge. Économiquement à court terme, c'est efficace. Stratégiquement, sur le long terme, ça me paraît complètement foireux.

Bref, ils auraient pu faire un portage au moins partiel de XAML/WPF sous Linux (en partant de Mono ?) et faire Visual Studio Code en .NET.
Mais ce n'est pas du tout ce qu'ils ont fait.
Quoiqu'il en soit pas mal de développeurs semblent s'être tourné vers Visual Studio Code, le produit est loin d'être un échec niveau adoption.

Pour ce qui est de Blazor, ce sera plus intéressant quand le code que l'on écrit sera compilé directement vers WebAssembly. Parce que là, du code intermédiaire (.NET) exécuté par une runtime en code intermédiaire (wasm), c'est un peu lourd...

En fait peut être que Blazor sera une solution proposé par M$ pour les applis de bureau portables en .NET.
Ce serait bien plus logique que VSCode soit basé sur C#/Blazor et pas sur TypeScript. Mais bien sûr quand ils ont commencé à développer VSCode, WebAssembly n'était pas vraiment une option...

Certains prédisent que WebAssembly va beaucoup diminuer l'utilisation de javascript dans les SPA. J'imagine que oui et que c'est une bonne chose (meilleure perf à l'exécution, possibilité de choisir le langage de développement de son choix compilant vers wasm), mais pour le moment ça patine... Peut être le temps que les outils type Blazor soient bien au point.

D'autres prédisent que WebAssembly sera utilisé pour faire des applications desktop portable (et donc qu'il va tuer au moins Electron, à part si Electron devient l'hôte standard des applis wasm). Là j'en sais trop rien.
1  0