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...

Si con MSMQ 3.0 y Windows 2003 Server SP2 se te amontonan los mensajes en las colas de Outgoing (salida)... haciendo que tarden en entregarse ó incluso que lleguen a caducar allí... antes de liarse a patadas con nada... existen diversos motivos por los que puede suceder:

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...

  Por invitación de Rodrigo Corral a partir de ahora también postearé en Geeks.ms, comunidad que sigo desde hace tiempo y que es todo un privilegio para mi colaborar en ella.

Me llamo Valeriano, actualmente vivo en Madrid, trabajo en Avanade y llevo unos dos años y medio dándole a esto del .NET con C#. Tengo especial curiosidad por la programación concurrente que espero poco a poco ir dominando, por el .NET framework y C# en general. Espero compartir con vosotros todo lo que vaya aprendiendo sobre estos temas :D

Un saludo.

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...