portátil 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.Mejores prácticas para C#
Project mono tiene algunos grandes recursos porting.
¿Cuáles son las mejores prácticas para C# portátil?
De hecho, he usado winforms y estaba 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.
No use Windows.Forms para GUI, pero Mono ya lo mencionó. Gtk # es mucho más consistente y confiable para GUI multiplataforma.
Si desea que el código sea portátil, debe revisar de cerca la lista de características 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.
Odio el término "Mejores prácticas" 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 código multiplataforma (y para la mayoría del 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.
Hace unos años te habría aconsejado que te compraras una copia de mi book en .NET multiplataforma, pero como el libro está un poco desactualizado, ahora realmente debes apegarte a la información del Mono. sitio.
La herramienta Mono Migration Analyzer (MoMA) es bastante buena para analizar una aplicación .NET existente y advirtiendo 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 Orion dijo que debe tener cuidado al usar DLL de terceros, aunque mi coautor escribió una herramienta NativeProbe para analizar las DLL para dependencias de P/Invocar si desea comprobar rápidamente el software de terceros.
Si está decidido a desarrollar en MS .NET, debe intentar y asegurarse de que también compila y prueba la unidad en Mono, y también debe tener en cuenta un número de espacios de nombres específicos de Windows como Microsoft.Win32 y System . Espacios de nombres de administración.
Hay otras cosas simples. Como no asumir los caracteres de ruta. O newlines.
Soy una de las personas que regularmente compila NUnit en Mono en Linux o OSX.
Además, no asuma 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 conseguimos the GUI running on Mono/Linux - fue muy emocionante (aunque era bastante feo)
cuidado con los nada que ver con el nombre de archivo y de manipulación de rutas y hacer uso de los métodos de .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 y luego se usaría path.separator etc
No utilice " \ r \ n "para una nueva línea. Utilice Environment.NewLine
Recuerde:
L.E .: Parece que algunas nuevas MacOSes ya no usan el separador de líneas "\ r".
Macintosh UTILIZADO para usar \ r. En estos días usa \ n, gracias a la base BSD. No estoy seguro exactamente cuando cambió. Sin embargo, todavía podría ser un problema. –
Falta un elemento: 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.
Gendarme y MoMA también pueden ayudar. – user7116