2009-11-24 9 views
14

¿Cuáles son las mejores prácticas para escribir código que se puede compilar de forma cruzada en .NET (Windows) y Mono (linux)? Aunque estoy muy familiarizado con .NET, no soy tan experimentado en Mono y todos sus problemas. ¿Alguien ha visto una buena publicación de blog o documento de mejores prácticas sobre esto, que no he podido desenterrar? Me quedaría con las características del nivel C# 3.0.Mejores prácticas para la compilación cruzada .NET/MONO

Lo primero que me preocupa es Interop, ya que necesitaría llamar a algún código nativo. Siguiente sería la mejor manera de manejar espacios de nombres como Mono.XXX. ¿Debo usar un montón de #if? ¿Aislar el código en ensambles por plataforma?

¡Cualquier sugerencia con respecto a la arquitectura y el diseño sería muy apreciada! Si ha tenido alguna experiencia en la compilación cruzada para Linux/Mono en Visual Studio (cualquier versión), también estaría interesado en eso.

+0

La compilación cruzada es la frase incorrecta, la compila una vez y luego la usa en ambas plataformas. – trampster

+0

No creo que sea correcto, dado que Mono tiene una cantidad de espacios de nombres Mono. *, Etc. ¿Quizás en un mundo perfecto? –

+0

Bueno, hice una aplicación WinForms sin ningún P/Invoke (suena fácil pero es difícil evitar P/Invoke) y funcionó perfectamente bien en Linux, el mismo.el ensamblado exe VS2010 produjo, e incluso tuvo el uso de nuevas características de .NET 4. –

Respuesta

7

Los mayores problemas se están pegando a las APIs apoyados por el Mono. Usar el soporte Visual Studio Integration en Mono puede ayudar mucho con esto, ya que puede enfocar Mono todo el tiempo, en todas las plataformas.

Para sus preguntas específicas:

1) Interoperabilidad - Tendrá que atenerse a P/Invoke. Intente aislar esto en ensamblajes separados, específicos de la plataforma. Esto lleva a 2:

2) Usando #if - Yo evitaría esto, y prefiero usar un modelo de extensibilidad. Mono es compatible con Managed Extensibility Framework, que proporciona una buena forma de "conectar" el código específico de la plataforma en tiempo de ejecución.

+0

Gracias por el puntero al modelo de extensibilidad. Muestra que es una vista previa, no un producto de envío. ¿Cuáles son las posibilidades de que las implementaciones .net y mono vayan a estar sincronizadas antes de finalizar el producto? El plugin de integración visual studio definitivamente ayudará, gracias. –

+0

MEF es de código abierto, por lo que no me preocuparía demasiado. Va a ser parte de .NET 4, y es bastante estable en este punto. Lo usamos en nuestro producto comercial ya. –

+0

Ese es el mejor consejo que he escuchado hasta ahora para MEF que se usa para plataforma cruzada para Mono. –

2
+0

Gracias. Dado que este sería un código nuevo, no estoy seguro de si utilizaría esta herramienta (a menos que me falta algo). En otras palabras, planeo usar CI para construir tanto Windows como Linux. –

+0

Hay algunas partes de Mono que no están terminadas. Por ejemplo, faltan algunas cosas en criptografía. Esos métodos/clases están marcados con los atributos 'todo'. Moma le señalará las cosas no implementadas. –

2

El proyecto Mono proporciona un documento con portability guidelines. Ese es un buen lugar para comenzar.

+0

Si vale la pena señalar que este documento parece un poco desactualizado en algunos lugares. Eso no significa que no esté lleno de información útil. – Stewart

3

usted debe ser interrested por Prebuild:

Prebuild es una herramienta de pre-construcción basadas en XML multiplataforma que permite a los desarrolladores generar fácilmente archivos de proyecto para las herramientas de desarrollo .NET importante IDE y que incluye: Visual Studio. NET 2002, 2003, 2005, SharpDevelop, MonoDevelop, NAnt y Autotools.

+0

¿Por qué votar abajo? El proyecto Prebuid es muy útil para mantener la misma base de código usando plataformas .NET y Mono. Y es gratis. – Larry

0

Utilizamos MonoDevelop y Visual Studio para el desarrollo, pero la clave es mantener un buen script de compilación NAnt para compilar todo en una sola toma (reglas de Joel Spolsky).

El punto principal de IMO es dejar en claro que el software debe ser multiplataforma, por lo que no se trata de "portar a Linux/mono" sino de desarrollar cada iteración en las plataformas requeridas.

Tuvimos que evitar algunas características al principio (usando Mono/.NET desde hace 5 años para un producto comercial) y seguimos apegados a .NET Remoting, pero eso no es un gran problema en el desarrollo multiplataforma en mi opinión.

Contar con el depurador suave desde casi un año también es una gran cosa.