practices - Mejores prácticas para C#portátil

remarks c#

Question

Estoy buscando escribir algún código C # para Linux / Windows / Mac / cualquier otra plataforma, y ​​estoy buscando las mejores prácticas para el código portátil.

Project mono tiene algunos excelentes recursos de portabilidad .

¿Cuáles son las mejores prácticas para C # portátil?

Answer 1

De hecho, he usado winforms y estuvo bien. Fue MUY feo, pero funcionó.

Obviamente, no use P / Invoke, o cualquier cosa win32 como el registro. También tenga en cuenta las DLL de terceros. Por ejemplo, usamos un dll de SQLite de terceros que en realidad contiene código nativo, que debemos intercambiar si queremos ejecutarlo en OSX / linux.

Answer 2

Hace algunos años, te habría aconsejado que te compraras una copia de mi libro en .NET multiplataforma, pero como el libro está algo desactualizado ahora, realmente debes apegarte a la información del sitio Mono.

La herramienta Mono Migration Analyzer (MoMA) es bastante buena para analizar una aplicación .NET existente y advertirle sobre problemas de portabilidad, pero la mejor apuesta para el nuevo código es usar la última versión estable de Mono para su trabajo de desarrollo.

Como dijo Orion, debes tener cuidado al usar archivos DLL de terceros, aunque mi coautor escribió una herramienta NativeProbe para analizar archivos DLL para las dependencias de P / Invoke si quieres comprobar rápidamente el software de terceros.

Si está decidido a desarrollar en MS .NET, debe intentar asegurarse de que también compile y pruebe la unidad en Mono, y también debe tener cuidado con una cantidad de espacios de nombres específicos de Windows, como los espacios de nombres Microsoft.Win32 y System.Management.

Answer 3

Hay algunas otras cosas simples. Como no asumir los caracteres de ruta. O nuevas líneas .

Soy una de las personas que regularmente compila NUnit en Mono en Linux o OSX.

Además, no suponga que los compiladores funcionan exactamente igual. Recientemente encontramos un problema donde el compilador de MS C # parece incluir cosas que el Mono no contiene, lo que requiere referencias adicionales en nuestro script de compilación.

Aparte de eso, ha sido bastante sencillo. Recuerdo la primera vez que ejecutamos la GUI en Mono / Linux , fue muy emocionante (incluso si era bastante fea)

Answer 4

No use Windows.Forms para GUI, pero Mono ya lo mencionó. Gtk # es mucho más consistente y confiable para GUI multiplataforma.

Answer 5

Si desea que el código sea portátil, debe revisar de cerca la lista de funciones completadas en el sitio Mono. Se detallan en cada clase en el marco y el nivel de integridad. Tendrá que tener en cuenta estas cosas durante el proceso de diseño, para que no vaya demasiado lejos y descubra que todavía no se ha implementado una característica crítica.

Answer 6

Tenga cuidado con cualquier cosa que tenga que ver con el nombre de archivo y la manipulación de rutas y haga uso de los métodos .NET portátiles en System.IO.Path, es decir.

en lugar de:

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

hacer:

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

Si necesita especificar un separador de ruta, entonces usaría Path.Separator, etc.

Answer 7

Un elemento faltante: asegúrese de que los nombres de los archivos distinguen entre mayúsculas y minúsculas. File.Open ("MiArchivo.txt"); no va a funcionar en Unix si su archivo se llama myfile.txt.

Answer 8

No use "/ r / n" para una nueva línea. Use Environment.NewLine

Recuerda :

• * NIX usa solo el carácter de nueva línea ("/ n")
• Windows usa "/ r / n"
• MacIntosh usa "/ r" (no estoy seguro de esto, no dude en corregirme).

LE: Parece que algunas MacOSes más nuevas ya no usan el separador de líneas "/ r".

Answer 9

Odio el término "Mejor práctica" porque parece que algunas prácticas pueden ser las mejores en cualquier contexto, lo cual es algo arriesgado, pero diré lo que considero una "Buena práctica" para el código multiplataforma (y para la mayoría de otro tipo de desarrollo):

Utilice un motor de integración continua y compilación para todas las plataformas de destino todo el tiempo .

Suena demasiado complejo? Bueno, si realmente necesita soportar múltiples plataformas, mejor hacerlo. No importa qué tan cuidadoso sea con su código y el uso de la biblioteca, si prueba demasiado tarde, se encontrará pasando muchísimas horas reelaborando grandes porciones de la aplicación.