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 Preview 4 est disponible et s'accompagne d'une MàJ de la compilation hiérarchisée
Ainsi que du contrôle WinForms Chart

Le , par Stéphane le calme

63PARTAGES

9  0 
Microsoft a annoncé la disponibilité de .NET Core 3.0 Preview 4. Il 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.

Le contrôle WinForms Chart est maintenant disponible pour .NET Core

Richard de Microsoft a 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.

Microsoft pense que le meilleur moyen de vous familiariser avec le contrôle des graphiques est de jeter un coup d'œil à son projet ChartSamples. Il contient tous les types de graphiques existants et peut vous guider à chaque étape.


Activation du contrôle Chart dans votre projet .NET

Pour utiliser le contrôle Chart dans votre projet WinForms Core, ajoutez une référence au package System.Windows.Forms.DataVisualization NuGet. Vous pouvez le faire en recherchant System.Windows.Forms.DataVisualization dans le gestionnaire de paquets de NuGet (n’oubliez pas de cocher la case Inclure la version préliminaire) ou en ajoutant les lignes suivantes dans votre fichier .csproj.

Code : Sélectionner tout
1
2
3
<ItemGroup>
    <PackageReference Include="System.Windows.Forms.DataVisualization" Version="1.0.0-prerelease.19212.2"/>
</ItemGroup>
Remarque: le concepteur WinForms est en cours de développement et vous ne pourrez pas configurer le contrôle à partir de ce dernier. Pour l'instant, vous pouvez utiliser une approche code d'abord ou créer et configurer le contrôle dans une application .NET Framework à l'aide du concepteur, puis transférer votre projet vers .NET Core.

WPF

L’équipe WPF a publié davantage de composants pour dotnet / wpf entre les versions Preview 3 et Preview 4.

Les composants suivants sont maintenant disponibles en tant que source:
  • Microsoft.NET.Sdk.WindowsDesktop - il s'agit du SDK MSBuild (comme dans le “SDK style project”) pour les applications desktop Windows.
  • Microsoft.Dotnet.Wpf.ProjectTemplates - ce sont les modèles de projet pour WPF.
  • PresentationBuildTasks - ce sont les tâches utilisées pour compiler Xaml.


Amélioration des API de la version .NET Core

Microsoft a amélioré les API de la version .NET Core dans .NET Core 3.0. Elles renvoient maintenant les informations de version attendues : « Ces modifications, même si elles sont objectivement meilleures, sont techniquement révolutionnaires et peuvent perturber les applications qui reposent sur des API de version pour diverses informations ».

Vous pouvez maintenant accéder aux informations suivantes via les API existantes:

C:\testapps\versioninfo>dotnet run
.NET Core version:
Environment.Version: 3.0.0
RuntimeInformation.FrameworkDescription: .NET Core 3.0.0-preview4.19113.15
CoreFX Build: 3.0.0-preview4.19113.15
CoreFX Hash: add4cacbfb7f7d3f5f07630d10b24e38da4ad027
Le code pour produire cette sortie est le suivant:

Code : Sélectionner tout
1
2
3
4
5
6
7
WriteLine(".NET Core version:");
WriteLine($"Environment.Version: {Environment.Version}");
WriteLine($"RuntimeInformation.FrameworkDescription: {RuntimeInformation.FrameworkDescription}");
WriteLine($"CoreCLR Build: {((AssemblyInformationalVersionAttribute[])typeof(object).Assembly.GetCustomAttributes(typeof(AssemblyInformationalVersionAttribute),false))[0].InformationalVersion.Split('+')[0]}");
WriteLine($"CoreCLR Hash: {((AssemblyInformationalVersionAttribute[])typeof(object).Assembly.GetCustomAttributes(typeof(AssemblyInformationalVersionAttribute), false))[0].InformationalVersion.Split('+')[1]}");
WriteLine($"CoreFX Build: {((AssemblyInformationalVersionAttribute[])typeof(Uri).Assembly.GetCustomAttributes(typeof(AssemblyInformationalVersionAttribute),false))[0].InformationalVersion.Split('+')[0]}");
WriteLine($"CoreFX Hash: {((AssemblyInformationalVersionAttribute[])typeof(Uri).Assembly.GetCustomAttributes(typeof(AssemblyInformationalVersionAttribute), false))[0].InformationalVersion.Split('+')[1]}");
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.

Les images SDK Docker contiennent PowerShell Core

PowerShell Core a été ajouté aux images de conteneur Docker du SDK .NET Core SDK, à la demande de la communauté. PowerShell Core est un outil / framework d'automatisation et de configuration multiplate-forme (Windows, Linux et macOS) qui fonctionne bien avec vos outils existants et qui est optimisé pour traiter les données structurées (JSON, CSV, XML, etc.) et les API REST. et modèles d'objet. Il comprend un shell de ligne de commande, un langage de script associé et un framework pour le traitement des cmdlets.

Vous pouvez essayer PowerShell Core, en tant qu'élément de l'image du conteneur du Kit de développement .NET Core SDK, en exécutant la commande Docker suivante:

Code : Sélectionner tout
docker run --rm mcr.microsoft.com/dotnet/core/sdk:3.0 pwsh -c Write-Host "Hello Powershell"
L’intégration de PowerShell dans l’image de conteneur .NET Core SDK permet à PowerShell de réaliser deux scénarios principaux, ce qui était impossible autrement:
  • Rédiger des fichiers Docker de l'application .NET Core avec la syntaxe PowerShell pour tout système d'exploitation.
  • Écrire une logique de construction d’application / bibliothèque .NET Core qui puisse être facilement conteneurisée.

Exemple de syntaxe de lancement de PowerShell pour une construction conteneurisée (montée sur volume):
  • docker run -it -v c: \ myrepo: / myrepo -w / myrepo mcr.microsoft.com/dotnet/core/sdk:3.0 pwsh build.ps1
  • docker run -it -v c: \ myrepo: / myrepo -w / myrepo mcr.microsoft.com/dotnet/core/sdk:3.0 ./build.ps1

Source : Microsoft

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

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
Membre émérite 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 Dasoft
Membre habitué 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
2  0 
Avatar de FatAgnus
Membre confirmé 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 confirmé 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 confirmé 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 confirmé 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