Meilleures pratiques pour le C# portable [fermé]

Question

Je cherche à écrire du code C# pour Linux/windows/mac/toute autre plate-forme et je recherche les meilleures pratiques pour le code portable.

Projet mono a du bon portage ressources.

Quelles sont les meilleures pratiques pour le C# portable ?

Answer 1

J'ai en fait utilisé Winforms et c'était bien.C'était BUTT UGLY, mais ça a marché.

Évidemment, n'utilisez pas P/Invoke, ni aucun élément Win32 comme le registre.Soyez également conscient des DLL tierces.Par exemple, nous utilisons une DLL SQLite tierce qui contient en fait du code natif que nous devons échanger si nous voulons exécuter sur OSX/Linux.

Answer 2

Je déteste le terme « Meilleure pratique » car il semble que certaines pratiques peuvent être les meilleures dans n'importe quel contexte, ce qui est risqué, mais je vais vous dire ce que je considère comme une « Bonne pratique » pour le code multiplateforme (et pour la plupart autre type de développement) :

Utiliser un moteur d'intégration continue et construire pour toutes les plates-formes cibles à tout moment.

Cela semble trop complexe ?Eh bien, si vous avez vraiment besoin de prendre en charge plusieurs plates-formes, mieux vaut le faire.Peu importe à quel point vous faites attention à votre code et à l'utilisation de votre bibliothèque, si vous testez trop tard, vous vous retrouverez à passer de très longues heures à retravailler de grandes parties de l'application.

Answer 3

Méfiez-vous de tout ce qui concerne la manipulation du nom de fichier et du chemin et utilisez les méthodes .NET portables dans Système.IO.Path c'est à dire.

au lieu de:

string myfile = somepath + "\\file.txt";

faire:

string myfile = Path.Combine(somepath, "file.txt");

Si vous devez spécifier un séparateur de chemin, vous utiliserez Chemin.Séparateur etc.

Answer 4

N'utilisez pas " " pour une nouvelle ligne.Utiliser Environnement.NewLine

Souviens-toi :

• *NIX utilise uniquement le caractère de nouvelle ligne (" ")
• Windows utilise " "
• MacIntosh utilise " " (je n'en suis pas vraiment sûr - n'hésitez pas à me corriger).

L.E. :Il semble que certains MacOS plus récents n'utilisent plus le séparateur de ligne " ".

Answer 5

N'utilisez pas Windows.Forms pour les interfaces graphiques, mais Mono l'a probablement déjà mentionné.Gtk# est beaucoup plus cohérent et fiable pour les interfaces graphiques multiplateformes.

Answer 6

Il y a quelques années, je vous aurais conseillé de vous acheter un exemplaire de mon livre sur .NET multiplateforme, mais comme le livre est maintenant quelque peu obsolète, vous devez vraiment vous en tenir aux informations du site Mono.

Le Analyseur de migration mono (MoMA) L'outil est plutôt efficace pour analyser une application .NET existante et vous avertir des problèmes de portabilité, mais le meilleur pari pour le nouveau code est d'utiliser la dernière version stable de Mono pour votre travail de développement.

Comme Orion l'a dit, vous devez être prudent lorsque vous utilisez des DLL tierces, bien que mon co-auteur ait écrit un NativeProbe outil pour analyser les DLL pour les dépendances P/Invoke si vous souhaitez vérifier rapidement les logiciels tiers.

Si vous êtes déterminé à développer sur MS .NET, vous devez essayer de vous assurer également de créer et de tester unitairement sur Mono, et vous devez également faire attention à un certain nombre d'espaces de noms spécifiques à Windows tels que les espaces de noms Microsoft.Win32 et System.Management.

Answer 7

Si vous souhaitez que le code soit portable, vous devez examiner attentivement la liste des fonctionnalités terminées sur le site Mono.Ils détaillent chaque classe du cadre et le niveau d’exhaustivité.Vous devrez prendre ces éléments en considération lors du processus de conception afin de ne pas aller trop loin et découvrir qu'une fonctionnalité critique n'a pas encore été implémentée.

Answer 8

Il y a d'autres choses simples.Comme ne supposez pas de caractères de chemin.Ou nouvelles lignes.

Je fais partie de ceux qui compilent régulièrement NUnit sur Mono sous Linux ou OSX.

Ne présumez pas non plus que les compilateurs fonctionnent exactement de la même manière.Nous avons récemment découvert un problème dans lequel le compilateur MS C# semble inclure des éléments que celui de Mono n'inclut pas, ce qui nécessite des références supplémentaires dans notre script de construction.

A part ça, cela a été assez simple.Je me souviens de la première fois que nous avons eu l'interface graphique fonctionnant sous Mono/Linux - c'était plutôt excitant (même si c'était était assez laid)

Answer 9

Un élément manquant :Assurez-vous que les noms de fichiers sont sensibles à la casse.Fichier.Open ("MonFichier.txt");ne fonctionnera pas sous Unix si votre fichier s'appelle myfile.txt.