Hoy fué un día de los que empiezan mal... Me levanto con una contractura en el cuello, miro el reloj ... "weno, voy sobrado para llegar al Hands-On lab de WPF..." (11:00), subo al coche introduzco la dirección que Google Maps me había dado para el Palacio Municipal de Congresos Campo de las Naciones ... tardo 10 min en coche, genial... llego a un recinto ferial y le pregunto al de seguridad y me dice ... "Eso chaval... esta en la otra punta de Madrid" ... WTF!! .. prosigue "habeis venido muchos esta mañana, vienes por una conferencia de Microsoft, verdad?" ... Pues si, Google Maps me ha colado un gol digno del Fail Blog :

Mas...

En mi anterior entrada hablaba sobre como crear enlaces en SendTo y preparar nuestra aplicación para recibir los nombres de los archivos seleccionados. He de confesar, que desde que uso XP x64 y VS2008 tengo varios problemas con los instaladores MSI que genero con VS, asi que estoy esperando a que pasen los TechDays para ponerme a instalar XP normal ..., el caso es que elaborando dicho artículo no pude probar correctamente la parte de instalación ya que, literalmente, aparecia un error de acceso a memoria un poco chungo cuando le daba a "Install" desde el VS, poco después me dí cuenta de que el error no aparece al ejecutar el .msi directamente y me dí cuenta que la manera de generar el enlace en la carpeta SendTo no funciona!!

Mas...

Si desarrollamos una aplicación que manipule archivos puede ser útil disponer en el menu contextual "Enviar a" (SendTo) un enlace que permita enviar los archivos seleccionados directamente a nuestra aplicación trabajar con ellos. Esta es la típica cosita facilona y que lleva 5 minutos pero que resulta extremandamente útil cuando lo que desarrollamos es una herramienta de uso cotidiano.

Los elementos SendTo se encuentran en la carpeta %homepath/SendTo% de cada usuario, pero explicaré como añadirlo directamente con el instalador de nuestra aplicación.

Mas...

Imagina que tu servicio necesita de otro servicio para cumplir su función, supongamos que el servicio 'a' necesita del servicio 'b'. Si yo reinicio 'b' ... 'a' es posible que pierda la conexión ... aparezcan errores ... e incluso pudiese darse el caso de quedar funcionando pero inconsistente, otro problema es que puede ser que al arrancar la máquina 'a' arranque más rápido e intente conectar a 'b' de forma infructuosa ... con las consecuencias que ello acarreé (que no deberían ser muchas si has pensado en "cuando las cosas no salen como deberían" cuando lo desarrollaste).

Para solucionar este problema de forma elegante están las dependencias de servicio.

Mas...

Puede ser... que el cifrado del archivo de configuración de tu aplicación no se adecue a la solución que buscas... puede ser... que necesites cifrar cadenas concretas en un archivo... en una base de datos... mandar eMails cifrados a tu novia/mujer/amante...  lo que sea...

Estas dos funciones, basadas en el ejemplo de este artículo con algunas modificaciones, cifran y descifran un String con el algoritmo simétrico Rijndael y con una palabra clave que se pasa como SecureString (¿Por qué?). De esta forma, podemos cifrar/descifrar un texto/cadena mediante ese password.

Necesitamos estos namespaces adicionales:

using System.IO;

using System.Security;

using System.Security.Cryptography;

using System.Runtime.InteropServices;

Mas...

Aquí va un pequeño How-to rápido de como se crea e instala un servicio Windows con .NET y Visual Studio 2005 dedicado a mi compañero Juanma Otero que a cambio me explicará como funcionan los EndPoints de SQL Server :D

Cada vez que vayamos a crear un servicio Windows, podemos seguir estos pasos para crear lo que sería el contenedor y su capacidad de instalación, para luego más tranquilamente empezar a introducir la lógica y funcionalidad del negocio que le queramos dar.

Mas...

Buff... cuanto tiempo desde mi último post, entre estudiar y la medio-gripe que arrastro desde hace unas semanas no tengo ganas tiempo de nada :P

Un tema que siempre me ha parecido que se deja un poco olvidado a la hora de desarrollar una aplicación es el tema de las excepciones, su flujo, su registro y como afectan al diseño y modularidad de la aplicación.

Una excepción, es un error en el flujo lógico ideal de nuestra aplicación causado por una condición inusual. Ante un error de este tipo, debemos actuar para corregirlo y/ó recuperar un estado consistente ó registrarlo en algún lugar(archivo log, EventLog, ..etc..) donde el administrador pueda ver que ha sucedido y tomar medidas. Esto es algo bien sabido por todos, pero el problema viene cuando hay que decidir que hacer con las excepciones que no podemos solucionar y como registrar de forma descriptiva el problema para poder solventarlo.

Mas...

Siguiendo con el el artículo anterior de la memoria en .NET donde explicaba como esta estructurada, sigo con las variables, que en .NET principalmente son de dos tipos:

• Tipos por valor:

•  
  • Se conoce su tamaño antes de su inicialización, el más grande tiene 16 Bytes.
  • Heredan de System.ValueType y ninguno puede ser extendido (sealed)(ni siquiera ValueType).
  • Se almacenan en el thread stack cuando son variables locales y expresiones intermedias, y en el managed heap en el resto de situaciones (variables globales ó/y estáticas).
  • Las estructuras (struct) y enumeraciones (enum) son tipos por valor también y responden al mismo comportamiento.
  • La memoria ocupada por estos tipos se elimina en cuanto están fuera de ámbito en caso de estar en el thread stack, y por medio del GC cuando estan en el managed heap (desapareciendo junto con la clase a la que está asociada). 

 Mas...

Con este, quiero empezar una serie de pequeños artículos sobre como esta estructurada la memoria en .NET, sin profundizar en demasiados detalles... pero empezar por lo más simple y acabar hablando sobre temas de sincronización, atomicidad y volaticidad pasando por el GarbageCollector, intentando aportar una información que a mi parecer, todo desarrollador debería tener en mente a la hora de programar... y que se debe conocer en profundidad para desarrollar aplicaciones multithreading. Espero que sea útil para quien lo lea y personalmente me ayude a comprenderlo mejor.

La memoria de la que hacen uso nuestras aplicaciones administradas se divide en dos partes principalmente:

Mas...

Esta clase, fruto de un fin de semana de inspiración y una semana de depurado en mis ratos libres, que no son muchos, sigue el planteamiento anterior para recorrer estructuras en arbol con múltiples hilos. Se trata de una clase abstracta que encapsula todo el mecanismo multithreading, simplemente hay que implementar un método que define como se obtienen sus hijos y suscribirse a un evento que es disparado por cada nodo.

Siempre es buena idea encapsular funcionalidades complejas de este tipo ya que:

• Permite probar la funcionalidad en otros campos.
• Permite hacer correciones de forma más sencilla. La lógica puede ser bastante complicada y no conviene mezclarla con la lógica de negocios.
• Permite su reusabilidad.

La clase utiliza un tipo genérico para que pueda adaptarse a cualquier tipo. Los nodos encontrados se envian vía evento, junto a un StringBuilder que indica su jerarquia en el arbol y cuyo separador puede ser indicado también en una sobrecarga del constructor. Además, la clase argumento del evento está implementado dentro de la clase, lo que permite que use el tipo genérico de la clase ThreadedTreeBase. Las excepciones capturadas se devuelven también en un evento, por lo que conviene comprobar si la propiedad Error es null ó no cuando evaluemos un nodo.

Mas...