dev \ efor monitoriza tus desarrollos .NET

Cada vez programo menos. Si bien sigo siendo una auténtica puta del teclado, pico mucho menos código que antes, digamos que mis servicios han sido reorientados hacia...buffff, no lo sé ni yo, dejémoslo estar así ;-).

Así todo, siempre he opinado que programar o desarrollar aplicaciones software (que suena mejor...) es un hábito del que ningún informático debería nunca renegar. Tod@s, algun@s durante más tiempo, otr@s con menos suerte y gloria, hemos pasado por la etapa en la que picar o tirar líneas de código a machete era nuestra labor principal, por no decir, única labor. Los que habéis pasado por el mundo de la consultoría como programadores junior me imagino que me entendéis, ¿verdad? Es la rampa de salida inicial de much@s informátic@s, su entrada al ruedo del apasionante mundo del desarrollo de software.

Por ello, aunque cada vez veo menos el splash screen de IDEs como Visual Studio o Eclipse, soy de los que intenta no descolgarse demasiado de los avances que se van dando en este campo. Quizás luego no lo ponga en práctica yo, ni siquiera llegue a instalarme ese último service pack o plugin que ha salido para hacer no sé qué historia, pero al menos, me auto-obligo a mantenerme al día en el ámbito del desarrollo de software, que con todos los cambios que hay, día sí y noche también, no es moco de pavo ;-).

Dicho esto, tras leer ayer un post sobre ALM del amigo Lobosoft que me hizo desempolvar una tarea y correspondiente post pendiente, hoy os paso a presentar uno de los últimos descubrimientos que he realizado en mis esporádicas pero intensas "rondas de vigilancia tecnológica" en el mundo del desarrollo de software": Dev \ efor. La susodicha asegura ser un plugin gratuito (aunque leo que sacarán la correspondiente versión comercial) para Visual Studio 2005/2008 que monitoriza el progreso de tu desarrollo software. Suena bien, ¿no?

Aunque no soy de los siguen a rajatabla ninguna métrica de calidad de código, en el pasado sí que he utilizado herramientas como FxCop (¡thanks titán!), que te ayudan a mejorar tu código con una serie de buenas prácticas, consejos, etc. Por eso, quizás rememorando (¿y añorando?) el pasado, esta utilidad gratuita me llamó en seguida la atención. Aseguran que este plugin mide, analiza y presenta en diferentes formatos, métricas de desarrollo de software siempre interesantes: cuánto tiempo hemos pasado con cada proyecto de Visual Studio, cuántas líneas de código hemos tirado esta semana, qué evolución sigue la calidad del código que estamos generando, etc. Las métricas de código que utiliza el plugin están basadas en Visual Studio Team System Code Metrics, por lo que parecen bastante fiables, de ahí que puedan servir para coronar a un@s y sacar los colores a otr@s ;-).

Hoy admito que no he hecho los deberes y que no he llegado ni siquiera a instalar el plugin, con lo que no os puedo dar un feedback más empírico. Hoy, como veis, simplemente quería lanzar un guante tecnológico ;-). Aún así, conociéndome cómo soy (nostálgico que de vez en cuando abre el Visual Studio 2008 para desarrollar cualquier C# CCA (Chorri-Console Application), seguro que acabo instalando el plugin y monitorizando mi propio código. ¡Qué peligro! ¿Seré productivo programando? Tranquil@s, prometo que si dev \ efor me dice que soy un pocket programmer (programador paquete), muy a mi pesar, prometo...que lo contaré, transparencia hacia los lectores 100% ;-).

Si alguien ya conoce o ha utilizado dev \ efor o herramientas de métrica de código similares, no hace falta decir que sus impresiones y comentarios serán más que bienvenidos...

SaludoX.

Si quieres estar meta-informado y volverte enfermo crónico vía RSS, suscríbete al Txoko de Lonifasiko .

Longitud máxima del path en Windows

Ser metódico y ordenado tiene sus pros y sus contras, tanto como informático como en la vida real. ¿Pros? Tiendes a tener todo bien organizadito y estructurado: múltiples niveles y subniveles de carpetas, archivos y nombres de proyecto bien descriptivos, en la medida de lo posible en inglés, ficheros readme.txt por todos los lados, confías mucho e intentas sacar el máximo partido a los sistemas de control de versiones, y un largo etc. Sin embargo, ser un poquitín maniático también tiene sus pegas:

¿Comorrr? Sí, ésta fue la advertencia en forma de messagebox que me mostró mi amigo "El Visual" hace bien poco. ¿Por qué? Por pasarme de listo largo con el path completo de un nuevo proyecto en Visual Studio 2008, es decir, con la ruta donde pretendía ubicar el proyecto más el nombre del mismo. Sinceramente, nunca antes me había ocurrido...

Como buen sabueso tecnológico que soy empiezo a ser, en seguida doy con el origen de tal limitación en un artículo de MSDN. Señoras y señores, con todos ustedes, MAX_PATH, una constante de la API de Windows que limita a 260 caracteres un path o ruta.

Por si a alguien le quedaba alguna duda, para demostrar una vez más lo cabezón que soy, no me he podido resistir a probar la repetitiva tarea de crear carpetas vía línea de comandos, hasta que la consola se ha aburrido de mí y ha dicho "¡¡¡Vale ya Miguel!!!":

Como curiosidad, comentar que el contador de palabras del Word me ha chivado que el profundo árbol creado "sólo" tiene 240 caracteres, así que queda demostrado que Windows se reserva en la buchaca unos caracteres, por si las moscas ;-).

Creyéndome a ciegas lo que dice el articulo de MSDN y sin haberlo probado (es viernes por la tarde, habrá que salir un poquito a la calle...), al parecer es posible saltarse esta estricta restricción utilizando ciertas funciones en versión Unicode, disponibles también en la propia API de Windows. Con esta puerta trasera, anteponiendo el prefijo "\\?\" a la ruta conflictiva en cuestión, se supone que la longitud del path podría aumentar aproximadamente hasta los 32.767 caracteres. ¡Casi ná! Así que ya sabes, si aún "trampeando" la longitud del path máximo te sigues pasando, el Dr. Lonifasiko te recomienda encarecidamente que vayas a mirarte, porque más que ordenado, ¡eres un auténtico path-maníaco y estás un poquito enfermo!

SaludoX.

Si quieres estar meta-informado y volverte enfermo crónico vía RSS, suscríbete al Txoko de Lonifasiko .

Taskkill, el comando asesino

Hoy martes, por ser ayer día de San Miguel (aprovecho para autofelicitarme de nuevo...), toca batallita informática. ¿Cuántas veces habéis visto en Windows el texto de "No responde" al lado de la barra de título de una aplicación? Tranqui, no os alarméis, como diría algún colega mío, eso es simplemente que la aplicación "se ha quedao perlada", un "cuelgue", lo hemos sufrido tod@s l@s usuari@s güindoseros alguna vez. ¿Os suena verdad?

Como usuarios conocedores del entorno que somos ;-), en estos casos es cuando pulsamos de forma simultánea (y de mala leche) las teclas Control+Alt+Suprimir (yo utilizo Control+Shift+Escape, es más directa) para ir al "Administrador de tareas" de Windows. Una vez allí, seleccionarmos la tarea o programa "conflictivo" que no da la talla y ¡zas, finalizar tarea! Quien más quien menos, cualquier usuario de nivel medio-avanzado que utiliza Windows ha tenido que hacer esto alguna vez. Y si me apuráis, los hay maniáticos como yo que acuden directamente a la pestaña "Procesos" del "task manager" y por rapidez, como ya conocen el nombre del proceso a matar, lo seleccionan de la lista y se lo cargan sin piedad pulsando "Terminar proceso":

En cambio hoy, mi PC tenía el día tontito, tan tontito que no me dejaba terminar de ninguna de las formas anteriormente descritas con un proceso de ésos que se ha quedao perlao. Lo he intentado por activa y por pasiva, pero ni caso, la aplicacioncilla que quería aniquilar seguía vivita y coleando:

Con mi furia a punto de estallar, busco (en inglés) en el buscador que hace poco cumplía diez años (¡cómo pasa el tiempo!) y voy a dar con un post que habla del comando taskkill, y de seguido, accedo a la referencia oficial del comando taskkill. "¡Qué grande! Justo lo que necesito..." he pensado (inocentemente) para mis adentros. Raudo y veloz, abro una ventana de línea de comandos (Inicio-->Programas-->Accesorios-->Símbolo del sistema ó Inicio-->Ejecutar-->Teclear cmd y pulsar Intro), y tecleo taskkill /? para ver la ayuda de este comando interesante:

Como la aplicación perlada es una aplicación un poco "especialita" que hace uso de los puertos USB y a su vez de otras librerías de más bajo nivel, he pensado que quizás convenía forzar su terminación con el parámetro "/F" (¡para qué andarse con chorradas!) y terminar también cualquier aplicación dependiente, que para eso tenemos el modificador "/T".

Al igual que vosotros, yo también he esbozado una sonrisa murmurando "¡qué fácil!". Por el mensaje de la pantalla anterior pensaréis que he podido matar el proceso sin problemas, ¿a qué sí? Pues tengo que deciros que no ha sido así ya que la aplicación de marras seguía perlada, pero vivita y coleando, es decir, seguía ejecutándose "algo" en Windows. He pensado que habría hecho algo mal, así que he probado varias cosas: indicar el identificador de proceso con "/PID", terminar primero con su proceso padre y mil cosas más:

Por mucho que los mensajes eran de éxito, ná de ná, allí seguía ejecutándose la muy.... con las esperanzas que había puesto yo en el taskkill, siento decir que me ha defraudado bastante ya que no he podido terminar de ninguna manera la maldita aplicación que se me había quedado perlada. He probado a cerrar sesión y volver a entrar, pero allí seguía la aplicación con el cartelito de "(No responde)" por bandera. Así que no me ha quedado otra que resignarme, tragarme todo mi orgullo informático y reiniciar la máquina. De auténtica traca...

Así que el día de hoy ha tenido dos conclusiones, una positiva y otra negativa: empezamos por la positiva reconociendo que el comando taskkill es bastante potente para terminar procesos de forma rápida desde la línea de comandos, sobre todo cuando no responden ni de coña. Significar que sólo está disponible en las versiones "Professional" de los sistemas operativos Windows, es decir, no viene por ejemplo en el Windows XP Home Edition que tiene mucha gente en casita. No sé cómo va el tema de las versiones en Windows Vista, yo os aseguro que Windows XP Professional dispone de este comando.

Sin embargo, la conclusión negativa de hoy ha sido que no he sido capaz de terminar dicho proceso con este comando. Tengo la sospecha de que ha sido por utilizar directamente el parámetro "/T" que indica que dicho proceso tiene dependencias, cuando realmente era este proceso quien dependía de otros, concretamente de su proceso lanzador, Visual Studio en este caso. En fin, que no sé qué ha pasado con esta aplicación en concreto, pero por las pruebas que he realizado a posteriori, taskkill me ha parecido super útil. Por cierto, al igual que hace el "task manager", existe un comando "amigo de taskkill" que muestra los procesos que corren actualmente en nuestro PC, con su PID, memoria que están consumiendo etc. El comando se denomina tasklist:

¿Conocíais este comando de Windows? En cuanto a los linuxeros, ¿qué comando utilizáis para matar/terminar procesos de forma abrupta?

Actualización 01/10/2008: Me acaba de volver a pasar, se me ha vuelto a perlar la aplicacioncilla con la que estoy trasteando y la opción gráfica de "Finalizar tarea o proceso" no chuta. Esta vez, con la intención de hacer las cosas bien, primero he intentado utilizar taskkill /F /T /IM devenv.exe para ver si matando el proceso del Visual Studio, de paso mataba a su proceso hijo, la maldita aplicación "tocapelotas". Pues comentaros que tampoco funciona, así que debería cambiar el calificativo de "comando asesino" por el de "comando homicida imprudente". Mecagüen la leche, lo que más me jode es que tengo que volver a reiniciar....

SaludoX.

Si quieres estar meta-informado y volverte enfermo crónico vía RSS, suscríbete al Txoko de Lonifasiko .

CsharpRepl, shell interactivo de C#

Tras la dura resaca de mi primer cumpleaños (¡que joven que soy!), hoy lunes "de empanada monumental" toca hablar sobre las andanzas de l@s imparables chic@s de Mono, que como siempre, están que no paran. Una vez más me entero de una excelente utilidad/herramienta gracias a mi habitual lectura del blog más tirano de la blogosfera opensource .NET. Esta vez, el project leader Miguel de Icaza nos daba a conocer la utilidad CsharpRepl, que viene a ser una especie de shell interactivo de C#. En otras palabras, una parte del compilador de C# de Mono que nos permite evaluar expresiones y ejecutar sentencias contra el runtime de Mono a través de la línea de comandos.

Puede que esta utilidad no sorprenda a los habituales de ciertos lenguajes de scripting; ni tampoco a los "comodones" como yo que utilizamos Visual Studio como herramienta de desarrollo, ya que este entorno integra la siempre útil ventana de "Inmediatos", que viene a ser más o menos lo mismo que CsharpRepl. ¡Qué de alegrías nos ha dado esta dichosa ventanita y cuántas veces ha evitado que tengamos que recompilar nuestra aplicación! Aunque parezca increible, todavía hoy en día hay muchos programadores que desconocen las maravillas que encierra esta ventanita mágica que traga con (casi) todo. Es un "must-try" pero mucha gente no la conoce porque inexplicablemente viene oculta por defecto dentro de Visual Studio, ¡hay que activarla a mano! Manda huevos...

Bueno, volvamos al tema que nos ocupa, que no es otro que CSharpRepl, el shell que te evitará hacer debug 178 veces. Disponible ya en los nightly builds de Subversion a partir del día 1 de Septiembre, el comando csharp que habilita este shell vendrá ya integrado en la versión 2.2 de Mono. Aunque el equipo está abierto (como siempre) a todo tipo de sugerencias de funcionalidad a incorporar a la utilidad, de momento el shell publicado permite cargar assemblies, importar namespaces, evaluar expresiones más o menos complejas, utilizar LINQ a machete e incluso escribir pequeños programitas de varias líneas gracias a la edición multi-línea:

Admito que empezar a realizar pruebas con Mono sigue siendo una de mis asignaturas pendientes para la nueva temporada 2008/2009, pero seguro que con este tipo de utilidades y herramientas con las que nos deleita muy a menudo el equipo de Mono, mi pas(it)o al lado oscuro será algo más indoloro. Ya que estamos, para no olvidarme de mis promesas y objetivos de cara a la temporada 2008/2009, voy a empezar a utilizar CSharpRepl desde ya mismo:

csharp> var goals = new string[]{"write quick and better posts", "write posts frequently", "increase readers", "a more professional look & feel blog", "earn some money"};

csharp> goals.Add("test Mono");

Mono Team, thanks again for your time and effort.

SaludoX.

Si quieres estar meta-informado y volverte enfermo crónico vía RSS, suscríbete al Txoko de Lonifasiko .

Proyectos de instalación al rescate

¿Cuántas veces hemos desarrollado una aplicación que en nuestro PC funciona perfectamente y al llevarla al PC de al lado (no digo ya llevarla al PC del cliente...), pega un pete brutal? A mí y a otros compañeros míos nos ha pasado en innumerables ocasiones. Sí, aunque somos muy bueno@s programando ;-), de vez en cuando también nos ocurren estas fatalidades.

"¿Qué librería o fichero de configuración me habré olvidado de copiar?", "¿habrá que copiar esta maldita librería bajo "Windows/System32?", "¿será necesario registrar el control ActiveX de marras con regsvr32?" Son las típicas autopreguntas que azotan la maltrecha cabeza del programador después de un disgusto de tal calibre.
Después de intentar aplastar el PC (e incluso valorar la utilización del panic mode si hay demo a la vista), normalmente el programador acude a herramientas míticas como Dependency Walker. No lo vamos a negar, es una grandísima utilidad que analiza todas las dependencias que tiene un ejecutable o librería Windows, aunque muchas veces no es suficiente para dar con la dependencia concreta que está dejando tu programming reputation a ras de suelo.
Lo siguiente en la checklist post-instalación fallida es empezar a pensar cosas raras...que si las meigas de Visual Studio...e incluso plantear que sin Visual Studio instalado en la máquina destino la aplicación nunca funcionará. ¿Comorrrr? ¿He oido bien? Esta afirmación es muy pero que muy grave, atenta contra todo proceso lógico de desarrollo de software; una cosa es el entorno de desarrollo (donde tendremos un IDE, etc.), y otra muy distinta, el entorno de producción, donde es inaceptable que haya que instalar el IDE de Visual Studio para que la aplicación funcione. Meigas, haberlas haylas, por ello, buceando por la red, uno se encuentra con historias terroríficas que cuentan que si desarrollas en C++ en una máquina con Visual Studio 2005 SP1 instalado, en la máquina en la que vaya a correr ese software es necesario instalar un pequeño runtime adicional denominado"Microsoft Visual C++ 2005 SP1 Redistributable Package", que ojo, no es lo mismo que instalar Visual Studio enterito, lo cual vuelvo a repetir, es inaceptable.

Bien, la última movida que hemos tenido no se solucionaba ni instalando este redistributable ni rezando a la Virgen de Lourdes, no había manera de arrancar aquello. ¿Cual ha sido entonces la solución final, ésa por la que quizás teníamos que haber empezado? Añadir a la solución (.sln) de nuestra aplicación un nuevo proyecto de instalación, un setup project de toda la vida:

De veras, este tipo de proyectos son muy útiles, son realmente fáciles de configurar y compilar; de hecho, la mayoría de las veces basta con arrastrar el output de tu proyecto principal (ejecutable, DLL...) al proyecto de instalación, que ya se encarga Visual Studio de arrastrar todas (o casi todas) las dependencias de dicho output. ¿Que crees que te has dejado alguna? ¿Algún fichero de configuración...? No pasa nada, añades todo lo necesario "a mano" en el proyecto de instalación y listo. Compilas el proyecto y si todo ha ido bien, verás que por defecto se genera un archivo de instalación con extensión .msi y otro denominado setup.exe. Llevar estos archivos a la máquina destino (en CD, pen-drive o lo que queráis), ejecutar el .msi y efectuar la instalación por defecto siempre será más fiable y elegante que el método por fuerza bruta. ¿Qué más quieres? Tu aplicación sube un escalón en glamour con ese aspecto profesional de la instalación en plan wizard, y tú tienes menos probabilidades de sufrir un infarto ;-).

Resumiendo este alegato de defensa en favor de los proyectos de instalación de Visual Studio: si desarrollas con Visual Studio 2003/2005/2008, sobre todo en C++, créate un setup project para realizar la instalación y deployment de tu aplicación, te ahorrará disgustos y caras de póker ;-)

Ésta es mi humilde opinión, pero ¿utilizáis vosotr@s los proyectos de instalación o sois de los que copian el contenido de la carpeta a la máquina destino por fuerza bruta y cruzan los dedos? No os cortéis, lo hemos hecho tod@s ;-).

SaludoX.

PD: Thanks Dinho...

Si quieres estar meta-informado y volverte enfermo crónico vía RSS, suscríbete al Txoko de Lonifasiko .

Project converter es la solución

Ya anticipé en mi última entrada relacionada con Visual Studio 2008 que tenía alguna que otra batalla más para contaros, pero que lo dejaba para otro día. Bien, como diría aquel: today is the day ;-).

Que conste que me parece oportuno contar esta batalla porque veo que últimamente hay bastantes desarrolladores actualizándose a Visual Studio 2008, y creo que este post puede ayudar a más de uno, o al menos eso espero. No creáis que soy vidente y veo a través de mi blog a la gente instalando Visual Studio 2008; no, no soy el nuevo Rappel, simplemente he sacado esta conclusión tras analizar las estadísticas que me ofrece diariamente Google Analytics acerca de mi blog, de las que rápidamente se extrae que la mini guía de instalación de Visual Studio 2008 que publiqué hace mes y pico es una de las páginas más vistas en la historia...de mi blog ;-). Vamos allá.

Es lo de siempre. A la hora de actualizarse a una nueva versión de cualquier tipo de herramienta, sobe todo informática, siempre hay unos pros y unos contras. En mi parte de la balanza de los pros siempre aparece la palabra "novedad" y siempre meto algo de mis ganas de probar lo último de lo último. En la parte de los contras...muchos contras tiene que haber para que yo deje de probar algo "nuevo". Si bien no había oído nada sobre la incompatibilidad de Visual Studio 2008 con .NET Micro Framework (hasta que lo probé y tuve que escribir un post...), reconozco que sí me habían avisado de ciertos problemillas en equipos de desarrollo donde se comparten soluciones y proyectos, y donde hay gente que sigue con Visual Studio 2005 y otros ya se han actualizado a Visual Studio 2008. Y es que hay de todo en la viña del señor...

La primera prueba "seria" que hice con Visual Studio 2008 fue abrir un proyecto "antiguo" desarrollado con su Visual Studio 2005:


Salta el típico asistente de conversión de proyectos al que estamos acostumbrados, la conversión se realiza con éxito, compruebo que todo está en orden, rezo, pulso F5, vuelvo a rezar y chequeo que la aplicación funciona bien; todo perfecto, como debe ser. Claro, pero ahora necesito que una colega del curro siga probando unas cosillas, por lo que le mando el proyecto y lo intenta abrir con Visual Studio 2005. Pete, me lo temía:

Ya me habían avisado en el grupo de Artalde de esta incompatibilidad hacia atrás, pero a estas alturas ya sabéis que soy un poco cabezón y un poco echao pa'lante. Siguiendo el gran consejo ofrecido por Toni Recio en el mismo thread, decidí comparar con WinDiff el fichero de soluciones creado por VS2008, y el que el asistente de conversión guarda como backup, el correspondiente a VS2005. Como podéis ver en la imagen, la diferencias son mínimas:

Así que para abrir con VS2005 soluciones y proyectos de VS2008 simples, basta con aplicar el truco del almendruco: editar el fichero de solución de VS2008, cambiar "Format Version 10.00" por "Format Version 9.00", guardar y ver si VS2005 es capaz de tragárselo. Sin embargo, la solución con la que yo estaba trabajando era un poco "especialita", así que yo no tuve suerte y admito que este pequeño tricky-hack no me funcionó. Luego me dio por comparar los ficheros de cada proyecto de la solución, los clásicos .csproj. Entonces me doy cuenta que VS2008 también mete mano a estos proyectos, de hecho, en mi caso había bastantes cambios. Esta vez me da un poco más de yuyu "editar a pelo", con lo que raudo y veloz pido auxilio a Google.

Tras sufrir varias turbulencias en la búsqueda, finalmente aterrizo en un blog donde tras explicar mi mismo problema, alguien linka a la página personal de un tipo llamado Emmet Gray. Buceo un poco por su web hasta que en seguida diviso el oasis en medio del desierto, la solución a mis problemas, la utilidad ProjectConverter, una utilidad que convierte los proyectos de VS2005 a Vs2008 y viceversa. Me la bajo, la instalo and here we go! La utilidad se integra en el menú contextual que se despliega al hacer clic con el botón derecho del ratón sobre el fichero de solución de Visual Studio:

Automáticamente ProjectConverter detecta que se trata de una solución de VS2008, con lo que muestra una pantalla para confirmar que queremos convertir la solución backwards, a VS2005:

Dejamos por si acaso la opción de realizar una copia de seguridad y pulsamos con total confianza "Convert Project". Tutto bene:

Sólo por curiosidad buceo en el directorio para ver qué ha realizado esta pequeña gran utilidad. Como se aprecia, hace un backup de los ficheros de solución y de proyecto de VS2008 y escribe v9 en ellos, mientras que genera un nuevo fichero de solución y otro de proyecto entendibles por VS2005:
Sé que tener que utilizar este tipo de herramientas cuando se quieren compartir proyectos entre miembros del equipo es un poco coñazo, pero antes que andar editando a mano los ficheros de soluciones y de proyectos, cualquier cosa, ¿o no?. A mí desde luego me ha parecido super útil. Y por cierto, he de decir que le mandé a Emmet un bug que encontré al convertir un tipo de proyecto Class Library en C++, y en pocas horas ya lo había corregido y se podía descargar la nueva versión desde su web. Vamos, que un crack...

Thanks Emmet for your time and effort! We really appreciate it!

SaludoX.

No olvides suscribirte al feed RSS para enterarte de todas las actualizaciones del Txoko de Lonifasiko

Visual Studio 2008 incompatible con .NET Micro Framework

¡Cómo pasa el tiempo queridos readers (sois ya más de 30 lectores vía RSS)! Me acabo de dar cuenta que fue hace un mes cuando escribí la mejor guía de instalación de Visual Studio 2008 de la historia de la informática ;-). Desde aquella instalación no puedo decir que le esté sacando chispas a este pedazo de IDE, ya que últimamente no programo tan a machete, pero bueno, aunque sea por amor al arte siempre trasteo algo. De hecho, muchas veces son estos auto-trasteos didácticos que tanto me gustan los que me dan y generan ideas para escribir en el blog. ¡Qué le vamos a hacer! Soy auto-didacta por naturaleza ;-).

El caso es que en los últimos tiempos venía trasteando yo con todo tipo de cosillas directa o indirectamente relacionadas con el mundo embedded. Aunque he estado bastante tiempo desarrollando para Windows Mobile, últimamente me ha dado por tecnologías todavía más embebidas, como por ejemplo, .NET Micro Framework, una de las tecnologías, junto con la robótica, a las que más éxito le auguro en los próximos tiempos. Y es que a nadie se le escapa que cada vez son más los dispositivos, de todo tipo, que nos rodean, dispositivos diminutos en cuanto a tamaño y muy limitados en cuanto a recursos. Hablo por supuesto de dispositivos y placas programables, y es aquí donde entra en juego .NET Micro Framework, ya que esta nueva plataforma de Microsoft pretende facilitar la vida a los intrépidos programadores que decidan cambiar su desktop o mobile profile por el de embedded o micro embedded developer. Yo estoy en ello, así que mientras podamos y nos dejen (muy importante...), la idea es continuar "descendiendo" hacia los infiernos el mundillo embedded.

Queda claro por tanto en estos dos párrafos la conexión entre el interés que tengo en .NET Micro Framework y la reciente instalación de Visual Studio 2008. Aunque con Visual Studio 2005 ya había trasteado con micro aplicaciones, una de las pruebas de fuego que me faltaba por realizar con Visual Studio 2008 era precisamente ésa: probar a desarrollar aplicaciones para .NET Micro Framework; crear un proyecto de .NET Micro Framework y ejecutarlo aunque sea en el emulador que trae la SDK por defecto. ¡Vamos a ello!

Extrañas sensaciones me invaden cuando abro el menú que me permite elegir la plantilla de proyecto que quiero iniciar con el Visual Studio 2008. No veo el tipo de proyecto de Micro Framework por ningún lado, cuando Visual Studio 2005 bien que me lo mostraba:

"Bueeeeno, no nos pongamos nerviosos...voy a abrir un proyecto ya existente, que seguro que tutto va bene". Cojo un proyecto que tenía bajo los proyectos de mi añorado Visual Studio 2005 e intento abrirlo con el asistente de conversión de Visual Studio 2008:

¡Error al canto! "Bueeeeno, do not panic, hay veces que estos wizards mágicos de conversión tienen problemas con algún fichero en concreto...". Pues no, esta vez el wizard tiene razón ya que el proyecto ni se ha podido cargar en Visual Studio 2008. Esto me empieza a oler a chamusquina. ¡Espera! Muy astutamente se me ocurre que todo puede deberse a no haber desinstalado .NET Micro Framework 2.5 SDK antes de instalar VS2008. ¡Manos a la obra! Desinstalo super convencido .NET Micro Framework, pego un reinicio just in case, y ejecuto de nuevo la instalación de .NET Micro Framework SDK 2.5. Todo parece ir bien hasta que...¡cataclón!

El mensaje que se ve en el primer pantallazo de los dos anteriores lo dice bien clarito: Microsoft .NET Framework 2.5 requiere Visual Studio 2005 para desarrollo de aplicaciones. "Nooooooo, que lo acabo de desinstalar...". Pues bien, ésa es la gran lección de hoy: Todo aquel que esté pensando en instalar Visual Studio 2008 y quitarse de en medio Visual Studio 2005, como yo he hecho, que sepa que con Visual Studio 2008, por el momento, no es posible desarrollar para .NET Micro Framework. Como esta incompatibilidad me pareció muy extraña, lo pregunté en el newsgroup correspondiente, donde en seguida me confirmaron mis sospechas y me dijeron que estaban trabajando en ello.

Pero como soy un poco preguntón, aprovechando que hoy he asistido al evento Windows Embedded European Tour 2008 en Arrasate y he tenido la ocasión de charlar con Dave Baker, le he tirado el mismo dardo envenenado. Cordialmente (¡gran tipo!) me ha confirmado que:

• El desarrollo de .NET Micro Framework requiere a día de hoy utilizar Visual Studio 2005 (ediciones Standard o Professional con C# instalado) .

• La próxima salida del Service Pack 1 para Visual Studio 2008 (andan ya con versiones Beta) no va a corregir esta situación.

• Se espera solucionar esta incompatibilidad con la salida de la próxima versión 3.0 de .NET Micro Framework, esperada más o menos para finales de este año 2008. Al loro con esto último, primicia de Dave Baker...
  

Ya veis las consecuencias nefastas (suena algo fúnebre) que tiene ser "el conejillo de indias tecnológico"; por querer ser el más cool y tener Visual Studio 2008, me he quedado sin poder seguir trasteando con .NET Micro Framework. Que conste que instalaré Visual Studio 2005 de nuevo para no perder de vista esta plataforma a la que le he cogido un cariño especial, y a la que le auguro un futuro prometedor en este mundo plagado de dispositivos embebidos cada vez más miniaturizados.

¡Ah! Que sepáis que tengo alguna que otra cosilla, alguna que otra issue con el Visual Studio 2008, pero esta vez con solución o hack incluído. Lo dejaré para otro día, que me da para otro post y tampoco es plan de agobiaros ahora con un post más largo que el río Amazonas ;-).

SaludoX.

No olvides suscribirte al feed RSS para enterarte de todas las actualizaciones del Txoko de Lonifasiko .

Guía de instalación de Visual Studio 2008

Soy bastante lanzado a la hora de instalar cualquier tipo de programa en mi máquina, tanto en el curro como en casa. Esta manía o actitud (o depende cómo se mire, aptitud), tiene sus riesgos, pero soy así por naturaleza, soy un early adopter que lo prueba todo; , un conejillo de indias que le hace mil y una putadas a su PC instalando continuamente versiones Beta, Alpha, CTPs y RTMs de todo tipo de herramientas y utilidades que pilla.

Esta vez en cambio, me estaba sorprendiendo a mi mismo de lo mucho que estaba tardando en instalar Visual Studio 2008, el nuevo IDE o entorno de desarrollo de Microsoft lanzado allá por finales de Febrero. Sinceramente estaba muy a gusto con Visual Studio 2005 SP1, pero claro, no vaya a ser que me quede desfasado, fuera de la onda tecnológica, y por ello deje de ser "cool, hot y amazing". Así que esta semana me he puesto el buzo, he instalado Visual Studio 2008 y se me ha ocurrido la brillante (¿?) idea de compartir con tod@s vosotr@s todo el proceso de instalación de Visual Studio 2008, plus una serie de consejillos del abuelo Lonifasiko. Tan sólo comentar que VS2005 y VS2008 pueden convivir en perfecta armonía en la misma máquina; yo, por problemas de espacio en disco (en pleno 2008...), he "preferido" desinstalar VS2005. Allá vamos:

1.- Backup de proyectos de Visual Studio 2005. Soy lanzado pero no tonto, así que con lo baratos que están los CDs y DVDs, el primer consejo es realizar un backup de todos los proyectos desarrollados con Visual Studio 2005. Seguro que no pasa nada, pero nos curaremos en salud...

2.- Despedida de Visual Studio 2005. Abrimos por última vez (quién sabe en esta vida...) el gran (sí, gran) Visual Studio 2005.


Contemplamos "su apariencia" fijamente unos minutos, cerramos los ojos, alabamos todo lo que nos ha ayudado, nos cagamos en él por las que nos ha liado, y en el nombre de todos los IDEs...amén.

3.- Lectura del archivo readme. Será que me estoy haciendo mayor y más "segurola", pero últimamente estoy cogiendo la buena manía de abrir los archivos readme.txt, readme.html, o leeme.txt que todo software trae o debería traer. Le pego una lectura rápida en la que no veo nada raro, salvo alguna issue con las SDKs de Windows Mobile 6, cosa que apunto rápidamente para desinstalar antes de proceder.

4.- Limpieza previa a la desinstalación de Visual Studio 2005. Antes de procecer con la desinstalación de VS2005, con la idea de hacer bien las cosas y de paso "hacer un poco de limpieza" y liberar espacio en disco, he echado una ojeada a la fatídica lista de programas instalados con la opción "Agregar/Quitar programas". Después de exclamar en alto "¡qué de movidas tengo instaladas!", procedo a desinstalar "todo lo relacionado con VS2005". En mi caso, entre otras cosas desinstalo ASP.NET AJAX Extensions, el plugin MySQL Tools for Visual Studio, SQL Server 2005 Everywhere Edition CTP, el plugin AnkhSvn para trabajar contra Subversion, GPS.NET for VS2005, Enterprise Library for .NET Framework 2.0 (January 2006) y Microsoft Device Emulator.

Así mismo, fiándome del readme, por si las moscas quito Windows Mobile 6 Standard SDK y Windows Mobile 6 Professional SDK. Y ya que estamos de rebajas, por el mismo precio quito Microsoft Robotics Studio 1.5, del que ya tenemos sustituto CTP (sí, definitivamente estoy enfermo...). Lógicamente, todo esto que cuento depende de lo que tenga instalado cada uno en su máquina; yo cuento MI proceso de desinstalación/instalación.

5.- Reset. ¿Por qué? Porque yo no lo hice, y tan pronto como comenzó el proceso de desinstalación de VS2005...¡sorpresa!

¡Ah sí, ya me acuerdo! Aquellos controles que instalé cuando desarrollaba para Windows Mobile. También los he desinstalado en el paso anterior, pero por lo visto han dejado "su particular huella" en el registro de Windows., o donde sea. Por eso, después de haber desinstalado muchas cosas (entre 10 y 15) ...seguro que un buen reset no viene mal.

6.- Desinstalación de Visual Studio 2005. "Definitivamente te voy a echar de menos compañero...":


Pulsamos "Aceptar" con la lágrimilla en los ojos, y tras un buen (repito, un buen) rato...

La desinstalación termina y nos avisa de que puede haber otros componentes que requieran de una desinstalación manual. Ya puestos a tunear la máquina, me cepillo MSDN 2005, Microsoft Document Explorer 2005 y Microsoft Visual Studio 2005 Tools for Office Runtime.

6.- Instalación de Visual Studio Team System 2008 Development Edition. Nombre más largo no pueden sacar no...

Decimos unas cuantas veces amén (= pulsar "Next"), configuramos la instalación (de momento nunca he utilizado Crystal Reports)...

...y tras otra larga espera (menos mal que dejé de fumar...), pantalla de "instalación ok"...

...y tras pulsar victorioso "Finish", el típico "messagebox maligno"...

...que visto lo ocurrido en el Paso 5, me "invita" a hacer un...

7.- Reset. Pues eso, ¡reset!

8.- Visual Studio 2008 ready to go! Como esta vez he decidido que de momento no voy a instalar en local la ayuda de MSDN 2008 (el que quiera, que la instale), ¡despegamos! Selecciono en mi caso "C# a muerte"...

...and ¡we're in!


9.- Tomaros una buena cerveza (o lo que queráis), que os lo merecéis, este proceso agota.

Como he dicho antes, este proceso de desinstalación de Visual Studio 2005 e instalación de Visual Studio 2008 es relativo a MI máquina. Con ello os quiero decir que si alguien sigue esta "mini guía" (por llamarla de alguna manera) y no consigue instalar ni desinstalar todo lo que quiere, le cae un rayo al salir de casa, se le rompe la máquina, o la abuela fuma, me podéis escribir un comentario diciendo que no os ha funcionado (e incluso que soy un paquete), pero en absoluto me hago responsable de nada de nada. Si es que parezco un abogado ;-)

Por cierto, espero que lo aquí contado le sirva de algo a alguien. Ésa es la intención...

SaludoX.

DOR: Debug Or Release

El mismo colega (¡suerte en tu nueva etapa campeón!) que sacaba a la luz las carencias del método String.Replace me ha vuelto a poner a prueba con otra duda existencial sobre el fascinante mundo de Microsoft .NET y Visual Studio. No sé cómo lo hace, pero al final siempre consigue que me ponga cabezón y me pique con estos "retos tecnológicos" que me plantea:

Colega: "Miguel, ¿cómo puedo saber, sin tener el código fuente, si un ensamblado .NET, bien sea un .exe o una .dll que me han pasado, está compilada en modo debug o release?"

Miguel (con cara de póker...): "Joder tío, es que te pasan unas cosas...me vienes con cada preguntita...en serio, acabas antes si escribes un libro tronco..."

Colega: "¡Ja, te he vuelto a pillar tío! No, en serio, tranqui, no te piques ni pierdas tiempo con ello, era por si te sonaba alguna forma rápida de poder saber eso..."

Como me jode no poder ayudar a un compañero con una duda que a priori parece tan sencilla y evidente. ¿Que no pierda tiempo, que no me pique? No sabes lo que estás diciendo chaval...acabas de herir mi orgullo informático hasta lo más profundo, ese orgullo friki con tintes de batalla y autosuperación que todo informático posee (aunque algunos no lo saquen a relucir). Y es que si no fuera por estas aventurillas y mini-retos, ¿qué sería de la triste vida de un informático? Vamos allá...

Mirando por Internet y todavía con el orgullo malherido, en seguida encuentro este post que explica de maravilla cómo diferenciar las versiones debug y release. Una vez más, se cumple el principio básico de todo error o duda informática: "Mira por Internet, seguro que antes que a ti le ha pasado a alguien...".

Como bien indican en ese útil post, para saber si una librería o ejecutable .NET (hablamos siempre de managed code) está compilado en modo debug o release, sólamente hace falta leer los atributos del ensamblado (librería o ejecutable) en cuestión. Fiándome 100% de lo que dicen, basta con mirar el valor del atributo IsJITTrackingEnabled; si está a true, la .DLL o el .EXE están compilados en modo debug; si está a false, se trata de una versión release.

Para leer los atributos de un ensamblado .NET (.NET assembly), tenemos varias posibilidades:

• Utilizar alguna utilidad gratuita como Reflector for .NET. ¡Qué gran utilidad!
  
• Complicarse la vida y hacerlo mediante código .NET, cargando dinámicamente la assembly en cuestión y analizando sus atributos "al vuelo".

Al no tener nada mejor que hacer en este frío y lluvioso Domingo de Pascua (¡qué triste!), y porque en el fondo soy un "batallador informático" (¿?), he cogido prestado parte del código expuesto en el post del amigo Jim, y me he currado una pequeña utilidad que a través de una interfaz gráfica muy sencilla nos dirá si un ensamblado .NET está en versión debug o release. Ésta es la apariencia inicial de la aplicación:


Si pulsamos el botón saldrá un cuadro de diálogo donde podremos seleccionar el ensamblado .NET que queremos chequear:

Y poco más...una vez seleccionado el ensamblado .NET, la utilidad nos mostrará de forma gráfica si se trata de una versión debug (como en la imagen) o release:


Indicar que la aplicación sólo funciona para ensamblados .NET, es decir, para managed code, y que tan sólo necesita tener instalado .NET Framework 2.0 en vuestra máquina (lo tendréis ya instalado...). Os dejo tanto el ejecutable, como el código fuente de la utilidad (proyecto de Visual Studio zipeado) en mi espacio de SkyDrive.

Para aquellos temerosos del malware creado por desconocidos como yo, deciros que la utilidad es totalmente inofensiva; no os va a formatear vuestro disco duro, ni va a recopilar las credenciales de vuestra cuenta de GMail; como mal mayor, la aplicación pegará un pete brutal y os dejará con la miel en los labios, sin saber si el ensamblado era debug o release; lo siguiente será cagarse en mí mil veces y escribir un comentario en el post diciendo que soy una paquete ;-). ¡Pues vale! ¡Qué le vamos a hacer! Se aceptan todo tipo de críticas y comentarios...es la dura vida del blogger informático ;-)

SaludoX.

Migrando aplicaciones .NET a 64 bits

¡Quien me iba a decir a mí que hoy lunes iba a tener ocasión de trastear con un Windows XP de 64 bits! ¿Qué pasa? Pues no, hasta hoy no lo había probado, ¿y? La diferencia con el Windows XP Professional "de toda la vida" (el de 32 bits) es que éste limita la memoria física y virtual a 4Gb, mientras que esta versión con instrucciones de 64 bits a priori sube el techo hasta los 128 Gb, con lo que si te lo propones, tienes slots y sobre todo, un buen bolsillo, puedes acabar con toda la RAM de la tienda de informática de tu barrio.

El caso es que me han encomendado probar en dicha máquina por temas de compatibilidad, algunas aplicaciones software que se han desarrollado recientemente, en especial, una aplicación Windows Forms (C# con .NET Framework 2.0) que se pelea a través de una serie de formularios contra una base de datos Access muy sencilla.

Suponía que iba a haber algún que otro problemilla, y os adelanto, que los ha habido. Seguramente será porque después de copiar todos los archivos de la aplicación al nuevo pepino no he rezado lo suficiente a la patrona de los informáticos, Santa Tecla. El caso es que según he hecho doble clic en el .exe......cataclón:

Como la aplicación trabaja contra Access a través del driver OleDB, utilizando el motor de base de datos Microsoft Jet 4.0, he pensado que simplemente tendría que registrar (con el comando regsvr32) alguna DLL o como mucho, instalar una versión de dicho motor compatible con arquitecturas de 64 bits. He ido raudo y veloz a Google, y como siempre, he respirado hondo al ver que una vez más, se ha cumplido la máxima del programador: "siempre hay alguien a quien le ha pasado lo mismo antes que a ti". Y por lo visto, la solución no era instalar una versión específica de Microsoft Jet 4.0 para arquitecturas de 64 bits (de hecho no la hay...), sino simplemente cambiar el target platform de la aplicación desde el propio Visual Studio 2005, tal y como se suele hacer con los proyectos para dispositivos móviles desarrollados con .NET Compact Framework, donde tan pronto cambiamos de PocketPC 2003 a Windows Mobile 5, como de WM 5.0 a WM 6.0.

Así que nada, empezando a digerir una nueva lección impartida por el Profesor Internet, abrimos la página de propiedades del proyecto de Visual Studio 2005, donde vemos que el proyecto está compilado para "Any CPU", la configuración por defecto para cualquier proyecto:

Pero claro, nuestro proyecto no es "cualquier proyecto", es una aplicación que ha de correr tanto en 32 como en 64 bits. ¡Ahí es nada! Pues bien, es tan fácil como desplegar la combo de target platform, seleccionar x86, guardar los cambios y compilar:

Al querer que la aplicación corra en 64 bits, más de uno (me incluyo) hubiera seleccionado ipso facto x64 en vez de x86, acción muy lógica, pero errónea. Seleccionando x86, estamos indicando que independientemente de la arquitectura y bits que tengan las instrucciones de la máquina, esta aplicación es una aplicación específica para plataformas x86, es decir, ha de correr en un entorno de ejecución gobernado por instrucciones de 32 bits. Y para ello, Windows XP Professional x64 Edition trae un emulador para x86 denominado WOW64, el cual permite correr aplicaciones de 32 bits sin problemas en una arquitectura Windows de 64 bits. ¡A tope!

Tan sólo queda copiar los archivos generados en esta compilación "especial" a la máquina destino y rezar 64 plegarias a San Blador (Santo de los programadores). Con la aplicación funcionando perfectamente sobre un Windows XP de 64 bits (lógicamente sigue funcionando para 32 bits), si vamos al task manager podremos ver que el identificador del proceso lleva la coletilla "*32", señal inequívoca de la naturaleza de la aplicación:

Una vez más, lección realmente interesante y productiva la de hoy, me voy tranquilo y muy contento a la camita. SaludoX.