Best practice per C # portatile

Sto cercando di scrivere un codice C # per linux / windows / mac / qualsiasi altra piattaforma, e sto cercando le migliori pratiche per il codice portatile.

Project mono ha alcune grandi risorse di porting .

Quali sono le migliori pratiche per C # portatile?

In realtà ho usato winform e andava bene. Era BUTT UGLY, ma ha funzionato.

Ovviamente, non usare P / Invoke, o qualsiasi roba Win32 come il registro. Essere anche a conoscenza di eventuali DLL di terze parti. Ad esempio, utilizziamo una dll di SQLite di terze parti che contiene in realtà un codice nativo in esso che dobbiamo sostituire se vogliamo eseguire su OSX / Linux.

Odio il termine “Best practice” perché sembra che alcune pratiche possano essere le migliori in qualsiasi contesto, che è una cosa rischiosa, ma dirò quella che considero una “Buona pratica” per il codice multi-piattaforma (e per la maggior parte altro tipo di sviluppo):

Utilizzare un motore di integrazione continuo e creare per tutte le piattaforms di destinazione tutto il tempo .

Sembra troppo complesso? Bene, se hai davvero bisogno di supportare più piattaforms, meglio farlo. Indipendentemente dall’attenzione verso il codice e l’utilizzo della libreria, se esegui un test troppo tardi, ti ritroverai a passare ore e ore a rielaborare grandi porzioni dell’app.

Fai attenzione ai nomi dei file e alla manipolazione dei percorsi e utilizza i metodi .NET portatili in System.IO.Path ie.

invece di:

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

fare:

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

Se è necessario specificare un separatore di percorso, utilizzare Path.Separator ecc

Non utilizzare “\ r \ n” per una nuova riga. Usa Environment.NewLine

Ricorda :

  • * NIX usa solo il carattere di nuova riga (“\ n”)
  • Windows utilizza “\ r \ n”
  • MacIntosh usa “\ r” (non sono molto sicuro di questo – sentiti libero di correggermi).

LE: Sembra che alcune nuove MacOS non usino più il separatore di riga “\ r”.

Non usare Windows.Forms per le GUI, ma Mono probabilmente lo ha già detto. Gtk # è molto più coerente e affidabile per le GUI multipiattaforma.

Qualche anno fa ti avrei consigliato di comprarti una copia del mio libro su .NET multipiattaforma, ma dato che il libro è un po ‘antiquato ora hai davvero bisogno di attenersi alle informazioni del sito Mono.

Lo strumento MoMA (Mono Migration Analyzer) è un ottimo strumento per analizzare un’applicazione .NET esistente e avvisarti di problemi di portabilità, ma la soluzione migliore per il nuovo codice è utilizzare l’ultima versione stabile di Mono per il tuo lavoro di sviluppo.

Come ha detto Orion, devi stare attento quando usi DLL di terze parti, sebbene il mio coautore abbia scritto uno strumento NativeProbe per analizzare le DLL per le dipendenze di P / Invoke se vuoi controllare rapidamente il software di terze parti.

Se sei determinato a sviluppare su MS .NET, dovresti assicurarti di creare e testare unitamente su Mono, e dovresti anche stare attento a una serie di spazi dei nomi specifici di Windows come gli spazi dei nomi Microsoft.Win32 e System.Management.

Se si desidera che il codice sia portatile, è necessario rivedere attentamente l’elenco delle funzionalità completate sul sito Mono. Entrano nei dettagli di ogni class nella struttura e nel livello di completezza. Dovrai prendere in considerazione queste cose durante il processo di progettazione in modo da non andare troppo in basso lungo un percorso e scoprire che non è stata ancora implementata una funzionalità critica.

Ci sono alcune altre cose semplici. Come non assumere i caratteri di percorso. O newlines .

Sono una delle persone che compila regolarmente NUnit su Mono su Linux o OSX.

Inoltre, non dare per scontato che i compilatori funzionino esattamente allo stesso modo. Recentemente abbiamo riscontrato un problema in cui il compilatore MS C # sembra includere cose che il Mono non ha, richiedendo riferimenti extra nel nostro script di build.

Oltre a questo, è stato piuttosto semplice. Ricordo la prima volta che la GUI era in esecuzione su Mono / Linux – era piuttosto eccitante (anche se era piuttosto brutta)

Un elemento mancante: assicurarsi che i nomi dei file siano case sensitive. File.Open (“MyFile.txt”); non funzionerà su Unix se il tuo file è denominato myfile.txt.