29 de Marzo de 2005 Traducción al Español Ezequiel Foncubierta Asociación de Gaditanos Linuxeros

efoncu@agali.org

Esta es la traducción de las Faqs oficiales de Mono que se pueden encontrar en http://www.mono-project.com/. La mayoría de los puntos correspondientes a "General-Básicas" y "General-Mono y Novell", estaban traducidos anteriormente de la antigua Faq por: Fabian Seoane (fabian@fseoane.net), Eduardo García (kiwnix@yahoo.es) y Alejandro Sánchez (raciel@x0und.net). El resto lo he traducido a través de la Faq de Mono traducida al Portugués por la gente de http://www.simios.org, debido a mi facilidad con el Portugués. Si encontrais alguna incoherencia, o error gramatical, ruego me lo comuniqueis a mi E-Mail. El proyecto Mono es una iniciativa abierta de desarrollo patrocinada por Novell que está trabajando para desarrollar una versión Open Source en un ambiente UNIX de la plataforma de desarrollo Microsoft .NET. Su objetivo es habilitar a los desarrolladores de UNIX a contruir y distribuir aplicaciones .NET multiplataforma. El proyecto implementará varias tecnologías desenvolvidas por Microsoft, que fueron enviadas al ECM para su estandarización. El proyecto Mono, muestra también interes en el desarrollo de componentes en C#, bibliotecas y frameworks. Hoy en dia, Mono no está limitado a la implementación de un Framework .NET, sino que también tiene otros componente. Alguno de esos componentes son desarrollados por el equipo de Mono, y algunos otros lo hemos incorporado a partir de otros esfuerzos de código abierto. Los más importantes son: Remoting.CORBA: Una implementación de CORBA para Mono Ginzu: Una implementación de ICE implementada encima de Remoting Gtk#: Recubrimento en C# para la librería Gtk+ #ZipLib: Una librería para manipular varios tipos de archivos comprimidos (Zip y Tar). GlGen (disponibles desde el CVS de Mono): Recubrimiento para OpenGL. Mono.LDAP: acceso a LDAP para aplicaciones .NET Mono.Data: proveemos de acceso para bases de datos Postgress, MySql, DB2, SqlLite, Tds, y Oracle. Mono.Cairo: Recubriemientos para el motor de renderizado Cairo (Nuestro System.Drawing está implementado encima de ésto). Mono.Posix: Recubriemiento para escribir aplicaciones POSIX usando C# Mono.Http: Soporte para la creación de servidores http a la medida o empotrados, así como herramientas comunes relacionadas con el protocolo HTTP. La iniciativa .NET es un esfuerzo de la compañía Microsoft que tiene limites poco claros, una parte de ese proyecto, es una arquitectura de desarrollo multiplataforma, Mono es una implementación de este entorno de desarrollo, pero no es una implementación de nada relacionado con la iniciativa .NET, por ejemplo Mono no es una implementación de passport, software como servicio (software-as-service). Mono contiene un numero de componentes útiles para implementar nuevo software: Una maquina virtual de lenguaje común de infraestructura (CLI) que contiene un cargador de clases, un Compilador en tiempo de ejecución (JIT), y unas rutinas de recolección de memoria. Una librería de clases que puede funcionar en cualquier lenguaje que funcione en el CLR (Common Language Runtime). Un compilador para el lenguaje C#. En el futuro, podríamos trabajar en compiladores que generasen CIL (lenguaje intermedio) para el CLR (Entorno de ejecución del lenguaje común). Windows tiene compiladores que compilan para la maquina virtual un número de lenguajes tales como: C++ gestionado (managed), Java Script, Eiffel, Component Pascal,APL, Cobol, Oberon, Perl, Python, Scheme, Smalltalk, Standard ML, Haskell, Mercury y Oberon. El CLR y el Sistema de tipos común (CTS) permiten que la aplicación y las bibliotecas sean escritas en una amplia variedad de lenguajes diferentes que compilen para "bytecode". Esto significa por ejemplo, que si defines una clase que haga una manipulación algebráica en C#, esa clase puede ser reutilizada en cualquier lenguaje que soporte el "CLI". Puede crear una clase en C#, una subclase en C++ y instanciar esa clase en un programa en Eiffel. Un sistema de objetos, sistema de hilos, bibliotecas de clases y sistema recolector de memoria únicos pueden ser compartidos por todos estos lenguajes. C# http://www.ecma-international.org/publications/standards/ECMA-334.HTM CLI http://www.ecma-international.org/publications/standards/ECMA-335.HTM Si, se están implementando las APIs de las bibliotecas de clases de la plataforma .NET. Cada cierto tiempo se hará, pero el objetivo actual es la interoperabilidad con el entorno de desarrollo de Microsoft, pero también se ofrecerá un conjunto de bibliotecas compatibles con ECMA. Mono es la palabra "monkey" en español. A nosotros nos gustan los monkeys. El motor de ejecución funciona en varias plataformas, y se está dando soporte a la compilación JIT ( justo-a-tiempo ) y AOT ( antes de tiempo ) en máquinas Intel x86 ( y pronto en PowerPC ). La librería de clases están ya lo suficientemente maduras como para ejecutar aplicaciones reales: nuestro compilador de C#, ASP.NET y aplicaciones basadas en GTK#. Vea el Mono Roadmap para más detalles sobre los planes de lanzamiento. Consulta la sección de "Contributing" el la pagina web de Mono: Seccion de contribuciones. Estamos interesados en probar las mejores herramientas para que los programadores desarrollen aplicaciones para sistemas operativos libre. También queremos ayudar en la interoperabilidad que irá a permitir que esos sistemas se ajusten con otros estandar. Para más información lea el White Paper del proyecto Mono. No. Era una broma. Novell está interesada en dotar a la comunidad de software con las mejores herramientas de trabajo para desarrollar aplicaciones para el Sistema Operativo Libre. Para mas información lee la página de definicion del proyecto. Por supuesto que no. Novell patrocina el proyecto mono, pero la única forma de implementar algo de este tamaño es cuando toda la Comunidad de Software Libre se involucre. Visita la pagina de contribuciones "Contribuciones" si quieres ayudar. Novell invertirá la mayor parte de sus recursos en hacer funcionar partes criticas del entorno de desarrollo y de ejecución. Una vez el proyecto este en un estado que sea útil para el mundo real, habrá alcanzado un numero suficiente de desarrolladores para mejorarlo. Cuando Mono esté listo para ser distribuido, Ximian ofrecerá soporte y servicios comerciales para mono. Los componentes de mono también se pueden licenciar de forma comercial. Para detalles sobre la licencia, contacte mono-licensing@ximian.com. Sí, Novell ofrece servicios de consultoría sobre servicios derivados de mono para hacerlo acorde a tus necesidades. Se puede portar en entorno de ejecución, personalizarlo, trabajar en clases específicas o modificar el código para adaptarlo a tus necesidades particulares. Mono será ofrecido en varias etapas a medida que el proyecto madure. Habrá gente que solo requiera un subconjunto de tecnológicas, para estos, el desarrollo estará completo antes. Puede mirar el calendario previsto. De varias formas. Este proyecto nació de la necesidad de probar herramientas mejores para la comunidad Gnome, y usará componentes desarrollados para Gnome cuando estos estén disponibles. Por ejemplo, planeamos utilizar Gtk+ y Libart para implementar Winforms y la API Drawing2D, y estamos considerando el soporte para GObject. Los miembros del equipo Mono trabajan intensamente en el proyecto Gtk#: un binding de las bibliotecas de clase de Gnome para .NET y Mono. Mono es muy nuevo para ser adoptado por esos grupos. Esperamos que las herramientas que desarrollemos sean adoptadas por los programadores de software libre, incluyendo aquí los miembros de la fundación Gnome y el proyecto Gnome en general. Si. Nosotros aseguramos que Mono 1.0 estará pronto para ser usado como plataforma de desarrollo de aplicaciones para el escritorio Gnome. Mono incluye Gtk#, un "binding" de Gtk+ y de las bibliotecas de Gnome para la plataforma .NET. Con eso aseguramos que es posible obtener una gran productividad en la creación de aplicaciones gráficas, comparandose especialmente al uso de Gtk+ o de "Java Swing". Si, proveeremos un conjunto de clases para implementar y usar componentes Bonobo a partir de Mono. Mono te deberá permitir escribir componentes Bonobo más facilmente, así como .NET en Windows te permite exportar componentes .NET para COM. No, Mono no depende de Gnome. Usamos algunos paquetes producidos por el equipo Gnome como la biblioteca "glib". También usamos otras bibliotecas Open Source de terceros como Cairo e ICU. Si, las personas podrán escribir aplicaciones Gnome usando Mono. Si, el proyecto Gtk# provee "bindings" para Gtk+, Gdk, Atk, libgnome, libgnomecanvas y libgnomeui. Otras bibliotecas del framework de Gnome serán añadidas a medida que sean necesarias. Si, podrá desarrollar aplicaciones gráficas. En realidad, éste es nuestro objetivo principal. Hoy puedes utilizar Gtk# o #WT para desarrolla aplicaciones gráficas, y el soporte para Windows.Forms está en camino. Si, las aplicaciones compiladas usando Gtk# podrán funcionar en Windows También. Las bibliotecas de Mozilla y de Gnome no serán soportadas actualmente y eso limita la portabilidad de sus aplicaciones. Ese problema será resuelto en el futuro. Gtk# es un conjunto de bindings para el toolkit Gtk+ para C# (y otros lenguajes CIL), que se integran nativamente con el escritorio Gnome. System.Windows.Forms es una API definida por Microsoft para la construcción de aplicaciones GUI. Windows.Forms está siendo implementado en código C# y usando System.Drawing para hacer la mayor parte de las tareas. Para más detalles vea "Winforms Roadmap". Un pequeño driver es necesario para el soporte en algunos sistemas operativos. Actualmente tenemos drivers para X Window y para Windows. El modelo de drivers permite que el porte para otros sistemas sea hecho de forma simple. Compatibilidad. Aunque sea posible ejecutar aplicaciones Windows.Forms simples con el backend basado en Gtk# de Windows.Forms, dificilmente esa implementación algún dia implementará todo lo que es necesario para una compatibilidad completa con Windows.Forms. La razón es por que Windows.Forms no es un toolkit completo, y para corregir éste problema un poco de la función interna de Win32 es expuesta al programador a través de la exposición del manipulador de mensajes de Windows (WndProc). Cualquier control puede sobreescribir éste métido. Más adelante se desarrollará generalmente P/Invoke en Win32 para conseguir la funcionalidad que no fue incluida. Para adquitir la compatibilidad total, tendriamos que emular esto, y eso puede llevar mucho tiempo. Para más información consulte la página de winforms Ya tenemos algunos parches en nuestra versión de Windows.Forms que hacen que Wine utilice las configuraciones del nucleo y fuentes de su escritorio, lo que aumenta mucho la integración. En el futuro, continuaremos mejorando ese escenario de interoperabilidades. Si sus aplicaciones fueran 100% .NET y no hicieran uso de "P/Invoke" en llamadas para las funciones de la API Win32, sus aplicaciones "smart client" rodarán en la plataforma Mono. Este enlace lo llevará a la página principal del proyecto. Gtk# se está volviendo bastante usable y podrá crear aplicaciones y applets como aquellos que ve en el ambiente Gnome. Es facil de instalar, por lo que vale la pena probarlo. Intente: mcs -r:gtk-sharp HelloWorld.cs Existe un archivo ejemplo llamado "DBClient" en gtk-sharp/samples que debes de consultar. Es un programa simple ten Gtk# que añade/actualiza/elimina información en una base de datos PostgreSql. Cuando tengamos los nuevos widgets table/tree, estoy seguro de que alguien escribirá un adaptador para System.Data (en Gtk2 los widgets tree/list son escritos usando view/model, entonces apenas precisará escribir un modle que mapee en la base de datos). Podrá dar una ojeada en gtk-sharp/sample/DbClient, donde hay una aplicación Gtk# que usa System.Data. Aunque no utilice DataAdapter, pero si DataReader. Aproximadamente el segundo semestre de 2005. Existe un documento explicando esa duda en: http://primates.ximian.com/~miguel/toolkits.html No hay ninguna cooperación en ese sentido entre Novell y Microsoft, así mismo los ingenieros que trabajan en .NET o ECMA están siendo muy amigables, respondiendo nuestras cuestiones o aclarando dudas sobre las especificaciones. Microsoft está interesado en otroas implementaciones de .NET y están dispuestos a ayudar creando las especificaciones en ECMA lo más exacta posible. Novell ha participado en los encuentros del comité ECMA para C# y CLI. No. No. Microsoft ha probado con el CLI y el lenguage C# que era posible crear una poderosa fundación para que muchos lenguages pudiesen interoperar. Ese conocimiento quedará para siempre. Igual que acontecen cambios no documentados en la plataforma, hoy la plataforma existente tiene valir por si sola. Si, estamos escribiendo Mono a partir de las especificaciones del ECMA y de los materiales impresos publicados sobre .NET. No. Mono no está relacionado con la iniciativa software-as-a-service de Microsoft. No. El proyecto Mono tiene como objetivo proveer un conjunto de herramientas compatibles para la plataforma de desarrollo .NET de Microsoft. No está direccionado de cualquier otra formar a endosar el sistema de asignatura única Microsoft Hailstorm basado en Passport, que es parte de Windows XP y otros servicios. No. MS Passport no es necesario para ejecutar aplicaciones compatibles con .NET producidas con herramientas de Mono. la única cosa necesaria es un compilador Just-in-time. La implementación "Código Compartido" será cara y sus usos serán muy restringidos, especialmente para uso comercial. Estamos trabajando en una implementación que garantizará un gran número de derechos importantes para sus usuarios: uso para cualquier propósito, redistribución, modificación y redistribución de las modificaciones. Esto es lo que se llama software libre. No. Mono es apenas un runtime, un compilador y un conjunto de bibliotecas de clase. No. Las aplicaciones pueden usar esa API para contactar con un sitio que use Passport, pero no están obligadas a hacerlo. Su su aplicación no usa Passport, no necesitará Passport. No. Entretanto, el toolkit de Passport para servidores web basados en Linux está disponible por parte de Microsoft. No. Microsoft Office es una aplicación de Windows. Para aprender más sobre la ejecución de aplicaciones Windows en sistemas Intel UNIX, tome como referencia el proyecto Wine. No. Eso requiere soporte para System.Windows.Form, que actualmente no está implementado. No, pero la API en el lado del cliente para autentificación no es un problema. Tenemos muchas otras APIs para la autentificación, como las APIs Liberty Alliance. El problema son las personas en el lado del servidor Web que utilizarán Passport para la autentificación. Mono se ejecuta en sistemas Linux, UNIX y Windows. Si, es posible en sistemas Linux usando algo como: if [ ! -e /proc/sys/fs/binfmt_misc/register ]; then /sbin/modprobe binfmt_misc mount -t binfmt_misc none /proc/sys/fs/binfmt_misc fi if [ -e /proc/sys/fs/binfmt_misc/register ]; then echo ':CLR:M::MZ::/usr/bin/mono:' > /proc/sys/fs/binfmt_misc/register else echo "No binfmt_misc support" exit 1 fi Mono, hoy en dia, viene con un compilador Just-in-Time para x86, PowerPC, s390 y sistemas basados en SPARC. El compilador es testeado regularmente en Linux, FreeBSD y en Windows (con nucleo XP/NT). Existe también un interprete, que es más lento y funciona en las arquitecturas x86, s3902, SPARC, HPPA, StrongARM y PowerPC. Mono requiere versiones Unicode de las API Win32 para funcionar, y apenas un subconjunto de las funciones *W son soportadas en Win9x. Existe "Microsoft Layer for Unicode" que provee una implementación de esas APIs para sistemas 9x. Infelizmente usa un truco en el enlazador para retrasar la carga que no es soportada por el ld, cuando algún tipo de adaptador es necesario. Precisará de MSLU y una de las bibliotecas para enlazar Mono a unicous.dll (http://mono.eurosoft.od.ua/files/unimono.zip) o alternativamente hacer una investigación en la red acerca de "libunicows". Ningún cambio en el código fuente de mono es necesario, apenas se debe tener la certeza de que el enlazador resolverá los "imports" para la biblioteca adaptadora en vez de las bibliotecas Win32. Eso se puede hacer insertando -lunimono antes de -lkernel32/user32 en el archivo specs del enlazador. Existen varios motivos: La mayoría de los contribuyentes de Mono son desarrolladores de Windows. Ellos poseen muchas referencias para contribuir en nuestro esfuerzo, y recordamos lo muy importante que es permitir que esos desarrolladores ejecuten el runtime en Windows sin forzarlos a usar otro sistema operativo. El soporte a Windows nos permite identificar las partes portables de Mono de las no portables, ayudando a Mono a volverse más portable en el futuro. Si, Mono puede hacer funcionar aplicaciones desarrolladas con el framework de Microsoft .NET en UNIX. Existen algunos puntos que deben de ser tomados en consideración: Mono todavía no está completado, entonces algunas pocas llamadas a la API pueden estar faltando, y en algunos casos el comportamiento de Mono podrá ser incorrecto. Si, el objetivo de Mono es implementar precisamente la API del framework de .NET (bien como subconjuntos de esa API seleccionables en tiempo de compilación, para aquellos interesados en una versión más simple de Mono). Si. Pero precisamos de tu ayuda para esto. Si encuentras algún bug en la implementación de Mono, por favor mande un informe de bug a http://bugzilla.ximian.com. No crea que sabemos sobre el problema, por que puede ser que no, y usar el sistema de bug trackin nos ayuda a organizar el proceso de desarrollo. Si, puedes. Entretanto como hoy Mono no está 100% terminado, alguna veces es util compilar código con Mono, para descubrir si tu aplicación depende de funcionalidades no implementadas. Algunas veces si. Pero alguna veces una aplicación .NET podrá invocar la API Win32, o asumir ciertos patrones que no son correctos para aplicaciones multiplataforma. Una aplicación 100% .NET es aquella que solamente utiliza las APIs definidas en el namespace System y no usa P/Invoke (Platform-Inoke, plataforma de invocación). Estas aplicaciones en teoría deben de funcionar sin modificaciones en Windows, Linux, HP-UX, Solaris, Mac OS X y otros. Observese que esto también es requerido para todos los assemblies utilizados por la aplicación. Si uno de ellos es específico de Windows, entonces el programa entero no es una aplicación 100% .NET. Además de eso, una aplicación 100% .NET no debe contener un flujo de datos de un assembly padre. Por ejemplo, Visual Studio .NET insertará un flujo #-tt> en los assemblies contruidos con el objetivo Debug. Este flujo contiene información de debug para uso de Visual Studio .NET. todavía, este flujo no podrá ser interpretado por Mono (a menos que esté deseando ofrecer soporte de él). Es recomendado que todo código compilado por Visual Studio .NET sea compilado con el objetivo Release antes de ser ejecutado sobre Mono. Si, con algunas restricciones. El programa .NET debe de ser una aplicación 100% .NET, o (de alguna forma) tener todos los assemblies de los cuales depende, disponibles en todas las plataformas deseadas. Mono también debe tener una implementación de los assemblies .NET utilizados. Por ejemplo, el namespace System.Enterpriseservices es parte de .NET, no fue implementado en Mono. Luego, cualquier aplicación que use este namespace no funcionará sobre Mono. La aplicaciones Visual Basic .NET son portables, pero la implementación en Mono de Microsoft.VisualBasic.dll está incompleta. Es recomendable evitar el uso de estos assembly en su códig, solamente utilice las partes implementadas por Mono. o ayude a implementar las características faltantes. Adicionalmente, puede ajustar para "Option Strict On", que elimina las llamadas implícitas a la clase Microsoft.VisualBasic.CompilerServices.ObjectType. (Gracias a Jörg Rosenkranz). Gestión de extensiones para C++ opera todavía más precariamente sobre Mono. Mono no soporta assemblies de modo mixed (esto es, assemblies conteniendo código gestionado y no gestionedo, lo que Managed C++ puede producir). Necesitas de un assembly completamente gestionado para funcionar sobre Mono, y conseguir que el compilador Visual C++ .NET genere un ejecutable de esta forma puede ser difícil. Necesita utilizar los assemblies del framework .NET, no las bibliotecas de C (no puedes usar printf(3), por ejemplo.), y necesitará usar opciones de enlazador /nodefaultlib /entry:main mscoree.lib junto con un flag de compilación /clr. POdrá entonces utilizar ciertas funciones intrínsecas del compilador (como memcpy(3)) y la STL. También debe verificar la "Converting Managed Extensions for C++ Projects from Mixed Mode to Pure Intermediate Language" en MSDN. Y finalmente, puede utilizar PEVERIFY.EXE del SD .NET para determinar si el assembly es completamente gestionado. Gracias a Serge Chaban sobre las flags del enlazador que deben de ser usadas. La mayor parte de Mono está siendo escrita usando C#, con apenas unas partes escritas en C (el JIT, el runtime, y las interfaces para el sistema de recolección de basura). Es más facil describir que es lo único en Mono: Un avanzado sistema de compilación de código nativo: Tanto compilación Just-in-Time (JIT) como precompilado de bytecodes CIL en código nativo son soportados. Una función para optimización de código: El nuevo generador de códigos de Mono fue contruido a partir de la experiencia de nuestro primer JIT, y nos permite implementar varios trucos avanzados de optimización de compiladores. Como el framework SSA, muchas nuevas optimizaciones son posibles. La lista actual de optimizaciones consisten en: Postpass de peephole, optimizaciones de Branch, llamadas Inline de métodos, folding constante, propagación de constantes, propagación de copias, eliminación de dead code, busqueda lineal de localización de registros globales, movimientos condicionales, código Emit por dominio, agenciamento de instrucciones, implementación de métodos intrínsecos, recursos y llamadas a cola, optimizaciones referentes a loops, comparaciones FP x86 rápidas, optimizaciones de procedimientos leaf. Un compilador C# self-hosting escrito en C#, que es limpio y facil de Mantener Objetivo en el Framework de .NET: estamos siguiendo las definiciones de la API del Framework de .NET, una vez que aseguremos que ésta es la API con la cual las personas están familiarizadas. Un motor de runtime multiplataforma: existe un motor y un intérprete JIT. El motor JIT funciona actualmente en sistemas x86, PowerPC, S390 y SPARC. En cuanto al interprete, funciona en sistemas x86, SPARC, StrongARM, s390 y PowerPc. El motor JIT está siendo portado a sistemas amd64 en este momento. Soporta Linux, BSD, MacOS, Windows y Solaris hasta ahora. El motor JIT está siendo escrito con un selector de instrucciones portable que no solamente genera buen código, sino que también es la función para redireccionar el motor JIT a otros sistemas. Soporte para remoting completo en el runtime. El compilador de C#, el motor JIT y las bibliotecas de clase están lo suficientemente maduras, de forma que el sistema entero se esté alojando a si mismo desde Abril de 2002. Eso significa que desarrollamos Mono completamente con él mismo hoy en dia. Nos forzamos a utilizar nuestro propio código para desarrollar nuestras herramientas, corregimos bugs rápidamente y el sistema en general es más robusto y testeado que si no lo hicieramos de esta forma. Nuestras bibliotecas de clases están bajo los terminos de la licencia MIT X11, que es una licencia muy liberal, el opuesto de la GNU GPL con excepciones, lo que significa que Mono puede ser utilizado en situaciones donde la GPL con excepciones no permite. Mono tiene una camada completa de Web Services: implementamos servidores web ASP.NET y bien el cliente web como la infraestructura SOAP basada en Remoting. Mono posee una completa implementación de C# 1.0 y tiene testedo mucho más de lo que tiene el compilador Portable.NET El compilador C# de Mono posee una fuerte manipulación de errores y una alta adherencia a la especificación como soporte a la atribución definida (requerida para generar código IL verificable) y comprobado conformemente como el CLS. El compilador C# de Mono es escrito en C#, lo que vuelve más facil que nuevos desarrolladores puedan entrar en el proyecto y mejorarlo, corregir sus fallos y optimizarlo. El compilador C# de Mono en C# es más rápido que el compilador en C. Preview de C# 2.0: trabajamos en progreso para una implementación 2.0 de nuestro compilador que está disponible (iterators, generics and method anónimos están disponibles en nuestro compilador "preview"). Mono posee una Reflection y una Reflection.Emit completas: Eso es importante para aplicaciones avanzadas, compiladores y generación de código dinámica. Mono posee una implementación completa de gestión XML: XML, XPath, XML Serializer, XML Schema handling. Están completamente funcionales, completas en características y ajustados para ejecutarlos. Mono posee una implementación completa de criptografía: implementamos las APIs 1.0 y 1.1 y estamos utilizando nuestra implementación completa para implementar transporter SSL/TLS. Soporte extensivo a bases de datos: Mono fue lanzado con proveedores de bases de datos (providers) para Firebird, IBM DB2, Oracle, Sybase, Microsoft SQL Server, SQL Lite, MySQL, PostgreSQL, Ole DB y ODBC. Mono incluye soporte completo para LDAP. Tenemos una comunidad de desarrolladores grande, sin la cual Mono no sería posible. En general, Mono está más maduro y completo, una vez que está siendo usado para desarrollarse a si mismo, lo que es una gran motivación para estabilizar la corrección, en cuanto a Portable.NET continua siendo una plataforma no testeada. Estamos ajustando nuestra implementación de forma que se vuelva compatible con la implementación de Microsoft. En otras palabras, la API P/Invoke de Mono está más completa comparada con la versión de Portable.NET, una vez que varias porciones de códigos que dependen de esta funcionalidad extendida no funciona de forma apropiada con Portable.NET. Mono apenas está relacionado con los Web Services por el hecho de que implementará el mismo conjunto de clases que fueron desarrolladas en el framework de .NET, para simplificar y facilitar el proceso de construcción de Web Services. Pero lo más importante es que Mono es una implementación Open Source del framework de .NET Podrá escribir Web Services en .NET que funcionaran en Mono, y viceversa. Si. Cuando el proyecto esté terminado, podrá usar las mismas tecnologías que están disponibles a través del SDK del framework de .NET en Windows para escribir Web Services. Soup es una biblioteca para crear servidores y clientes SOAP para aplicaciones Gnome, y puede ser usada sin Mono. Podrá examinar el código fuente de soup usando Gnomes's Bonsai. Si. El CLI contiene información suficiente sobre una clase, de forma que exponerla a otros sistemas RPC (como CORBA) es bastante simple, y no require el soporte de un objeto. Remoting.CORBA es una implementación de CORBA que está ganando popularidad. Construir una implementación de las interfaces Bonobo una vez que esté, será relativamente simple. Si, pero las herramientas de serialización aun no están siendo planeadas, y probablemente tengas que implementarlas. Existen algunas ventajas en utilizar ORBit, como la reutilización de código existente y aprovechar todo el trabajo hecho en él. Michael Meeks posteó algunas razones, como algunas ideas que podrán ser aplicadas para reusar ORBit. La mayoría de los usuarios optarán por una solución nativa de .NET, como Remoting.CORBA Monodoc es una navegador gráfico de documentación para las bibliotecas de Mono. Actualmente, Monodoc consiste en una aplicación Gtk# y está en intenso desarrollo. Si. El motor CLI estará disponible como una biblioteca compartida. El motor de recolección de basura (garbage collection), la abstracción de "threads", el sistema de objetos, el sistema de código de tipos dinámicos y el JIT están diponibles para que desarrolladores de C integren sus aplicaciones si así lo deseasen. Con un poco de suerte, entusiastas del Software Libre contribuirán con herramientas para mejorar el entorno de desarrollo. Estas herramientas podrán ser desarrolladas inicialmente utilizando la implementación CLI de Microsoft y despues ser ejecutadas con Mono. Estamos recomendando a las personas que usen y contribuyan en proyectos ya existentes, como SharpDevelop, Anjuta y Eclipse. La regla principal es que la pila en el CLI no es una pila de propósito general. No se le permite utilizar la pila con otros propósitos que no sean los de tratar valores y pasar argumentos a las funciones o retornar valores. Dada cualquier llamada o instrucción de retorno, los tipos en la pila tienen que ser los mismos, independientemente del flujo de ejecución de su código. En Mono, XSP es apenas el nombre del generador de código C# para páginas ASP.NET. En el proyecto Apache es un termino para la tecnología "eXtensible Server Pages" (Páginas Extensibles en el Servidor), entonces, como estás son cosas diferentes, no se deben de confundir. El CIL puede ser mejor "JITeado" que los bytecodes JVM, pero puede interpretarlos de forma tan trivial como interpretarías bytecodes JVM. El servidor XSP está disponible y puede usar también "mod_mono" con el servidor Apache. Si. Mono se está "autodesarollando" desde Marzo del 2002. Si. Basta con usar dos prefijos de instalación. Si dices una herramienta de test para C#, puede querer volverla independiente del compilador C# de Mono, de forma que otras implementaciones puedan utilizarla más adelante. Nosotros también renombramos "corlib" a "mscorlib" cuando salvamos archivos PE, de hecho, el runtime puede ejecutar perfectamente programas creados por mono. Puede usar: mcs /target:library file1.cs mcs /target:library file2.cs mcs /target:exe file1.dll file2.dll /out:mybin.exe La infraestructura de remoting está implementada. Tenemos implementaciones de TcpChannel, HttpChannel y de Soap y Formateadores Binarios. Son compatibles con .NET. Todavía, algunas clases de la biblioteca puden tener una representación binaria diferente, por que ellas pueden poseer una estructura de datos interna diferente, entonces por ejemplo, no podrá compartir un objeto Hashtable entre Mono y MS.NET. Esto no será un problema si estuvieras usando tipos primitivos, arrays de sus propias clases. Caso de tener problema, ¿Podría postear un test?. Cambie el atributo __stdcall por el macro STDCALL, e incluya eso en su código C para nuevas versiones de gcc: #ifndef STDCALL #define STDCALL __attribute__((stdcall)) #endif Por Carlos Perelló: Creo que la mejor solución es el recurso binfmt con el wrapper que existe con paquetes Debian en: http://www.debianplanet.org/mono/dists/unstable/main/source/admin/ Si quieres usar este en máquina "Big endian", debe aplicar un patch (http://carlos.pemas.net/debian/mono/binfmt-detector-cli.c.diff. Funciona realmente bien y permite que utilices Wine también. EL lee las cabeceras del archivo ".exe" y comprueba que el archivo es un ejecutable .NET. Debes de ejecutar de la siguiente forma: ./mi_aplicacion.exe y funcionará sin precisar de ninguna adaptación. Por Peter Williams y Gonzalo Paniagua: Eso (probablemente) es Red Hat 9 usando UTF9 en tu consola; los bytes son marcadores UTF8. Puede hacer esto: LC_ALL=C mono meuexe.exe Y ya no aparecerán. También puede hacer esto: $ echo -e "\033%G" para habilitar UTF-8 en la consola. Si. Mono soporta ASP.NET, tenemos una instalación sin modificar de IBuySpy funcionando bien en Mono, como otros programas. Puede verlo por ti mismo descargando el servidor XSP. Linux es suficiente. Necesitas de una máquina virtual Mono y un servidor web que aloje las páginas. Actualmente distribuimos un pequeño servidor web llamado XSP, que es usado para depurar aplicaciones, o puede usar mod_mono para ejecutas las páginas en Apache. El proyecto Mono desarollo un módulo para Apache llamado "mod_mono" que puede alojar páginas ASP.NET. Si. El módulo "mod_mono" soporta ahora las dos versiones de Apache (1.x y 2.x). Siempre podrá mantener una copia de Apache 2 ejecutando en paralelo con Apache 1.3 (en un puerto diferente o usando un reverse proxy). También puede diseñar dos servidores, con direcciones IP diferentes en la misma máquina física. El soporte para ADO.NET está completo y ya hay varios proveedores disponibles para él. a Si. Use la clase Mono.Data.SybaseClient. En primer lugar deberá crear un SybaseConnection, y entonces, a partir de él utilizar como cualquier otra clase basada en IDbConnection. Si. MySql Connector/Net fue construido por MySql AB y ellos son las personas que mejor conocen el funcionamiento de acceso a esa base de datos. El autor de ByteFX.Data no mantiene más ByteFX.Data por que fue empleado por MySql AB. Para más información vea http://www.mono-project.com/MySQL. Usa la clase Mono.Data.SqliteClient. Tenga la certeza de que está usando Mono 1.1.3, por que el proveedor de Sql Lite no funciona bien con las versiones 1.0.x o inferiores de Mono. Use una cadena de conexión como esta: "URI=file:SqliteTest.db" si estuvieras usando Sql Lite versión 2.x, o use: "version=3,URI=file:SqliteTest.db" si estuvieras usando Sql Lite versión 3.x. Para más información consulte http://www.mono-project.com/SQL_Lite Puede usar Npgsql, ya incluido en Mono. También esta incluido en la instalación de PostgreSql 8.0 para Windows. Para más información consulte http://www.mono-project.com/PostgreSQL A fin de cuentas, existen muchos lenguajes que apuntan a Java VM. Puede conseguir herramientas muy buenas para desarrollar utilizando Java hoy en dia en sistemas libres. Red Hat contribuye con un front-end GCC para Java, que puede a partir de los fuentes y bytecodes de Java, generar ejecutables nativos. Transvirtual implementó Kaffe, un motor JIT para Java. Intel también posee una máquina virtual Java llamada ORP. JVM no fue proyectada para ser una máquina virtual de propósito general. El lenguaje común intermediario (CIL), por otro lado, fue hecho tengiendo como blanco una gran variedad de lenguajes de programación, y tengiendo un conjunto de reglas proyectadas para ser optimizadas por "JITers". Si, Java puede ser integrado como CLI, el compilador de Microsoft J# hace exactamente eso. El proyecto IKVM desarrolla una máquina virtual que funcione sobre Mono. IKVM es esencialmente un compilador JIT, que traduce bytecodes JVM para instrucciones CIL, y entonces deja que el motor JIT nativo asuma el control. Si, eso es lo que hace IKVM. Eso puede ser hecho facilmente con IKVM. Si. El inicio de un compilador JScript puede ser encontrado en el CVS. Cesar coordina éste esfuerzo. Lo que puedes hacer con Mono es cargar aplicaciones diferentes en sus propios dominios de aplicación: esa es una característica del CLR que permite empaquetar aplicaciones en un único espacio de proceso. Eso es generalmente explotado para compartimentalizar diferentes partes de la misma aplicación, pero puede ser usado efectivamente para reducir el overhead de inicialización de memoria. Así se usan diferentes dominios de aplicaciones y la representación de runtime de tipos y métodos es compartida entre aplicaciones. Si. La colección de clases de Microsoft es muy grande, pero de ninguna forma puede ser considerada completa. Sería interesante la portabilidad de "Camel" (La Api de Mail usada por Evolution inspirada por Java Mail) para aplicaciones Mono. Puede también desear disponer la implementación de CORBA para Mono. No por que ella pueda ser últil, sino por que eso es una cosa divertida de hacer, dado el hecho de que CLI es un sitema rico en tipos. Para más información sobre como extender Mono, vea nuestra página de ideas. Cubrir una tecnología es algo bueno. Extender tecnologías de formas imcompatibles es ruín para los usuarios, entones no planeamos hacer cambios que traigan imcompatibilidades con las tecnologías. Si tienes ideas innovadoras, y desea crear nuevas clases, te animamos a hacer que esas clases funcionen correctamente en Mono y en .NET. Hoy Mono es distribuido con un número de bibliotecas extras que fueron desarrolladas por los miembros de la comunidad Mono y otros grupos. En algunos caso, recordamos que el código de Microsoft estaba incompleto, pero para evitar rompar la compatibilidad, expusimos la funcionalidad faltante en nuevos assemblies (Vea Mono.Security y System.Security). Si. Mono se está autodesarrollando desde Marzo de 2002. Si. Basta con usar dos prefijos de instalación Actualmente, estamos haciendo nuestro trabajo en sistemas Linux y Windows. No esperamos mucho linuxismo en el código, entonces debe ser facil de portar Mono para otras variantes de UNIX. Mono actualmente funciona en Linux, Windows, Solaris, FreeBSD, HP-UX y MacOS X. El motor Just-in-Time (JIT) está disponible en x86 y PowerPc, Sparc y procesadores s390 pueden generar código y optimizaciones para una CPU específica. Existen intérpretes para CPUs Itanium, HP-PA y StrongArm. Si. Puedes conseguir los binarios precompilados en http://www.mono-project.com/downloads/index.html Si. Puedes conseguir los binarios precompilados en http://www.mono-project.com/downloads/index.html No. Cygwin solo es necesario para construir Mono. Dependerá solamente si usas algún assemblie en particular (por ejemplo, para desarrollar aplicaciones GUI). Si está interesado en Mono para implementar un "P2P Enterprise Web Service Hello World", no necesitará de ningún componente Gnome. Eto Demerzal ya inició la portabilidad de Rhino para C#. Si, Mono funciona en Linux/PPC y MacOS X (10.2 y 10.3). Queremos poner luego Mono en las manos de los programadores. Estamos interesados en reutilizar el software open source existente. No existe la necesidad de reescribir tu código si continua usando Microsoft Sql Server. Si quisiese utilizar una base de datos Open Source, entonces necesitará hacer cambios en sus fuentes. No hacer llamadas a P/Invoque o DLLs y no utilizar nada que sea parte de los namespaces Microsoft.* es suficiente. No use todavía Métodos/Clases marcadas como "Este tipo/método soporta la infraestructura del framework de .NET y no debe ser utilizado directamente a partir de su fuente.", excepto que sepas lo que esas clases/métodos hacen. Crystal Reports es propietario. Alguien puede intentar crear algo parecido, pero no hay ningún voluntario. Intente evitarlo. Aunque pase, verá una emulación para el registro en Mono. Gnome tiene un mecanismo de configuración similar al registro, pero las llaves no son iguales, entonces probablemente terminará por tener que hacer alguna detección en el runtime, y dependiendo de la detección, cargar un assembly con las modificaciones específicas de la plataforma. Si, eso ya fue hecho. No. No se está haciendo nada de eso. No existe nada en ese sentido, pero Mono ya provee servicios de precompilación (compilación Ahead-of-time). Actualmente no hay instrucciones para eso, entretanto existen algunos esfuerzos en ese sentido. El concepto sería similar al uso de gestionar C++ de la implementación de Microsoft. El problema es que gestionar el C++ de Microsoft no produce código totalmente gestionado y la máquina virtual no está preparada para gestionar código nativo para diferentes plataformas. Existen algunas soluciones posibles: Usar un generador de código como SWIG que lee el código C++ y genera unas bibliotecas de funciones C que pueden ser llamadas por C#. Pró: permite usar código C++ por C#. Contra: No es muy elegante; Una camada extra tiene impacto sobre la ejecución. Había un esfuerzo con el compilador WHIRL-to-IL, que compilaría C (y probablemente C++) en CIL que Mono podría ejecutar. Modificar GCC para producir CIL. Usar Gimple en GCC 4.0. WHIRL es el nombre de la representación intermediaria produciza por el compilador Open64 de SGI. El compilador Open64 es una versión modificada de GCC que genera un nuevo lenguaje intermediario en vez de RTL. Este podría ser la base para la generación de código CIL, y para implementar las futuras extensiones gestionadas para C++ del ECMA. Open64 (y otros forks derivados de GCC) dividen los front-ends de los backends, utilizando una representación WHIRL intermediaria. Kris comenzó la implementación de un traductor de WHIRL para CIL. Entonces sería posible usar compiladores GCC que generasen código CIL. Una vez que exista un traductor completo para WHIRL, estamos interesados en procurar expandir los front-ends de GCC para incluir extensiones para gestionar C++. La implementación del lenguaje VB.NET está en proceso. Para encontrar más información sobre la situación actual del compilador, mire la página sobre Basic. Por el momento, Mono no tiene ninguna intención de implementar el lenguaje VB6. La ventaja principal reportada sobre VB6 es su integración con los controles basados en COM, que no estarían disponible para UNIX. En general la ventaja principal de VB6, es la disponibilidad de controles abastecidos por terceros. Un esfuerzo en esta implementación requeriría una implementación de la tecnología COM para ejecutar los controles existentes. Esta tare está fuera del objetivo de Mono. Esos lenguajes son simples de implementar, excepto por su dependencia de objetos COM. Entretanto, en este momento no hay planes de implementarlos. No podemos predecir el futuro, pero una estimación conservadoras es que sera por lo menos tan rápido como otros motores JIT". El motor JIT de Mono fue recientemente rearquitectado, y provee muchas nuevas características, y camadas subseptibles a optimizaciones. Es relativamente facil añadir nuevas optimizaciones en Mono. El CIL tiene algunas ventajas obre los bytecodes de Java: La existencia de struct en vez de clases, ayuda mucho a la ejecución y minimiza los requerimientos de memoria de las aplicaciones. Generalmente en el mundo CLI son ciudadanos de primera clase, no son apenas un añadido fuertemente tipado al lenguaje. Las especificaciones genéricas son embebidas en el flujo de instrucciones, y el JIT usa esta información para "JITar" una única instancia de un método que es optimizado en los argumentos de tipo. El CIL es realmente una representación intermediaria y existe un número de restricciones sobre como puedes emitir código CIL que simplifique la creación de mejores motores JIT. Por ejemplo, en el CIL, la pila no es realmente una abstracción disponible para que el gestor de códigos lo utilice a su gusto. En vez de eso, es una manera de crear una representación fija del arbol de analisis gramatical. Cualquier dato punto de llamada o punto de retorno, se espera a que la pila contenga los mismos tipos de objetos, independientemente de como la instrucción fue obtenida. Si. La licencia fue planeada para permitir la creación de aplicaciones propietarias. Usamos tres tipos de licencia: El compilador de C# y las herramientas esstán licenciadas bajo los terminos de la GNU General Public License (GPL). La máquina virtual está bajo la GNU Library GPL 2.0 (LGPL 2.0) Las bibliotecas de clases están licenciadas bajo los terminos de la MIT X11. Tanto la máquina virtual como el compilador de C#, están también disponibles en una licencia propietara, para que no se pueda usar LGPL o GPL en su código. Para más información sobre la licencia, contacte con mono-licensing@novell.com. Originalmente, las bibliotecas de clases eran licenciadas bajo los terminos de la GNU Library GPL (LGPL). El problema de la GNU LGPL esta en las partes ultrapasadas relacionadas a trabajos derivados. Un trabajo derivado necesitaría estar licenciado bajo la misma licencia. Esta definicion era buena antes de la existencia de las bibliotecas orientadas a objeto, pero con la introducción de las bibliotecas orientadas a objeto, muchas personas están en desacuerdo en que la herencia de una clase orientada a objeto sea considerado un trabajo derivado. Las bibliotecas de clases son una parte bien grande de Mono y es ahí donde está la mayor diversidad de contribuciones. Debido a ésta ambigüedad y el hecho de que diferentes autores puedan interpretar los terminos de la licencia de forma diferente, hemos escogido una licencia que continua siendo libre sin esas ambigüedades. La ambigüedad permitirá que el autor de un código exigiese la liberación de las partes del código, basandose en conceptos técnicos. Nosotros no queremos que eso suceda con Mono en el futuro. Primeto tenemos que avalar la compatibilidad de su licencia, aunque generalmente aceptamos código, bajo los mismos terminos del módulo en el que el código formará parte. Cuando un desarrollador continue con el código para el compilador de C# o la máquina virtual de Mono, le pedimos al autor derechos para relicenciar su contribución bajo los terminos de otras licencias. Esto le permite a Novell redistribuir el código de Mono para que no pueda usar versiones GPL o LGPL del código. Particularmente fabricantes de sistemas embebidos, pueden obtener derechos sobre la máquina virtual de MOno y modificarla para sus propósitos sin necesidad de devolver sus modificaciones. Comencemos con algunas consideraciones. El framework de .NET está dividido en 2 partes: las tecnologías cubiertar por el ECMA/ISO y otras tecnologías desarrolladas sobre éstas últimas como ADO.NET, ASP.NET y Windows.Forms. Mono implementa ambas partes, las cubiertas por el ECMA/ISO y otras de más alto nivel como ASP, ADO.NET y Windows.Forms. El proyecto Mono fue desarrollando esos componentes e integrando bibliotecas y clases de receros, siendo las más importantes: APIs de depuración, integración con la plataforma Gnome (Accesibilidad, renderización Pango, Gdk/Gtk, Glade, GnomeUI), Mozilla, OpenGL, soporte extensivo a bases de datos (Microsoft solamente soporta algunos proveedores, cuando mono soporta 11 tipos diferentes de proveedores), bibliotecas de integración POSIX y finalmente la API embebida (usada para añadir capacidades de ejecución de scripts en aplicaciones y alojar el CLI, como el runtime embebido en Apache). El nucleo del framework .NET que fue patentado por Microsoft fue sometido al ECMA/ISO. Jim Miller de Microsoft hizo una declaración de las patentes que cubren en ISO/ECMA (él es uno de los inventores listados en la patente). Básicamente permite que cualquiera que quiera implementar esos componentes, pueda hacerlo con cualquier propósito. Los elementos de la controversia son los conjuntos de clases ASP.NET, ADO.NET y Windows.Forms. Estas son necesarias para aquellas que necesitan de total compatibilidad con la plataforma Windows, aunque no son necesarias para la plataforma open source Mono, e ninguna para la integración y soporte de Mono en Linux. La estrategia de Mono para congeniar con éstas tecnologías es la siguiente: Superar la patente usando una técnica diferente de la implementada que mantenga la API aunque cambie los mecanismos, si eso no es posible podemos: Eliminar partes del código cubiertas por esa patente o: Encontrar trabajos anteriores que inutilicen la patente. No proveer ninguna característica/capacidad patentada llevaría a la interoperabilidad, aunque todavía si proveeriamos a la comunidad de software libre una buena herramienta de desarrollo, que es la razón principal para desarrollar Mono. Es importante recordar que las patentes no se aplican a paises donde las patentes de software no están reguladas. Para el desarrollo del Linux desktop o servidor, solamente necesitamos de componentes ECMA, y las cosas que nosotros mismo desarrollamos (Como Gtk#) y la integración con Apache. Además de implementar las clases del framework de .NET, Mono implementa también un gran conjunto de bibliotecas específicas de UNIX, de Gnome y algunas otras que aunque no sean parte del framework de .NET son útiles para muchas personas. El mapa siguiente muestra la relación entre los diversos componentes: Mapa de componentes de Mono Si, acepta codebehind en su implementación de ASP.NET. Aunque queda avisado de que mono ignora el atributo CodeBehind que VS.NET añade a sus páginas generadas. ASP.NET hace referencias a algunos assemblies padres y todos los assemblies encontrado sn el directorio bin de su aplicación. Si necesita hacer referencia a algún otro assembly que está instalado en el GAC, use: ]]> Si tienes un tag en un archivo MyTags.dll, y ese archivo no está en el directorio bin o GAC, y quiere que el prefijo sea something, añade lo siguiente a su página: ]]> Ahora, si existe un control en el assembly MyTags.dll llamado SuperDuper puede usar lo siguiente: El soporte para aplicaciones ASP.NET está en desarrollo y todavía no está completo, Si quiere intentarlo, use el comando xsp2. Necesitará instalar los assemblies y compiladores de la versión 2.0 preview. La portabilidad es en la mayoría de los casos un problema cuando quiere mover su aplicación Windows/.NET para Mono en una plataforma Windows. Si estuviera desarrollando una aplicación desde cero, los problemas de portabilidad estarán resueltos si testea su aplicación regularmente en Linux y en Windows durante el desarrollo. No todas las aplicaciones escritas para ASP.NET funcionan en Mono la mayoría de las veces debido a suposiciones que hacen los desarrolladores. En UNIX, los nombres de archivos son case sensitive y es posible, por ejemplo, tener en el mismo directorio Login.aspx y login.aspx. Si los desarrolladores no mantienen la consistencia en los nombres de archivo, no funcionará. Estos son los problemas más comunes: Los archivos ASP.NET están, por ejemplo, como Login.aspx, pero todas las referencias en el código están como login.aspx. La aplicación usa el registro de Windows para guardar configuraciones (Mono no implementa las clases de registro para Unix). La aplicación usa clases no disponibles en Mono (EnterpriseServices por ejemplo). Portar una aplicación requiere que esos cambios sean considerados. La mayoría de las aplicaciones funcionarán en Mono sin que se haga nada, pero otras necesitarán ser corregidas de los problemas citados en la sección anterior. Si quiere ver la lista de aplicaciones ASP.NET portadas en Mono vea http://www.go-mono.com/ports/ o eche un ojeada a otras aplicaciones como nGallery, que incluye soporte para Mono. Los siguientes proveedores poseen soporte para aplicaciones ASP.NET en Mono: http://monoforge.com http://www.grokthis.net Mono actualmente usa un conservador y no remueve el recolector de basura. Esto significa que la falta de memoria no es redimensionada cuando la memoria es liberada. Entonces las aplicaciones podrán hacer un uso exagerado de la memoria, que hará que el proceso crezca como aplicaciones en C, C++, Perl y Python. Es importante no cometer éste tipo de error, por ejemplo, en vez de crear un bloque de tamaño SIZE y liberarlo, puede crar dos de tamaño SIZE/2+1 ASP.NET en Mono es particularmente vulnerable a éste tipo de problema de memoria por que es facil para los desarrolladores definir APIs que transfieran grandes bloques de datos, como archivos de imagen enteros, eso reservaría mucha memoria que puede ser fragmentada. Una solución simple sería intentar escribir aplicaciones que no reserven grandes bloques de datos, y si varios bloques pequeños. WebRequest.Create("https://www.anywhere.com"); genera una excepción. Esto probablemente suceda por que Mono no confia en el sitio al que está intentando conectar. La instalación principal de Mono está configurada para no confiar en sitio alguno. Para confirmarlo hay una herramienta tlstest.ext mcs tlstest.cs /r:System.dll /r:Mono.Security.dll mono tlstest.exe https://www.anywhere.com Existen dos alternativas para resolver el problema: Implementando ICertificatePolicy en una clase. Un ejemplo está disponible en el código fuente de tlstest.cs. Haciendo ésto, podrá sustituir los resultados normales de validación del certificado (y por ejemplo aceptar un certificado no confiable). Mientras tanto quedará como responable de sus propias reglas de confianza para su aplicación. Usando la utilidad certmgr.exe (incluso en Mono) para añadir certificados a la raiz de Mono. Todos los certificados SSL asignados a la raiz serán aceptados (ninguna excepción será aceptada) para usar con SSL (para todas las aplicaciones de Mono ejecutadas por el usuario o por el ordenador - dependiendo de donde esté instalado el certificado). SSL cifra los datos - pero cifrar los datos en un servidor inseguro no servirá de nada. Necesitará saber quien está al otro lado. SSL usa certificados X.509 con el propósito de verificar una clave pública junto a una entidad (en este caso un Web Server). El servidor pone este certificado junto a una autoridad certificadora (CA) que certifica si una clave pertenece a su dueño. Entonces podrá confiar en una entidad certificadora para hacer este trabajo correctamente. Si. Mono acepta la firma para assemblies. Assemblies son archivos de tipo PE. Mono soporta la firma de varios tipos de archivo PE, como EXE, DLL, OCX, SRC... No. Los archivos CAB no son archivos PE. En cuanto a los mecanismos de asignación son semejantes, el formato CAB es muy diferente del formato PE. Mono no requiere de archivos CAB en este momento (y talvez nunca), entonces soportar la firma de archivos CAB no es necesario (a menos que alguien quiera contribuir con eso). Signature can't be traced back to a trusted root! o A assinatura não pôde ser rastreada até uma autoridade raiz!. La instalación principal de Mono no confia en ninguna entidad certificadora (CA). Al verificar un archivo PE, la utilidad chktrust intentará encontrar una raiz confiable y si no la encuentra emitirá el siguiente error: Mono CheckTrust 1.1.4.0 Verifying file sample.exe for Authenticode(tm) signatures... WARNING! sample.exe is not timestamped! ERROR! sample.exe signature can't be traced back to a trusted root! Podra utilizar la herramienta certmgr para añadir un certificado raiz para la firma de código. No. Mono tiene un soporta limitado a la construcción y validación de certificados PKIX. Eso es suficiente para casos simples de autentificación SSL/TLS y firma de código. La versión 2.0 del framework de .NET mejorará este soporte con nueva clases X609Chain. Existen dos principales razones para no incluir certificados raiz en la instalación principal de Mono: Certificados digitales son como la mayoría de los archivos digitales pasivos de derechos de autor. Eso hace que existan restricciones en cuanto a su distribución. No estamos en el negocio para decidir quien es confiable y quien no. Las autoridades certificadoras existen en todo el mundo. El mejor servicio para ti podra no ser el mejor servicio para otras personas y tener una lista enorme de raizes confiables no es una solución muy segura. Mono 1.0.x (estable) no soporta CAS (Code Access Security). Mono 1.1.x tiene un soporte parcial (la implementación está en desarrollo) pero las bibliotecas de clases no tiene protección en la mayoría de sus recursos. En Mono 1.2 habrá una previa de esa tecnología (desligada por la principal) con soporte parcial a biblioteca de clases. El soporte total está previsto para Mono 2.0. Principalmente el soporte para CAS está desligado en Mono. En Mono 1.1.4 o versiones superiores podrá activar el soporte de gestión de seguridad usando la opción --security. mono --security sample.exe Esta Faq contiene material producido por: Miguel de Icaza Jaime Anguiano Lluis Sánchez Traducción libre al Español por: Ezequiel Foncubierta - efoncu@agali.org Parte de la traducción (puntos "General-Básicas" y "General-Mono y Novell") se debe a: Fabian seoane - fabian@fseoane.net Eduardo García - kiwnix@yahoo.es Alejando Sánchez - raciel@x0und.net