Best Practices für portables C# [geschlossen]

Question

Ich möchte C#-Code für Linux/Windows/Mac/jede andere Plattform schreiben und suche nach Best Practices für portablen Code.

Projekt Mono hat einige tolle Portierung Ressourcen.

Was sind die Best Practices für portables C#?

Answer 1

Ich habe tatsächlich Winforms verwendet und es war in Ordnung.Es war ABER HÄSSLICH, aber es hat funktioniert.

Verwenden Sie natürlich nicht P/Invoke oder andere Win32-Komponenten wie die Registrierung.Achten Sie auch auf DLLs von Drittanbietern.Zum Beispiel verwenden wir eine SQLite-DLL eines Drittanbieters, die tatsächlich nativen Code enthält, den wir austauschen müssen, wenn wir unter OSX/Linux laufen wollen.

Answer 2

Ich hasse den Begriff „Best Practice“, weil es den Anschein hat, dass einige Praktiken in jedem Kontext die besten sein können, was eine riskante Sache ist, aber ich werde sagen, was ich als „Good Practice“ für Multiplattform-Code (und für die meisten) betrachte andere Art der Entwicklung):

Verwenden Sie eine kontinuierliche Integrations-Engine und Erstellen Sie jederzeit für alle Zielplattformen.

Klingt zu komplex?Nun, wenn Sie wirklich mehrere Plattformen unterstützen müssen, ist es besser, dies zu tun.Egal wie sorgfältig Sie mit Ihrem Code und der Bibliotheksnutzung umgehen: Wenn Sie zu spät testen, werden Sie lange Stunden damit verbringen, große Teile der App zu überarbeiten.

Answer 3

Achten Sie auf alles, was mit Dateinamen- und Pfadmanipulation zu tun hat, und nutzen Sie die portablen .NET-Methoden in System.IO.Path dh.

anstatt:

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

Tun:

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

Wenn Sie ein Pfadtrennzeichen angeben müssen, verwenden Sie Pfad.Trennzeichen usw

Answer 4

Verwenden Sie nicht „ “ für eine neue Zeile.Verwenden Umgebung.NewLine

Erinnern :

• *NIX verwendet nur das Newline-Zeichen („ “)
• Windows verwendet „ “
• MacIntosh verwendet „ “ (ich bin mir da nicht ganz sicher – Sie können mich gerne korrigieren).

L.E.:Es scheint, dass einige neuere MacOS das Zeilentrennzeichen „ “ nicht mehr verwenden.

Answer 5

Verwenden Sie Windows.Forms nicht für GUIs, aber Mono hat das wahrscheinlich bereits erwähnt.Gtk# ist für plattformübergreifende GUIs viel konsistenter und zuverlässiger.

Answer 6

Vor ein paar Jahren hätte ich Ihnen geraten, sich ein Exemplar von mir zu kaufen Buch auf plattformübergreifendem .NET, aber da das Buch mittlerweile etwas veraltet ist, müssen Sie sich wirklich an die Informationen der Mono-Site halten.

Der Monomigrationsanalysator (MoMA) Das Tool eignet sich ziemlich gut zum Analysieren einer vorhandenen .NET-Anwendung und zum Warnen vor Portabilitätsproblemen. Bei neuem Code ist es jedoch am besten, die neueste stabile Version von Mono für Ihre Entwicklungsarbeit zu verwenden.

Wie Orion sagte, müssen Sie vorsichtig sein, wenn Sie DLLs von Drittanbietern verwenden, obwohl mein Co-Autor eine geschrieben hat NativeProbe Tool zum Analysieren von DLLs auf P/Invoke-Abhängigkeiten, wenn Sie schnell Software von Drittanbietern überprüfen möchten.

Wenn Sie entschlossen sind, auf MS .NET zu entwickeln, sollten Sie sicherstellen, dass Sie auch auf Mono erstellen und Komponententests durchführen, und Sie sollten auch auf eine Reihe von Windows-spezifischen Namespaces achten, wie z. B. die Namespaces Microsoft.Win32 und System.Management.

Answer 7

Wenn Sie möchten, dass der Code portierbar ist, müssen Sie die Liste der abgeschlossenen Funktionen auf der Mono-Site genau prüfen.Sie gehen detailliert auf jede Klasse im Framework und den Grad der Vollständigkeit ein.Sie müssen diese Dinge während des Designprozesses berücksichtigen, damit Sie nicht zu weit gehen und feststellen, dass eine wichtige Funktion noch nicht implementiert wurde.

Answer 8

Es gibt noch einige andere einfache Dinge.Gehen Sie zum Beispiel nicht von Pfadzeichen aus.Oder Zeilenumbrüche.

Ich gehöre zu den Leuten, die NUnit regelmäßig auf Mono unter Linux oder OSX kompilieren.

Gehen Sie auch nicht davon aus, dass die Compiler genau gleich funktionieren.Wir haben kürzlich ein Problem festgestellt, bei dem der MS C#-Compiler scheinbar Dinge einschließt, die der Mono-Compiler nicht enthält, sodass zusätzliche Referenzen in unserem Build-Skript erforderlich sind.

Ansonsten war es ziemlich einfach.Ich erinnere mich an das erste Mal, als wir dort waren die GUI läuft unter Mono/Linux - Es war ziemlich aufregend (auch wenn es War ziemlich hässlich)

Answer 9

Ein fehlender Artikel:Stellen Sie sicher, dass bei Dateinamen die Groß-/Kleinschreibung beachtet wird.File.Open ("MyFile.txt");funktioniert unter Unix nicht, wenn Ihre Datei den Namen myfile.txt trägt.