¿Hay alguna forma compatible de ejecutar aplicaciones .NET 4.0 de forma nativa en una Mac?

¿Cuáles son las opciones admitidas por Microsoft para ejecutar código C # / .NET 4.0 de forma nativa en Mac? Sí, sé acerca de Mono, pero entre otras cosas, se queda atrás de Microsoft. Y Silverlight solo funciona en un navegador web. Una solución de tipo VMWare tampoco es suficiente.

¿Hay alguna respuesta semi-autorizada de por qué Microsoft simplemente no admite .NET en la Mac misma? Parece que podrían Silverlight y / o comprar Mono y estar rápidamente allí. No hay necesidad de Visual Studio nativo; La compilación cruzada y la depuración remota están bien.

La razón es que donde trabajo hay una creciente incertidumbre sobre el futuro, lo que está causando que se desarrolle mucho más en C ++ en lugar de C #; nuevos proyectos eligen usar C ++. Nadie quiere decirle a la gerencia dentro de 18 a 24 meses "lo siento" si la Mac (o iPad) se convierte en un requisito. C ++ es visto como la opción más segura, incluso si (posiblemente) signifique una pérdida de productividad hoy.

¿Hay alguna respuesta semi-autorizada a por qué Microsoft simplemente no admite .NET en la Mac misma?

Probablemente, la mejor respuesta es que no solo "admite" .NET en la Mac. Gasta cientos de millones de dólares y varios años portando .NET a la Mac.

Si bien algunas cosas están completamente administradas y no requerirían portabilidad, la mayoría son envoltorios alrededor de la API Win32 (ventanas, controles, gdi +, criptografía, directorio activo, COM, servicios empresariales, acceso a dispositivos, sonido, video, códecs, winforms, etc. etc)

Cada uno de estos tendría que resumirse en el backend y reasignarse a bibliotecas nativas equivalentes en OSX. Por supuesto, no habrá un mapeo limpio y agradable, por lo que también debe escribir hacks sobre hacks para que funcione exactamente igual.

Luego está el problema de que estas API en OSX pueden ser frágiles y Apple no es muy bueno en la compatibilidad con versiones anteriores, por lo que puede rehacer sus hacks con cada versión principal (y, a veces, versiones menores y revisiones), acumulando un alto costo de mantenimiento.

Básicamente, es una enorme cantidad de dinero y trabajo para muy poca ganancia en una plataforma cuyo propietario estaría en contra de que lo haga de todos modos. Y realmente no desea gastar dinero para ayudar a las personas a migrar de su propia plataforma a la de su competencia.

Así que te quedan opciones de plataforma cruzada no perfectas:

• C ++, que aún requerirá portabilidad en el futuro
• Silverlight fuera del navegador, para soporte de Microsoft
• Mono, que hace el trabajo para admitir un subconjunto saludable de .NET, pero no es Microsoft

No, Silverlight es la única opción de Microsoft de .Net en OS X. Mono no se "retrasa" tanto como cree; es compatible con .Net 4.0 y C # 4, por ejemplo. Sin embargo, los kits de herramientas de la interfaz de usuario (WinForms y WPF) no son compatibles con OS X. Mono no es compatible con WPF en absoluto. Tampoco podría Microsoft sin reescribir todo el motor de renderizado. Eso probablemente está bien, sin embargo. Si desea escribir una aplicación nativa de Mac, debería estar escribiendo una interfaz de usuario nativa (quizás usando MonoMac).

No. Mono es tu mejor apuesta.

Otros proyectos de código abierto como DotGNU también pueden servirle. http://www.gnu.org/software/dotgnu/ Pero ninguno de estos es compatible con MSFT.

Silverlight no es solo un navegador . Desde la versión 3 OOB ha existido y sería la ruta que tomaría si una plataforma compatible con Microsoft es imprescindible.

Si bien Mono puede retrasarse, no está tan eliminado de la pila de .NET como puede pensar y no debe descartarse como una opción viable.

En cuanto a por qué Microsoft no implementa toda la pila .NET; ROI

La mayor parte de las ganancias de Microsoft proviene de dos productos: Windows y Office. La compatibilidad multiplataforma dañaría a Windows.

Si realmente desea que el mismo código se ejecute multiplataforma, escriba una aplicación web. Sin embargo, no suena como tú. "Por si acaso" no es una buena razón, es un cambio de alcance.

Incluso si decide apuntar a Mac OS X o iOS en 16 meses a partir de ahora, ¿realmente cree que podría tomar su código C ++ existente y convertirlo en una buena aplicación nativa (o incluso funcional)? A menos que estés trabajando en un juego de pantalla completa, la respuesta es no.

Ahorre tiempo con C # ahora, y si decide pasar a la Mac, vuelva a escribirlo de la manera Mac con Objective-C y Cocoa; sus usuarios se lo agradecerán.

¿Hay alguna respuesta semi-autorizada a por qué Microsoft simplemente no admite .NET en la Mac misma?

¿Dónde está el mercado que justificaría que MS gastara el tesoro codificándolo? Para hacer esto, tendrían que gastar mucho dinero en efectivo: millones de dólares en salario. Un proceso continuo, a medida que aparecen correcciones y actualizaciones.

¿Y para qué? ¿Los derechos de fanfarronear? Todo lo que obtienen es la capacidad de las personas de deshacerse de Windows para Apple y aún poder ejecutar sus aplicaciones.

Si alguien se beneficiara de hacer esto, sería Apple. Facilite a las personas la transición a su plataforma y a los desarrolladores (DESARROLLADORES DE DESARROLLADORES) que la codifiquen. ¿Pero crees que a SJ le importa? Prefieren inventar cosas nuevas para pegarse un i enfrente de. Además, la mayor parte del marco es OS y las especificaciones CLR son gratuitas para que cualquiera las implemente. No puedes pegar un NDA sucio en nada de eso.

Puede encontrar útil el proyecto MonoMac: http://www.mono-project.com/MonoMac

Permite el desarrollo de aplicaciones Cocoa estilo Mono, que pueden implementarse en la tienda de aplicaciones Mac.

Consideraría fuertemente este enfoque para un desarrollador que no esté familiarizado con Objective-C pero con .NET / Mono / Java que tiene que entregar una aplicación en un escenario restringido en el tiempo.

Ninguna.

Recomiendo escribir una aplicación C ++ con compilación cruzada, puede que te guste, o usar Ruby con wxWidgets.

Considero que .NET es una mala propuesta para el desarrollo multiplataforma y el mantenimiento de productos a largo plazo. Aunque, hombre, puedes encontrar aplicaciones rápidamente en él. : - /

Wish Delphi seguía siendo un gran contendiente.

Si desea ejecutar .NET de forma nativa en una Mac, puede usar BootCamp para hacerlo (es decir, ejecuta Windows en la Mac y sus aplicaciones .NET en Windows).

Si se refería a Mac OS X en lugar de solo el hardware, puede usar VMWare o Parallels para ejecutar las aplicaciones .NET en Windows (en emulación) en OS X. Ambos tienen modos visuales que permiten que su aplicación aparezca como si solo se estuviera ejecutando dentro de OS X (se verá y se comportará como una aplicación de Windows, pero si está escribiendo una aplicación no web multiplataforma sin una interfaz personalizada para cada sistema operativo, siempre tendrá ese problema).

Obtendrá la misma cantidad de "soporte" al hacerlo, ya que está ejecutando la aplicación en Windows, aunque virtualizada. Por supuesto, cualquier persona que ejecute la aplicación necesitará una copia del software de virtualización y Windows, y estará dispuesto a soportar una aplicación que no se comporte como una aplicación de OS X, pero es la única forma de tener "nativo" .NET ejecutándose en una Mac.

Dan, no creo que puedas hacer esto. Sin embargo, una posible solución (todavía vapourware) es usar Embarcadero Rad Studio C ++ Builder, que tiene un buen VCL para desarrollar aplicaciones visuales (en las que se basa gran parte de .net), y se rumorea que tienen soporte multiplataforma. en el próximo lanzamiento

Esto se desarrollará en Windows, dirigido a Mac o Linux. O eso dice su hoja de ruta.

El entorno de C ++ es razonable y si se desarrolla contra el VCL, entonces, en teoría, la aplicación simplemente funcionará en las otras plataformas.

Por supuesto, hasta que se envíe, queda por ver cuán efectivo es realmente.

La respuesta es no.

En realidad, su caso parece ser un muy buen ejemplo de cuándo no elegir .NET.

Si desea desarrollar para un sistema operativo, utilice las herramientas adecuadas. No hay aplicaciones verdaderamente profesionales escritas en mono para Mac. Por otro lado, hay muchos desarrolladores no profesionales que utilizan muchas herramientas que crean mucha basura. Mire las revisiones de aplicaciones mono que se han escrito para OSX. Los desarrolladores están escribiendo utilizando un marco incompleto pirateado para que coincida con la plataforma OSX. Comience a escribir: si ha utilizado C #, el objetivo C es un aprendizaje rápido.

Los desarrolladores profesionales para Mac usan C ++, Objective C, Cocoa y Xcode. Desarrollo en varias plataformas y cada una tiene sus mejores herramientas. Use Xcode para Mac e iOS.

Como una nota al margen, Xcode no es Visual Studio, no es tan estable y es una desgracia para Apple en comparación, pero funciona bien cuando te acostumbras a él. Es muy difícil vencer a las herramientas de Microsofts, pero fueron escritas para Windows, no para Linux, iOS, OSX, AIX, etc.