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 confirme que la version générale de .NET Core 3.0 sera disponible durant la .NET Conf 2019
Et en profite pour publier .NET Core 3.0 RC1

Le , par Stéphane le calme

245PARTAGES

13  0 
Microsoft a annoncé la disponibilité de la RC1 de .NET Core 3.0. .NET Core est pour rappel le « reboot » complet de l’environnement .NET. Entièrement open source (licence MIT), il en est une version modulaire distribuée via NuGet.

Dans son billet parlant de .NET Core 3.0 Preview 9, Microsoft avait déclaré que la Preview 9 serait la dernière version avant la disponibilité générale de .NET Core 3.0. « Nous, ou du moins l'auteur infatigable de ces billets de blogs, nous sommes trompés », a noté Richard de Microsoft (qui est celui qui rédige les billets sur les Preview de .NET Core 3.0).

Cette fois-ci, il s'est contenté de dire que la disponibilité générale approche à grands pas puisqu'elle est prévue pour le 23 septembre à l'occasion de la .NET Conf, un événement gratuit de trois jours autour des plateformes .NET (qui va donc s'achever le 25 septembre).

Voici son explication :

« Pour des raisons techniques et historiques, l'ensemble d'outils .NET (compilateurs, client NuGet, MSBuild,…) est dupliqué entre Visual Studio et le Kit de développement logiciel (SDK) .NET. Des modifications importantes ont été apportées à la boîte à outils dans Visual Studio 2019 16.3 Preview 4, également publié aujourd'hui. Il est essentiel que la version du Kit de développement .NET Core SDK faisant partie de toute version de Visual Studio inclue le même jeu d'outils afin de fournir une expérience compatible dans tous les scénarios.

« Nous aurions dû nous rendre compte qu'il était très probable que nous devions publier des modifications pour prendre en charge une autre préversion de Visual Studio. Faire des corrections dans les outils .NET comme ceci est une procédure d’exploitation standard. Nous aurions pu publier un nouveau SDK .NET Core et le livrer uniquement via Visual Studio. Cependant, nous avons déjà déboussolé des personnes dans un passé (maintenant lointain) avec cette approche. Par conséquent, lorsque nous publions un nouveau kit de développement .NET Core SDK, nous le rendons disponible pour tous, partout ».


Prise en charge de Visual Studio

.NET Core 3.0 est pris en charge avec Visual Studio 2019 16.3 Preview 4 et Visual Studio pour Mac 8.3, également disponibles aujourd'hui. Effectuez une mise à niveau pour bénéficier de la meilleure expérience (et prise en charge) avec .NET Core 3.0 Preview RC1.

Le code C# Extension pour Visual Studio est toujours mis à jour pour prendre en charge les nouvelles versions de .NET Core. Assurez-vous d'avoir la dernière version de l'extension C# installée.

.NET Core 3.0

Les évolutions ont été abordées au fil des Preview. Par exemple, .NET Core 3.0 Preview 4 inclut un contrôle de graphique pour Windows Forms, une prise en charge HTTP / 2, des mises à jour du GC permettant d’utiliser moins de mémoire, une prise en charge des limites de CPU avec Docker, l’ajout de PowerShell dans les images de conteneur Docker du SDK .NET Core, et bien d’autres améliorations encore.

Contrôle WinForms Chart

Richard de Microsoft avait avancé que :

« Nous avons entendu dire que certains développeurs n'étaient pas en mesure de migrer leurs applications .NET Framework existantes vers .NET Core, car ils dépendaient du contrôle Chart. Nous avons résolu ce problème pour vous!

« Le package System.Windows.Forms.DataVisualization (qui inclut le contrôle de graphique) est désormais disponible sur NuGet, pour .NET Core. Vous pouvez maintenant inclure ce contrôle dans vos applications .NET Core WinForms! »


Microsoft a porté la bibliothèque System.Windows.Forms.DataVisualization sur .NET Core au cours des derniers sprints. La source du contrôle de graphique est disponible à l'adresse dotnet / winforms-datavisualization, sur GitHub. Le contrôle a été migré pour faciliter le portage vers .NET Core 3, mais Microsoft précise qu'il ne s'agit pas là d'un composant sur lequel l'entreprise a l'intention d'innover. Pour des scénarios de visualisation des données plus avancés, l'éditeur recommande de consulter Power BI.

Mise à jour de la compilation par niveaux (TC - Tiered Compilation)

La compilation hiérarchisée (TC) est une fonctionnalité d'exécution capable de contrôler la vitesse de compilation et la qualité du JIT afin d'obtenir différents résultats en termes de performances. Elle est activée par défaut dans les versions .NET Core 3.0.

L’avantage fondamental de TC est de permettre des méthodes de (ré) jitting avec un code lent mais plus rapide à produire ou de meilleure qualité mais plus lent à produire afin d’améliorer les performances d’une application au cours des différentes étapes d’exécution, du démarrage à son état stationnaire. Cela contraste avec l'approche non-TC, dans laquelle chaque méthode est compilée d'une seule manière (comme pour le niveau de qualité supérieure), qui privilégie l'état stationnaire au démarrage.

« Nous réfléchissons à ce que la configuration par défaut de TC devrait être pour la version 3.0 finale. Nous avons étudié l’impact (positif et / ou négatif) sur les performances de nombreux scénarios d’application, avec pour objectif de sélectionner un paramètre par défaut qui convient à tous les scénarios et de fournir des commutateurs de configuration permettant aux développeurs de sélectionner leurs paramètres de configuration.

« TC reste activé dans la préversion 4, mais nous avons modifié la fonctionnalité activée par défaut. Nous recherchons des commentaires et des données supplémentaires pour nous aider à décider si cette nouvelle configuration est la meilleure ou si nous devons apporter d'autres modifications. Notre objectif est de sélectionner la meilleure valeur globale par défaut, puis de fournir un ou plusieurs commutateurs de configuration afin d'activer d'autres comportements de participation ».

Prise en charge HTTP/2

Microsoft a apporté un support pour HTTP/2 dans HttpClient. Le nouveau protocole est obligatoire pour certaines API, telles que gRPC et le service de notification Apple Push. L'éditeur prévoit que davantage de services nécessiteront HTTP/2 à l'avenir.

ASP.NET prend également en charge HTTP/2, mais il s'agit d'une implémentation indépendante optimisée pour la mise à l'échelle.

Dans la préversion 4, HTTP/2 n'est pas activé par défaut, mais peut être activé avec l'une des méthodes suivantes:
  • Définissez AppContext.SetSwitch ("System.Net.Http.SocketsHttpHandler.Http2Support", true); réglage du contexte de l'application
  • Définissez la variable d'environnement DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP2SUPPORT sur true

Ces configurations (l'une ou l'autre) doivent être définies avant d'utiliser HttpClient si vous avez l'intention d'utiliser HTTP/2.

Remarque: la version de protocole HTTP préférée sera négociée via TLS/ALPN et HTTP/2 ne sera utilisé que si le serveur choisit de l'utiliser.

En somme, voici quelques-unes des principales fonctionnalités de .NET Core 3 :
  • Windows Desktop, WPF et support de winforms dans .NET Core
  • Prise en charge de la dernière version de C# (8.0)
  • Déploiement MSIX et exécutable EXE autonome
  • Prise en charge de .Net Standard 2.1
  • Winforms avec haute DPI
  • Prise en charge JSON intégrée rapide
  • Support HTTP/2
  • Prise en charge des chiffrements cryptographiques AES-GCM et AES-CCM
  • Compilation à plusieurs niveaux
  • Amélioration des performances

Télécharger .NET Core 3.0 RC1 (sur Windows, macOS et 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 confirmé 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
Membre extrêmement actif 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 expérimenté 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