¿Puedo escribir una aplicación multiplataforma (Mac y Windows) usando C #? [cerrado]


8

Veo mucha información antigua sobre esta pregunta, y muchos artículos volando alrededor de Interwebs, pero no puedo decir exactamente dónde están las cosas.

Básicamente, quiero escribir código C # que luego pueda compilar en una aplicación nativa de Windows, y también compilar en una aplicación nativa de Mac (sin Parallels, sin Wine, etc.). Se puede hacer esto?

¿Son productos como Xamarin el camino a seguir? El sitio web de Xamarin dice "Use el mismo lenguaje, API y estructuras de datos para compartir un promedio del 75% del código de la aplicación en todas las plataformas de desarrollo móvil". pero no puedo decir qué podría implicar ese 25% del código de la aplicación que es específico de la plataforma ... Tampoco puedo decir si se dirigen a OSX y Windows, su sitio web está muy centrado en dispositivos móviles.

[añadido más tarde]

Resumen: Xamarin no está diseñado para crear aplicaciones multiplataforma: lo que le brindan es una forma de escribir aplicaciones de Mac en C #, utilizando las operaciones de la GUI de Mac. Lo que recomiendan es escribir todas las plataformas multiplataforma de "lógica de negocios" y luego escribir 2 GUI completamente separadas, una para Windows y otra para Mac.

C # / Qt parece estar en sus primeras fases (aunque si alguien se topa con este artículo en 2016 o más tarde, échale un vistazo).

Parece que mono hará multiplataforma, incluida la GUI, pero solo si usa Windows Forms.


Puede consultar docs.asp.net/en/latest/getting-started/index.html y code.visualstudio.com . Visual Studio y .NET se han hecho de código abierto. Hoep que resuelve tu propósito. Pero sí, si está esperando crear una aplicación GUI, entonces no creo que sea posible.
Krishnandu Sarkar

Tienen Xamarin.Forms ahora en la versión paga. No hace todo, pero hace bastante. Le permite desarrollar una GUI multiplataforma.
MetalMikester

@ KrishnanduSarkar ¿de qué estás hablando? ¿Qué tiene que ver ASP .NET con él? :)
Konrad Morawski

@ KrishnanduSarkar plus es la primera vez que escucho acerca de Open Studio de Visual Studio. ¿Podría proporcionar un enlace a esa información?
Konrad Morawski

@ KonradMorawski No lo es. Pensé en informarle. Es por eso que mencioné que si está esperando crear una aplicación GUI, esto no servirá para su propósito. Bueno, el enlace ya está dado en mi comentario.
Krishnandu Sarkar

Respuestas:


10
  1. Xamarin no "apunta" a Windows, porque no tiene sentido, lo que sea que escriba en C #, está listo para ejecutarse en Windows en sí mismo. Es por eso que solo venden licencias para Xamarin.Android, Xamarin.iOS y Xamarin.Mac. Pero, ¿qué se supone que debe hacer una capa de abstracción de Xamarin.Windows? Ese sería un producto de aceite de serpiente de libro de texto :)

  2. "Aplicación nativa de Windows" : nativo es una palabra difícil cuando se trata de C #. Las aplicaciones de C # generalmente requieren tiempo de ejecución de .NET o Mono, ya sea que se creen con el uso de Xamarin o no. Si desea crear binarios nativos en lugar de IL , existen soluciones como .NET Native o ngen , pero es una cuestión independiente del uso de Xamarin. No creo que quisieras decir "nativo" en este sentido estricto, pero es bueno tener en cuenta esta distinción. Con C #, incluso en Windows, generalmente utiliza una especie de máquina virtual.

  3. Xamarin.Mac requiere tiempo de ejecución Mono.OSX para que el código C # se pueda construir en absoluto. Y une el tiempo de ejecución de Objective-C con Mono.OSX como se describe en Xamarin.Mac Internals :

    Existe el tiempo de ejecución basado en Objective-C que contiene instancias de clases nativas (NSString, NSApplication, etc.) y existe el tiempo de ejecución C # que contiene instancias de clases administradas (System.String, HttpClient, etc.). Entre estos dos trabajos, Xamarin.Mac crea un puente bidireccional para que pueda llamar a métodos (selectores) en Objective-C (como NSApplication.Init) y Objective-C puede devolverle la llamada (como los métodos en el delegado de su aplicación)

    Entonces, sí, la aplicación resultante es "nativa" en el sentido de que no es, digamos, una pieza de HTML envuelta en algún componente de WebView. Tiene acceso a elementos nativos de interfaz de usuario y API. No es nativo en el sentido de que requiere la instalación de Mono.OSX. En otras palabras, es tan nativo como C # en Windows bajo circunstancias predeterminadas.

  4. También es posible que desee familiarizarse con http://blog.xamarin.com/introduction-to-xamarin.mac-seminar/ , podría estar fechado (2013), pero creo que las verdades fundamentales son válidas. Eche un vistazo a la diapositiva # 7.

  5. "No puedo decir qué podría implicar ese 25% del código de la aplicación que es específico de la plataforma" - por definición, todo lo que no es independiente de la plataforma, por lo tanto, casi una lógica comercial "pura", y lo que sea que abstraiga de implementaciones concretas (como alguna interfaz "IRepository", etc.). Sin embargo, lo que sea específico de la plataforma: la interfaz de usuario, la persistencia de la base de datos, las bibliotecas de terceros para Windows o Mac, no se pueden compartir. La proporción de 75/25 es una regla general, su kilometraje puede variar mucho dependiendo de la naturaleza de su aplicación.

Tenga en cuenta que solo he tenido alguna experiencia no comercial con Xamarin para plataformas móviles, y no cubría iOS (solo Windows Phone y Android). Si no soy exacto sobre esto, corríjame.


También podría mencionar github.com/mono/xwt , es una capa de abstracción para GTK #, MonoMac, Xamarin.Mac y WPF para GUI.
Residuo
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.