Entradas etiquetadas como ‘.Net’

Escrito por Iván Alonso el Lunes 16 de Noviembre de 2009

Necesitamos instalar:

  1. Mono para OS X (incluye Mono, GTK# y Cocoa#)
  2. MonoDevelop para OS X

Con la primera ejecución de MonoDevelop nos buscará las últimas actualizaciones.

Para comprobar que todo está funcionando correctamente, crearemos una aplicación de prueba que muestre un Hola Mundo, pero la peculiaridad estará en que utilizaremos los mismos espacios de nombres que usamos cuando programamos bajo Windows. Es decir, no utilizaremos GTK#, Cocoa#, ni ningún otro subsistema, sino WinForms.

Creamos una nueva solución C# vacía, como la siguiente:

Captura de pantalla 2009-11-16 a las 13.49.15.png

Tras esta ventana, puede aparecer otra para activar determinadas opciones para personalizar el proyecto, pero no marcaremos ninguna (en caso de necesitarlas, puede hacerse posteriormente en las opciones del proyecto).

Se habrá creado la solución HolaMundo con el proyecto HolaMundo en su interior. Haciendo click derecho sobre el proyecto añadiremos un nuevo archivo C# (Añadir, Nuevo Archivo, Empty Class, y le ponemos como nombre -por ejemplo- CHolaMundo).

Captura de pantalla 2009-11-16 a las 13.53.28.png

Captura de pantalla 2009-11-16 a las 13.54.50.png

Incluiremos el siguiente código en el nuevo archivo creado:

using System;
using System.Windows.Forms;
 
namespace HolaMundo
{
   public class CHolaMundo : Form
   {
      static public void Main ()
      {
         Application.Run (new CHolaMundo ());
      }
 
      public CHolaMundo ()
      {
         Text = "Hello Mono World";
      }
   }
}

Si intentamos compilar en este momento, nos devolverá el error:

Error CS0234: The type or namespace name `Windows’ does not exist in the namespace `System’. Are you missing an assembly reference?

La razón es que, por defecto, el compilador de C# incluído con mono únicamente referencia los siguientes ensamblados: mscorlib.dll, System.dll y System.Xml.dll. Para que el proyecto sepa que debe referenciar System.Windows.Forms, podemos lanzar el compilador desde línea de comandos (con el parámetro -r:System.Windows.Forms.dll), o añadirlo permanentemente a las opciones del proyecto.

Bajo el nombre del proyecto, en los archivos de la solución, veremos la carpeta Referencias, sobre la que haremos doble click, y buscamos el ensamblado que queremos referenciar en nuestro proyecto:

Captura de pantalla 2009-11-16 a las 14.09.23.png

Tras incluirlo, la solución ya funcionará perfectamente, por lo que podemos hacer un Build (Command+K) y Ejecutar (Command+Alt+Enter), y podremos ver este resultado:

Captura de pantalla 2009-11-16 a las 14.17.19.png

Desde luego no es la aplicación de .Net más compleja que podíamos utilizar como ejemplo, pero ya es algo. Y tanto el código utilizado como el ejecutable resultante son 100% compatibles con sistemas Windows.

Escrito por Iván Alonso el Martes 9 de Septiembre de 2008

El contenido de este post está extraído parcialmente de la página del proyecto Mono, por lo que hereda su licencia GNU Free Documentation License 1.2.

Echándole un vistazo al roadmap de desarrollo planeado en el proyecto Mono, podemos ver las siguientes versiones, y las funcionalidades que irá incluyendo cada una de ellas:

Mono 2.2 (Noviembre 2008):

  • Un nuevo compilador Just-In-Time y completar las funcionalidades del Ahead-of-Time.
  • MSBuild, MoMA Web Tools, un motor de Windows.Forms nativo, y otras funcionalidades.
  • MonoDevelop 2.0, probablemente la opción más interesante a destacar de esta lista. Actualmente ya se ha liberado la versión Alpha de esta versión.

Mono 2.4 (Febrero 2009):

  • Verificador de metadatos, plugin de Visual Studio (ya en beta) para depurar proyectos remotos, ASP.NET 3.5, Windows.Forms actualizado para OS X, MonoDevelop 2.2, Linq to DB.

Mono 2.6 (Mayo 2009):

  • Silverlight 2.0 (preview), ASP.NET MVC.

Mono 2.8 (Agosto 2009):

  • Silverlight 2.0 (beta), MonoDevelop 2.4, nuevo Garbage Collector (Compacting GC).

Otros proyectos que seguirán sus propios roadmaps: Navegador de documentación, debugger, integración de Java a través de IKVM, el proyecto Olive (.Net 3.0) y GTK#.

Y después… to infinity, and beyond!

Escrito por Iván Alonso el Martes 9 de Septiembre de 2008

Antes que continuar con más aspectos técnicos sobre Mono, quizá sea más interesante conocer un poco del trasfondo y la situación histórica que nos lleva hasta aquí.

En 1996 comenzó el proyecto KDE, para dotar a GNU/Linux con un sistema de ventanas mucho más avanzado de lo que existía hasta el momento. Aunque KDE era software libre, se basaba en el toolkit Qt de Trolltech, que por aquel entonces tenía una serie de licencias restrictivas que lo hacían en cierto modo incompatible con la filosofía de libertad de GNU.

En Agosto de 1997 diero comienzo varios proyectos para solventar esta situación, entre ellos Gnome (dirigido por Miguel de Icaza y Federico Mena), aunque cuando más adelante Qt pasó a tener una licencia mucho más libre (2000) sólo Gnome continuó su camino. Así, lo que Gnome pretendía era ofrecer otra opción a KDE que fuera verdaramente libre. Para esto eligieron GTK+ (el toolkit de GIMP) como sistema sobre el que construir su nuevo entorno, en el que poder utilizar licencias como LGPL (Aún liberado, Qt sigue utilizando la licencia GPL, que es más restrictiva con respecto a lo que se puede hacer con el software que la incluye, especialmente cuando tratamos con librerías).

En el 2000, cuando los documentos sobre estándares de .Net vieron la luz, Miguel de Icaza comenzó a interesarse por ellos, desarrollando un compilador de C#. En Ximian, la empresa dedicada al desarrollo de aplicaciones para Gnome fundada por (entre otros) de Icaza, se realizó un estudio de viabilidad para asegurarse de que la tecnología del proyecto Mono podía desarrollarse, tratando así de encontrar nuevas formas de desarrollo que facilitaran la creación de aplicaciones (probablemente el punto más fuerte de .Net).

El 20 de Junio del 2004 se liberó Mono 1.0.

Escrito por Iván Alonso el Lunes 8 de Septiembre de 2008

Ya sabemos más o menos que es eso de Mono. Intuimos que, como todos los grandes proyectos Open Source, tiene un roadmap de funcionalidades a incluir, por lo que nos preguntamos ¿En qué estado se encuentra ahora mismo el proyecto?

A lo largo de este Septiembre de 2008, aparecerán varias versiones release candidate, como preludio a la aparición de la versión 2.0 de Mono a final de mes. Este es un resumen de cómo quedará el proyecto tras esta nueva versión:

API: Terminadas las Base Class Libraries con lo que le faltaba (Windows.Forms) hasta .Net 2.0. Añadido ADO.NET 2.0 y ASP.Net 2.0 (WebForms y Web Services, faltan WebParts y ciertas partes de Mobile).

Compiladores: C# 3.0 (incluyendo LINQ to Objects y LINQ to XML, aunque aún sin LINQ to SQL u otras bases de datos) y Visual Basic .Net con generics.

Máquina Virtual: Ahora incluye también DLR (Dynamic Language Runtime), que en .Net se utiliza para IronRuby o IronPython, y en un futuro en otros lenguajes más asociados al scripting como el futuro Visual Basic .Net 10.0.

Otros:

  • MoMA (Mono Migration Analyzer), una herramienta para evaluar la complejidad previa de portar un proyecto de .Net a Mono.
  • Gendarme: una herramienta para analizar programas y librerías en código intermedio buscando problemas que los compiladores no suelen buscar.
  • Debugger: Que se está rehaciendo, dado que en la última versión de MonoDevelop no es posible realizar debug de la aplicación.

Otros proyectos con su propio roadmap:

  • Moonlight: implementación libre de Silverlight, con apoyo por parte de Microsoft. Actualmente soporta la versión 1.0 y se ha comenzado con la 2.0. El desarrollo puede hacerse con su propio IDE (Lunar Eclipse), y ya existe como plugin para Mozilla.
  • Proyecto Olive: trasladar nuevas librerías de .Net a Mono, entre las que se encuentran algunas de las más interesantes de .Net 3.0, como WF, WCF o WPF, aunque aún se encuentran en un estado muy alpha.
  • Proyectos Google Summer of Code: LINQ to DB (MySql, Oracle y PostgreSQL), MSBuild, etc.
  • Otras librerías: Al igual que se han reimplementado las Base Classes, también hay muchos proyectos relacionados con Mono o que incluyen wrappers/bindings a otros sistemas, como: GTK#/Glade# para utilizar las interfaces de usuario de GTK+ y/o desarrollar aplicaciones nativas para Gnome, Mozilla libraries (Gecko#), integración con Mac OS X (Cocoa#), bases de datos, seguridad, integración con Unix, y un largo etcétera [documentación].
Escrito por Iván Alonso el Lunes 8 de Septiembre de 2008

Básicamente es una versión libre de .Net, aunque definirlo así no es del todo acertado, ya que existen similitudes y algunas peculiaridades en partes de sus componentes. En la wikipedia encontramos una definición bastante acertada:

Es un conjunto de herramientas compatibles con .Net que siguen estándares ECMA.

.Net puede reducirse a tres componentes: un compilador, una máquina virtual y un conjunto de librerías. Como Java. En el caso de .Net existen decenas de compiladores que traducen distintos lenguajes al código intermedio de .Net (CLI, Common Language Infraestructure), aunque el proyecto Mono se ha centrado principalmente en C#, y posteriormente algunos otros.

La máquina virtual (el CLR), proporciona un entorno seguro de trabajo, control de memoria, hilos de ejecución, control de excepciones, un garbage collector

Las librerías (Base Class Library) encapsulan muchas de las funcionalidades que podemos necesitar en el día a día del programador, y son lo bastante amplias como para poder desarrollar aplicaciones complejas en su totalidad sin necesitar librerías externas.

¿Qué incluye Mono de todo esto? Pues vayamos por partes: dado que el código intermedio (CLI) es un estándar liberado por Microsoft (bajo el control del ECMA, estándar Ecma-335), cualquiera puede programar compiladores para esta tecnología. El compilador de C# de Mono sólo necesita basarse en las especificaciones del CLS (Common Language Specification) y del lenguaje C# (también estándar, Ecma-334). También existen documentos ISO definiéndolos [lista].

El CLR es una implementación concreta de Microsoft, pero Mono incluye su propia máquina virtual compatible con el CLI. Incluye un compilador Just-in-time, un compilador Ahead-of-time, cargador de clases y librerías, garbage collector, threads e interoperabilidad.

Y las librerías: Mono incluye una reescritura de prácticamente todo el API, aunque alguna cosa podría faltar. El principal caballo de batalla (de hecho en prácticamente cualquier sistema de código abierto) ha sido siempre el interfaz de usuario. El espacio de nombres Windows.Forms alcanzará compatibilidad con la versión 2.0 de .Net en la próxima aparición de Mono 2.0. Por otra parte, aquellas partes de las librerías de .Net que hayan sido incorporadas más tardíamente a Mono, tienen contrapartidas funcionales. Por ejemplo: Si no queremos usar la implementación Mono de Windows.Forms, podemos utilizar GTK#.

En resumen:

Por lo tanto, hemos visto qué es Mono y hemos comparado sus tres bloques principales con .Net, viendo que nos proporciona una implementación libre (y verdaderamente multiplataforma) de .Net, permitiendo incluso utilizar código (y binarios) desarrollados con Visual Studio en otras plataformas.

En el próximo post de esta serie veremos otras peculiaridades de este sistema.

Escrito por Iván Alonso el Jueves 19 de Junio de 2008

Sigo con el tema con el que estaba el otro día, cambiando código obsoleto por cosas más legibles y/o más rápidas (aunque lo cierto es que las expresiones regulares pueden llegar a ser bastante poco legibles, especialmente si no estás acostumbrado a utilizarlas (o, como yo, no te acuerdas)).

Para normalizar un montón de textos, aplicamos algunos patrones para eliminar los molestos símbolos en los que se transforman las Ñ’s en otros sistemas de software, por ejemplo almohadillas, diéresis, el símbolo del yen, etc.


// Sustituimos  símbolo raro + vocal
// por "Ñ" + vocal
// Simbolo raro = {blackslash, almohadilla, yen, dieresis}
salida = Regex.Replace(salida, @"[#\\¥¨](?<vocal>[AEIOU])", "Ñ${vocal}");

Una aparición de los símbolos (doble barra invertida para escapar el carácter), seguido de una vocal, lo cambiamos por una Ñ seguida de la misma vocal. La ‘memoria’ antes y después de la aplicación de la expresión regular se consigue con la utilización de ?<nombre> en el patrón de reconocimiento y ${nombre} en el patrón de salida.

Una cosa interesante es que realmente estamos escapando el símbolo de la barra invertida dos veces, una al duplicarla y otra al comenzar el string con una arroba. Así lo escapamos en el entorno de programación y lo volvemos a escapar cuando la cadena llega al motor de expresiones regulares. Esto es lo que me llevó algo más de tiempo para darme cuenta, el resto se solucionó con una rápida petición de ayuda por Messenger a S., que ya me ha estado echando una mano con un par de dudas relacionadas con los css de esta web.

Escrito por Iván Alonso el Jueves 12 de Junio de 2008

Estoy reescribiendo una librería bastante desactualizada, en la que aparentemente han metido mano muchas personas diferentes. Se manejan una serie de strings que hay que “estandarizar” antes de comprobar si son válidos o no, y uno de los métodos que estaban implementados era:

/// <summary>
/// Función auxiliar que se le pasa una cadena y elimina todos los caracteres
/// blancos duplicados entre palabras.
/// </summary>
static public string EliminaBlancos(string cadena);

El código era un horrendo bucle que iba buscando sucesivas apariciones de dobles espacios y… en fin (y usando strings en lugar de StringBuilder, por si fuera poco). Obviamente este tipo de cosas pueden hacerse bastante rápido con expresiones regulares, pero como nunca suelo utilizarlas he tardado un rato en recordar cómo iban, así que aquí lo dejo apuntado por si es útil para alguien:

output = Regex.Replace(input, @"\s+", " ");

Y hemos cambiado trece líneas del código original por sólo una.

\s detecta espacios en blanco (dependiendo del motor de expresiones regulares, suele ser blancos, tabuladores y saltos de línea por ejemplo).

+ indica que hay una o más repeticiones del elemento precedente.

Recordad que la clase Regex está en:

using System.Text.RegularExpressions;

Más información en la wikipedia, claro.