Esto puede ser una pregunta tonta ... pero yo solo estaba buscando en el proyecto Mono y tienen una sección sobre la instalación de Mono on Windows. Pero, dado que Windows obviamente ya tiene el tiempo de ejecución de .NET, ¿alguien puede decirme cuál es exactamente el punto de tener Mono para Windows? ¿Ayuda con el desarrollo de plataformas cruzadas o algo así?¿Cuál es el punto de Mono en Windows
Porque Mono no implementa .Net 100% lo mismo que MS .Net Framework, es bueno que pueda probar en Mono sin tener que ejecutar en Linux. También Mono tiene enlaces para crear formularios con GTK que MS no admite.
Está principalmente allí como una ayuda para desarrollar aplicaciones de Mono para las bibliotecas específicas de Mono. También para ayudar a promover la causa, para que los desarrolladores puedan trabajar en su entorno natural cuando se desarrollan para Mono.
¿Qué es un "entorno natural"? Windows podría ser * su * entorno natural. Tengo varios entornos, todos muy artificiales, pero bien para mí. :) –
Si desea desarrollar una aplicación multiplataforma en C#, entonces el uso de la implementación de Microsoft no es lo más inteligente, ya que no existe una alternativa totalmente compatible para otras plataformas.
Por lo tanto, si usa Mono en Windows para desarrollar aplicaciones, se asegurará de que tendrá pocos problemas para transferirlo a otro sistema operativo (siempre que evite otros pozos como P/Invoke).
Mono does some things the .Net doesn't. Por ejemplo, mono apoya la vinculación estática por lo que se puede construir, compilar y distribuir su aplicación sin necesidad de un instalador en tiempo de ejecución separada. Si creaste una aplicación para que se basara en el modo mono para que sea multiplataforma, existen algunas diferencias, por lo que usar mono en Windows es una mayor garantía de compatibilidad.
.Net does some things that mono doesn't. Hay algunos lugares en el BCL que aún no se han portado para mono. Si desea una aplicación que también funcione en mac/linux, probablemente desee desarrollar primero en mono, incluso si está trabajando en Windows.
La vinculación estática es una de las cosas más importantes que escuché en Mono para Windows. –
Es extraño que nadie haya mencionado que el mono sea de código abierto (lo es, ¿verdad?). Estoy seguro de que es importante para algunos. – Rolf
Aunque no es de gran interés, hay algunos casos en los que tiene mono mejoras sobre el tiempo de ejecución estándar de Microsoft. Migel dio una charla sobre algunos de éstos en el PDC este año:
ver a estos mensajes:
Algunas personas han utilizado porque no están autorizados a instalar .Net Framework en sus PC con Windows, debido a la cantidad de registros y archivos del sistema que lo eliminan. (En ambientes estrictamente controlados)
Mono, por otro lado, está autocontenido en Archivos de programa, y solo escribe una clave de registro con una ruta de acceso (que no es necesario ejecutar).
Creo que esto es un poco tonto, pero es algo que muchos usuarios nos han contado.
Hay algunas características que Mono tiene que .NET no.
Mono es altamente modular. Puede dividirlo en pequeñas piezas y desplegar solo exactamente esas partes que necesita. ¿No quieres System.Xml?Bien, se fue.
Mono es incrustable. Puede alojarlo dentro de su aplicación C/C++, para permitir que los usuarios lo guionen desde un entorno de entorno seguro administrado. El ejemplo más famoso de esto es mod_mono, que aloja Mono dentro del servidor web Apache, y es cómo ASP.NET se implementa en Mono, por ejemplo. Esta característica va muy bien junto con la modularización mencionada anteriormente.
Esto ya se ha mencionado: enlace estático. También va muy bien junto con la modularización.
El compilador como servicio es otro. Anders Hejlsberg ha estado hablando de ello por un tiempo largo, y tal vez, tal vez esté listo para C# 5.0. Bueno, Mono ya lo tiene, y de hecho lo tuvo durante años.
Miguel de Icaza, Desarrollador principal de Mono también tiene una iniciativa que él llama "Embrace and Extend.NET", que extiende la CLI de formas que (actualmente) no son posibles con otras implementaciones CLI (incluyendo .NET). Hasta ahora, Embrace and Extend.NET tiene tres características.
Mono.Simd, que proporciona un acceso seguro y controlado a las instrucciones SIMD de la CPU subyacente (por ejemplo, SSE en Intel o AltiVec en PowerPC). Utilizado para juegos y gráficos.
64 bits índices de matriz, que están permitidos por la especificación ECMA, pero Mono es la única máquina virtual que realmente los proporciona. Utilizado en supercomputación.
Y más recientemente, continuaciones. Esta es realmente la primera vez que Mono se desvía del dominio de la especificación: los índices de matriz larga son perfectamente válidos según la especificación, y Mono.Simd también funciona en cada implementación CLI (aunque muy SLOW), pero Mono.Tasklet necesita soporte especial de la VM que no es parte de CLI o .NET. Esto se usa para la lógica del juego y p. en Second Life.
Creo que la razón principal por la que hicieron esto es para que puedan ejecutar aplicaciones .NET en Mono y .NET en paralelo para compararlas. Además, hay algunas aplicaciones que dependen de las bibliotecas Mono.
De Mono de technical FAQ:
por qué el apoyo de Windows, cuando se puede ejecutar la cosa real?
Hay varias razones:
apoyo Windows nos ayuda a identificar las partes portátiles de Mono de las versiones no portátiles de la misma, ayudando Mono volvemos más portátil en el futuro.
Nos ayuda dado que podemos aislar problemas en Mono por particionando el problema (¿es un problema de tiempo de ejecución , o un problema de sistema operativo?).
Aproximadamente la mitad de los contribuidores a Mono son desarrolladores de Windows. Tienen muchas razones diferentes para contribuir al esfuerzo, y nos resulta muy importante dejar esos desarrolladores corren el tiempo de ejecución en Windows sin forzarlos a utilizar un nuevo sistema operativo .
Mono no modifica en gran medida el registro de Windows, actualiza las DLL del sistema, instala DLL en la ruta de Windows/System32 .
Ayuda a los desarrolladores basados en Windows a probar su código en Mono antes de que se implementen en Linux.
Mono y aplicaciones que incorporan Mono se pueden implementar sin un instalador (se puede "xcopy" implementar la aplicación y las requeridas Mono archivos sin necesidad de instalar el tiempo de ejecución .NET ).
también aunque haya programas enlazados dinámicamente con mono, puede tener ese .exe compilado y tiempo de ejecución Mono pendrive y Goto otro equipo sin .NET/Mono instalado, y ejecutar ese programa en la nueva PC sin cualquier instalación en tiempo de ejecución. es decir, conduce a aplicaciones portátiles (particularmente útiles como aplicaciones portátiles de pen drive) Esto no es posible con .NET. Debe tener .NET runtime instalado en un instalador particular, es decir, el tiempo de ejecución que contiene la carpeta copiar y pegar no es posible.
Para agregar a las numerosas razones mencionadas en otras respuestas, es posible que se requiera instalar Mono para Windows en Wine para permitir la ejecución de aplicaciones .Net dentro de Wine.
espero que Miguel llegue al punto de abrazar y extender; pero hasta ahora solo está siguiendo el ejemplo de MS. duele ver a un gran desarrollador subyugado de esa manera – Javier
¿Quién dice que está de nuestro lado? * tos * – cgp
Si bien MS.Net no viene con soporte para Gtk #, el proyecto Mono publica un instalador para Windows que permite que las aplicaciones Gtk # se ejecuten en MS.Net sin Mono. – jpobst