Le framework 8.0 utilisé par Mercator Core n'est pas un successeur du framework .net 4 mais bien de .net Core 3.0. Par ailleurs, des pans entiers de ce framework ont été réécrits afin d'améliorer les performances et la stabilité. En conséquence, il est possible que les programmations sur mesure dans et autour de Mercator doivent être adaptées lors de la migration .net Core.
En général, ces modifications sont mineures et permettent une compatibilité ascendante avec le framerwork 4.8.
Cette page n'a aucune prétention d'exhaustivité. Le cas échéant, il faut se reporter à la documentation fournie par Microsoft.
Process.Start : UseShellExecute = true n'est plus la valeur par défaut
Le code a été adapté. Pas d'impact causé par Mercator. Si du code personnalisé utilise Process.Start, il faut probablement fixer UseShellExecute à true.
Utilisez la méthode Api.Api.ProcessStartWithShellExecute à la place de Process.Start ou ajoutez ceci lors de l'initialisation du ProcessStartInfo :
ProcessStartInfo si = new ProcessStartInfo(fileName, arguments) { UseShellExecute = true };
Encoding 1252 n'existe pas par défaut en .net Core
Dans MercatorApi.Api : les méthodes Chr, Asc, xSha1, xSha256 et Md5 ont été adaptées.
Installez le nuget : System.Text.Encoding.CodePages
Placez cette ligne de code dans l'initialisation de votre exécutable (pas nécessaire pour une simple librairie)
Encoding.RegisterProvider(CodePagesEncodingProvider.Instance);
Remplacer ContextMenu par ContextMenuStrip
ContextMenu n'est pas repris dans le nouvel environnement. Il faut utiliser à la place ContextMenuStrip qui propose les mêmes fonctionnalités.
Si du code sur mesure adresse directement Form.ContextMenu ou Control.ContextMenu pour, par exemple, désactiver un point de menu, il faut tenir compte du fait qu'à présent ces propriétés sont null. Mercator instancie dès à présent Form.ContextMenuStrip et Control.ContextMenuStrip. Les éléments dans ces menus contextuels ne sont plus des MenuItem mais des ToolStripMenuItem. Sur un tel menu contextuel, l'événement Popup doit être remplacé par Opened. Un séparateur de menu n'est plus créé via new MenuItem("-") mais via new ToolStripSeparator().
Remplacer System.Device.Location.GeoCoordinate par _BaseClasses.GeoCoordinate
Ce code se trouve au niveau des cartes géographiques que Mercator peut afficher et plus précisément en ce qui concerne les markers. Si l'ancienne classe est utilisée, il suffit de la remplacer par la nouvelle.
Remplacer System.Windows.Forms.DataVisualization.Charting par MercatorDataVisualization.Charting
System.Windows.Forms.DataVisualization.Charting qui permet de réaliser facilement des graphiques n'a pas été porté vers .net Core. (Ce projet est abandonné par Microsoft). Ces fonctionnalités ont été ré-incluses dans MercatorTunnel.dll. Elles sont disponibles dans MercatorDataVisualization.Charting. Elles sont disponibles en .net 4.8 et .net Core. Il est donc recommandé d'utiliser à présent cet espace de nom tant en .net 4.8 et qu'en .net Core. Dans la plupart des cas, cela consiste à modifier uniquement une clause using.
Nugets à référencer
Si votre code utilise System.Data.SqlClient (par exemple, Api.Zselect, Api.SqlExec, ...), votre projet doit référencer le nuget System.Data.SqlClient 4.8.6.
Si votre code utilise des fonctionnalités Json de Newtonsoft (ou de MercatorTunnel), votre projet doit référencer le nuget Newtonsoft.Json 13.0.1.
Il est important d'utiliser les mêmes versions que celles de Mercator.
Clients web http
System.Net.HttpWebRequest et System.Net .WebClient sont dépréciés dans le framework .net Core. Il faut à présent utiliser System.Net.Http.HttpClient.
Dans MercatorTunnel, il existe une implémentation de cette dernière classe : MercatorHttpClient.HttpClient qui offre l'avantage de présenter les mêmes implémentations de GetData et PostData qui étaient précédemment disponibles via extension sur System.Net.HttpWebRequest. Cela permet d'utiliser les nouveaux outils avec un minimum de modification de code :
#if (MERCATOR_CORE)
MercatorHttpClient.HttpClient client = MercatorHttpClient.HttpClient.Create(url);
#else
System.Net.HttpWebRequest client = (System.Net.HttpWebRequest)System.Net.WebRequest.Create(url);
#endif
client.Timeout = 2500;
StringContainer stringContainer = client.GetData<StringContainer>(out error);
Chargement des assemblies
Pour le chargement des assemblies, .net Core est beaucoup plus capricieux que .net 4. Dans bien des situations, la simple présence d'une dll dans le répertoire principal de l'application n'est pas suffisant. Si le développement est une application autonome autour de Mercator, les assemblies à charger seront définies dans le fichier monapplication.deps.json. Ce fichier est produit automatiquement et il ne faut en principe jamais le modifier. Il doit être distribué.
Si le développement est une librairie utilisée à l'intérieur de Mercator, il faut absolument cette DLL dans "Gestion > Fichiers SQL > Assemblies" afin que Mercator charge cette assembly lors de son démarrage. Ceci assure aussi la distribution de l'assembly sur tous les postes.
Conflits de version
Hormis quelques exceptions, .net Core peut charger toutes les assemblies produites en .net 4. En revanche, l'inverse n'est pas vrai. Pour sécuriser ce point, cette option doit rester à NON : "Autres / Compilation autorisée depuis Mercator Core" (id = COMPILCORE).
Lors de la distribution automatique des assemblies depuis "Gestion > Fichiers SQL > Assemblies", Mercator applique ces règles supplémentaires :
- un Mercator classique ne reçoit jamais d'assembly compilée pour la version Core
- un Mercator Core choisira toujours la version Core si deux assemblies de même nom existent, l'une compilée en .net 4.8 et l'autre en en .net Core.
Par convention, chez Mercator, le dernier indice de la version vaut
- 40 pour la version classique
- 80 pour la version Core.
Projet multi-plateformes .net 4.8 et .net Core
Voir cette page.