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> |
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
.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
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]}"); |
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"
- 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