¿C # es realmente un lenguaje multiplataforma?

C # (y la plataforma .net en general) parece que se está convirtiendo en una buena opción para aplicaciones de orientación múltiple:

• Marco oficial de MS .net: desarrollo completo de Windows, asp.net dev, Windows phone Dev, etc.

• mono y todos sus derivados: monotouch, monodroid: el resto del mundo. Estas herramientas son hoy RTM.

• ¿Significa que C # se está convirtiendo en un buen lenguaje para apuntar a las plataformas más populares: escritorio, web y móvil?

• ¿Sigue siendo mejor usar el lenguaje "nativo" de las plataformas de destino (objetivo C, Java, etc.)
• ¿Es solo una pantalla de humo y solo un lenguaje de marketing?

Tenga en cuenta que soy consciente de que no podré copiar / pegar el código entre plataformas. Pero estoy seguro de que las capas inferiores de aplicaciones (modelos, negocios, etc.) pueden reutilizarse, pero sé que tendré que adaptar las capas superiores (Gui, etc.) a la plataforma. Mi objetivo está más centrado en las habilidades requeridas que el intercambio de código técnico.

[edit] Soy un desarrollador ac # en una compañía que usa masivamente c #. Es por eso que hablé de c # en un plan para expandir el rango de plataformas de destino en mi empresa.

Sí, en general, .NET Framework es ideal para aplicaciones que se dirigen a una amplia gama de dispositivos. Pero esto no es exclusivo de .NET; Java hacía eso mucho antes. Lo que hay que tener en cuenta es que no hay una alternativa real a las herramientas nativas para una plataforma en particular.

Las aplicaciones de Mac que cree con .NET nunca se verán como aplicaciones nativas de Mac OS X, y eso es considerado un problema por la gran mayoría de los usuarios de OS X. Es posible que eso no sea importante para usted estratégicamente, dependiendo de si su modelo de negocio valora maximizar la saturación sobre maximizar la satisfacción del usuario, pero ciertamente es algo a tener en cuenta al tomar una decisión.

Los sistemas GUI en Linux y Windows son algo más flexibles en términos de qué aplicaciones parecen "nativas" y encajan bien con la plataforma. Pero culpo principalmente a la falta de pautas claras de interfaz y al hecho de que los desarrolladores de aplicaciones históricamente han estado dispuestos a ignorar los que existen. Muchos usuarios de Mac prefieren la Mac precisamente por su interfaz de usuario consistente.

Teniendo en cuenta que tendrá que adaptar la capa GUI a la plataforma específica (y posiblemente reescribirla en un lenguaje completamente diferente, como Objective-C), lo que le permite aprovechar la plataforma .NET solo para el código de la biblioteca. Y luego no hay una victoria muy clara para C # sobre C ++, en mi opinión.

Para el desarrollo rápido de aplicaciones, existen pocas alternativas que sean mejores que C # y .NET. Y sacar una aplicación rápidamente y tenerla disponible de inmediato en una diversidad de plataformas es sin duda una ventaja comercial. Pero para las verdaderas aplicaciones multiplataforma que tienen como objetivo satisfacer realmente al usuario, no es necesariamente la solución definitiva.

Microsoft .NET es la implementación oficial de CLR, DLR, BCL, CLI y CLS. Otras empresas, grupos, comunidades o grupos de trabajo no están asociados con Microsoft de manera que puedan tener una implementación 1: 1 de la última versión de marco y lenguaje.

Básicamente, debe revisar qué características de lenguaje y marco le gustaría aprovechar en un proyecto concreto y verificar si están presentes en implementaciones no oficiales de .NET.

Si espera una solución de compilación única y distribuir en todas partes, está equivocado: debe hacer un estudio de caso.

Uso C # en juegos que se ejecutan en máquinas XBOX y Windows, lo uso en aplicaciones Compact Framework para soluciones de robótica, uso MonoTouch para desarrollo de iPad, tengo algunas aplicaciones web que se ejecutan en Linux y algunas otras soluciones. Por lo general, hay una manera de hacer lo suyo en una plataforma determinada. La capa central es casi la misma para la mayoría de ellos (es necesario un estudio de caso). El problema, y ​​lo considero como una serie, es el entorno de desarrollo. Estoy acostumbrado a Visual Studio y sus características. Pero MonoDevelop, por ejemplo, me vuelve loco.