El armario "ropero"

Mutex vs Semaphore

Mario Ropero — Tue, 24 Nov 2009 09:41:18 GMT

El otro día estaba leyendo y encontré un sitio que exponía algunas preguntas que hacía Google en su entrevista de trabajo y ví una de ellas y me pareció curiosa (sobre todo porque creía saber la respuesta) y era “¿Diferencia entre Mutex y Semaphore?” y como ahora estoy a ver si aprendo un poco de concurrencia y esas cosicas me dije, esta es fácil a ver si soy capaz de explicarla de una forma sencilla.

Lo primero decir es que tanto el Mutex como el Semaphore son herramientas para controlar/bloquear (el nombre correcto es sincronizar, pero vamos…) el acceso a recursos desde nuestros hilillos. Y creo que lo mejor es contar un ejemplo y no de código.

Imaginemos (o supongamos) que tenemos 3 cajas que queremos utilizar, cuando una persona viene a utilizar una caja, se la lleva y entonces sólo quedan 2 cajas, cuando ha terminado de utilizarla la deja y vuelven a quedar 3 cajas, si vienen 3 personas y cogen las 3 cajas, el próximo que venga tendrá que esperar a que alguna de las personas termine con la caja y la devuelva.

Buenos si a eso le ponemos que las cajas son recursos y las personas son hilos, eso sería, más o menos, el funcionamiento de un Semaphore con Count = 3.

Creo que es bastante sencilo, y bien la pregunta ¿qué es el Mutex?, pues la respuestas sencilla sería decir que un Mutex es un Semaphore con Count = 1.

Y listo, evidentemente esto es algo más complejo pero creo que eso sería una descripción bastante sencilla y aproximada.

Os dejo las direcciones de la documentación del msdn para que veáis ejemplos, aquí el Mutex y aquí el Semaphore

Un saludo y hasta la próxima,

Mario Ropero.

[FW 3.5] Obtener los miembros recursivamente de un grupo en directorio activo

Mario Ropero — Tue, 17 Nov 2009 20:00:00 GMT

Hola a todos, con el FW 3.5 hay una opción para recoger todos los miembros de un grupo en modo recursivo, así que ya se acabó de ir buscando los miembros del grupo y ver si tenía a su vez miembros y todo el rato lo mismo.

Es que estos chicos de .NET son muuuuuy listos. Os pongo un ejemplillo pero es sumamente sencillo.

El espacio de nombres a usar es System.DirectoryServices.AccountManagement

string nombreGrupo = "grupo";
string nombreDominio = "dominio";

using (PrincipalContext ctx = new PrincipalContext(ContextType.Domain, nombreDominio))
{
    GroupPrincipal grp = GroupPrincipal.FindByIdentity(ctx, IdentityType.Name, nombreGrupo);

    if (grp != null)
    {
        
        foreach (Principal p in grp.GetMembers(true))
        {
            Console.WriteLine(p.Name); 
        }
        grp.Dispose();
    }                
}

Y ya está, la gracia está en el GetMembers(true). Una cosa a tener en cuenta es que si el usuario que ejecuta este código no tiene permisos para poder ver un grupo dará un error de “Member not found”, así que es necesario que tenga permisos por lo menos de visualización.

Este post es corto, y creo que va a ser una serie de post para hacer cosas sencillas, porque creo que cuando estoy mucho tiempo sin desarrollar en algo, al final las cosas más sencillas o simples son las que más buscamos, o por lo menos en mi caso que soy un rato zote.

Un saludo a todos.

“Ar” Mario Ropero.

System.Transactions y concurrencia

Mario Ropero — Tue, 03 Nov 2009 10:00:28 GMT

Hola a todos, llevo bastante tiempo desconectado y es que el verano me ha sentado mal y estoy muy perruno, pero bueno vamos a ver si podemos hacer algo para remediarlo. Hace tiempo conté un problemita que me surgió con los TransactionScope y su abuso.

Esta vez el problema estaba en que un proceso hacía una operación y en un momento llamaba a un hilo en background para procesar otro trabajo, pero todo tenía que estar dentro de la misma transacción o al menos que sólo se hiciese commit si todos los procesos acababan bien.

Bueno pues ahí empezaron mis problemas, porque cuando tú creas un TransactionScope por defecto el crea una transacción (ambient transaction que se llama) y la almacena en el Thread Local Storage (lo que viene siendo el TLS) del hilo en uso y esto hace que no se propague a los nuevos hilos que se generan. Y buscando por la red encontré el whitepaper de un “peaso” de crack que ya me dijeron en su tiempo, el gran Juval Lowy y expone la solución para estos problemas.

Os lo pongo aquí, pero realmente creo que es mejor que os bajéis el whitepaper y le echéis un vistazo que no es nada pesado y la verdad explica muy bien cómo funciona todo y el LTM y bueno, clarifica bastante…

En el tema de la concurrencia, os pongo un ejemplo de la clase que se ejecutaría sobre uno de los hilos generados

public class Obrero
{
    public void Trabaja(DependentTransaction transaccion)
    {
        Thread thread = new Thread(Metodo);
        thread.Start(transaccion);
    }

    public void Metodo(object transaccion)
    {
        DependentTransaction tran = transaccion as DependentTransaction;

        Transaction antiguaTransaccion = Transaction.Current;

        try
        {
            Transaction.Current = tran;

            Debug.WriteLine("Esto tiene que estar dentro de una transacción... o algo similar :)");
            
            tran.Complete();
        }
        finally
        {
            //Liberamos la transaccion que hemos pasado y volvemos a poner la transacción a la antigua
            tran.Dispose();
            Transaction.Current = antiguaTransaccion;
        }
    }
}

Aquí lo único ha observar, es que a la clase se le pasa un objeto DepedentTransaction y es el que usa para hacer el Complete() una vez hecho el trabajo que tenga que hacer, en este caso un importantísimo Debug.WriteLine.

Desde el “padre” para invocar a esto sería un código similar a esto

using (TransactionScope scope = new TransactionScope())
{ 
    //Vamos a recoger la transacción actual y generar un dependentTransaction a través
    //del método DependentClone()
    DependentTransaction transaccion = Transaction.Current.DependentClone(DependentCloneOption.BlockCommitUntilComplete);
    
    //Aquí llamo a la clase que generar el hilo y hace otro trabajo transaccional
    Obrero obrero = new Obrero();

    obrero.Trabaja(transaccion);

    Debug.WriteLine("El papi hace cualquiero tipo de trabajo transaccional");

    //Este Complete() significa que en este instante se ejecutará el Commit de los hijos y del padre
    //debido a la opción de DependentCloneOption que está a BlockCommitUntilComplete, esto quiere decir
    //que no se hará ningún commit de los "hijos" hasta que el padre haga el Complete()
    scope.Complete();
}

Bueno aquí las cosas importantes son el método DependentClone de la transacción actual y la opción de DependentCloneOption, lo demás no es más que pasarle a la clase que hemos creado antes, la transacción generada y que trabaje sobre ella.

Las distintas opciones de DependentCloneOption

Esto es un enumerado que tiene dos opciones, BlockCommitUntilComplete y RollbackIfNotComplete.

La opción BlockCommitUntilComplete, hace que no se ejecuten los commit de las transacciones dependientes hasta que la transacción “padre” haga el Complete(), esto en la practica hace que cuando en una transacción dependiente se haga un Complete(), la transacción se marca como “lista para hacer commit” pero no se ejecuta.

La opción RollbackIfNotComplete, hace que si el “padre” ejecuta el Complete() y existe alguna transacción dependiente que todavía no haya hecho un Complete() se generará una TransactionAbortedException, y además el hilo hijo seguirá trabajando para nada porque la transacción ya está abortada.

La verdad es que esto del System.Transactions tiene bastante miga, seguiré investigando cositas que aunque es una tecnología bastante antigua ya, todavía sigue dando mucha guerra en los proyectos porque no se utiliza correctamente, y por cierto os vuelvo a recomendar a todos leeros el whitepaper de Juval Lowy que mola…

Un saludo a todos.

Mario Ropero.

Compilar en tiempo de ejecución

Mario Ropero — Thu, 08 Oct 2009 13:30:00 GMT

Hola a todos, seguro que muchos de vosotros ya sabéis de que va todo esto, pero es que es una de las cosas que más gracia me hizo cuando descubrí cómo hacerlo. Vamos a ver cómo gracias a una librería muy maja (System.CodeDom) podemos compilar en tiempo de ejecución y gracias a la reflexión (ya sabéis que es la raíz de todo mal) podemos ejecutarlo.

El uso que se le puede dar a esto es prácticamente ilimitado aunque no es tan fácil de ver (al menos en mí caso), así que me encantaría que me dijeseis para qué lo habéis usado para hacerme una idea, en mí caso yo lo tuve que usar para permitir que ciertos usuarios bastante avanzados pudieran meter validaciones complejas sobre campos y se ejecutasen al momento, vamos para hacer un generador de fórmulas y cosas así está muy bien.

Bueno os pongo un ejemplito para que veáis lo fácil que es (la verdad es que los chicos de .NET son unos tipos muy listos).

La función que genera una clase en tiempo de ejecución que tiene un método que ejecuta un “Hola Mundo!”

private object CreaYCompilaHolaMundoClass()
        {
            CompilerParameters cp = new CompilerParameters();
            cp.ReferencedAssemblies.Add("system.dll");
            cp.ReferencedAssemblies.Add("system.data.dll");
            cp.ReferencedAssemblies.Add("system.xml.dll");
            cp.ReferencedAssemblies.Add("system.windows.forms.dll");
            
            cp.GenerateExecutable = false;
            cp.GenerateInMemory = true;


            StringBuilder code = new StringBuilder();
            code.Append("using System; \n");
            code.Append("using System.Windows.Forms; \n");
            code.Append("using System.Data; \n");
            code.Append("using System.Xml; \n");
            code.Append("using System.Reflection; \n");
            code.Append("namespace Prueba.Compilador { \n");
            code.AppendFormat("  public class {0} ", "HolaMundo");
            code.Append("{ ");
            //Clases de apoyo
            //GetValue a string
            code.Append(" public void HazTuTrabajo() \n");
            code.Append("  {");
            code.Append(" MessageBox.Show(\"Hola mundo\");");
            code.Append(" }\n");           
           
            code.Append("} }");

            CompilerResults cr = CodeDomProvider.CreateProvider("C#").CompileAssemblyFromSource(cp, code.ToString());
            if (cr.Errors.HasErrors)
            {
                StringBuilder error = new StringBuilder();
                error.Append("Error al compilar: ");
                foreach (CompilerError err in cr.Errors)
                {
                    error.AppendFormat("{0}\n", err.ErrorText);
                }
                throw new Exception("Error al compilar: " + error.ToString());
            }
            Assembly a = cr.CompiledAssembly;
            return a.CreateInstance("Prueba.Compilador.HolaMundo");
        }

Lo primero importante es que necesita el using del System.CodeDom.Compiler. Luego cosas a destacar, ReferencedAssemblies son las dlls que queremos referenciar desde nuestro código generado (en el ejemplo he puesto varios aunque no se necesitan todos), en este caso no se genera una dll física si no que está compilada en memoria.

Después escribimos el código que queramos que tenga (hay que tener un poco de cuidado con las llaves de apertura y cierre) y la línea de CompilerResults….. es la importante. Después de eso se genera un Assembly (System.Reflection) y se devuelve una instancia…

Para ejecutar lo que hemos creado sería algo similar a esto

object _comp = CreaYCompilaHolaMundoClass();
MethodInfo mi = _comp.GetType().GetMethod("HazTuTrabajo");
mi.Invoke(_comp, null);

Y poco más… evidentemente esto se puede complicar lo que queramos, pasando parámetros y demás… como os dije antes se abren muchas, muchísimas puertas aunque hay veces que es complicado verle la utilidad.

Por cierto, yo no opino que usar reflexión sea malo, siempre y cuando sea usada correctamente (creo que hay muchas discusiones sobre esto pero algún día me gustaría escribir sobre ello) la reflexión mola y mola mucho.

Un saludo y hasta la próxima.

Mario Ropero.

[WCF] DataContractSerializer y la propiedad IsReference. .NET 3.5 SP1

Mario Ropero — Tue, 29 Sep 2009 18:00:00 GMT

Hola a todos, siguiendo al hilo de mi anterior post y haciendo caso a un señor que de esto sabe un rato, se puede pasar por referencia los objetillos sin necesidad de generar un behavior especial, simplemente con una propiedad del atributo DataContract.

Sigo pensando exactamente lo mismo que antes, que esto, aunque solucione muchos problemas es posible que enmascare un desconocimiento de fondo por parte de los desarrolladores del proyecto, y que las cosas dejen de funcionar correctamente porque esto está o no aplicado.

Pero bueno al lío, que esto es rápido y sencillo.

Clase que NO se pasa por referencia

[DataContract]
public class Persona
{
    [DataMember]
    public string Nombre {get;set;}

    [DataMember]
    public string Apellidos {get;set;}
}

Esto es un DataContract normal y corriente.

Clase que SI se pasa por referencia

[DataContract(IsReference = true)]
public class Persona
{
    [DataMember]
    public string Nombre {get;set;}

    [DataMember]
    public string Apellidos {get;set;}
}

Como podéis observar es mucho más sencillo ahora. Lo único es que es necesario tener instalado el SP1 del framework 3.5.

Muchas gracias a Unai por indicarnos el camino….

Hasta la próxima.

Mario Ropero.

[WCF] Vuelta a la realidad,… y jugando con el DataContractSerializer

Mario Ropero — Mon, 21 Sep 2009 12:00:00 GMT

Hola a todos!!!!, han pasado muchas semanas sin que haya actualizado el blog, de hecho ni me he acercado a él. Necesitaba desconectar y vaya que si lo he hecho… :). Pero todo se acaba, así que aquí vuelvo a soltar rollazos a troche y moche (tampoco muchos, que esto de escribir cansa…).

Uno de mis mayores problemas que he encontrado cuando se trabaja con un patrón proxy (como Remoting, WCF,…) es que mucha gente no tiene claro dónde van sus objetos y cómo se pasan los valores por referencia, por valor, etc… Y se escucha mucho eso de…”He pasado mi clase loquesea y cuando actualizo en el servidor su valor, no me lo devuelve cambiado…”

Debo deciros que a mí también me costó lo suyo (uno que es lento…), pero bueno es bastante normal que esto ocurra, y también es normal que haya formas de evitar esto, por ejemplo en Remoting había que poner explícitamente el “ref” en la variable y el se encargaba de mantener el cambio y devolverlo.

Pues estuve buscando algo similar para utilizar en WCF, y encontré que si usamos el DataContractSerializer (el serializador que se usa por defecto en WCF), tenemos una opción parecida aunque un poco más compleja de elaborar, se hace a través de OperationBehavior y decoradores de métodos.

Generamos un DataContractSerializerOperationBehavior

Creamos una clase que herede de “DataContractSerializarOperationBehavior”, este es el behavior que luego aplicaremos a través del decorador.

public class SerializadorConReferencias : DataContractSerializerOperationBehavior
   {
       public SerializadorConReferencias(OperationDescription operationDescription) 
        : base(operationDescription) 
       { }

       public override XmlObjectSerializer CreateSerializer(Type type, string name, string ns, IList<Type> knownTypes)
       {
           return CreateDataContractSerializer(type, name, ns, knownTypes);
       } 

       private static XmlObjectSerializer CreateDataContractSerializer(Type type, string name, string ns, IList<Type> knownTypes)
       {
           return CreateDataContractSerializer(type, name, ns, knownTypes);
       } 

       public override XmlObjectSerializer CreateSerializer(Type type, XmlDictionaryString name, XmlDictionaryString ns, IList<Type> knownTypes)
       {
           return new DataContractSerializer(type, name, ns, knownTypes,
               2147483647 /* En plan bruto... */,
               this.IgnoreExtensionDataObject,
               true /*Aquí esta el cambio*/,
               this.DataContractSurrogate);
       }
   }

El caso está en el último CreateSerializer al que ponemos a true la propiedad de “PreserveReferences”. Usando este serializador en vez del de por defecto ya lo tendríamos, pero queda más elegante si usamos un decorador de métodos y así decidimos los métodos que queremos que lo usen y los que no.

Generamos un decorador que extienda IOperationBehavior

Para crear un decorador debemos heredar de Attribute y además en este caso debemos implementar el interfaz IOperationBehavior para poder aplicar este behavior en la operación (Método) que deseemos.

public class ConReferenciasDec : Attribute, IOperationBehavior
   {
       #region IOperationBehavior Members
       public void AddBindingParameters(OperationDescription description, BindingParameterCollection parameters)
       {
       } 

       public void ApplyClientBehavior(OperationDescription description, ClientOperation proxy)
       {
           IOperationBehavior innerBehavior = new SerializadorConReferencias(description);
           innerBehavior.ApplyClientBehavior(description, proxy);
       } 

       public void ApplyDispatchBehavior(OperationDescription description, DispatchOperation dispatch)
       {
           IOperationBehavior innerBehavior = new SerializadorConReferencias(description);
           innerBehavior.ApplyDispatchBehavior(description, dispatch);
       } 

       public void Validate(OperationDescription description)
       {
       } 

       #endregion 

   }

Aquí lo único a destacar es que tenemos que aplicar el behavior en el cliente y en el servidor. Ahora sólo nos quedaría utilizarlo.

public interface IService
{

    [OperationContract]
    [ConReferenciaDec]
    void DoSomething(ComplexType algo);
}

Conclusiones

WCF mola mucho y se pueden hacer muchísimas cosas de una forma más o menos sencilla. En este caso en particular yo no estoy muy de acuerdo en utilizar este tipo de cosas, intento explicarme, tengo claro que la forma habitual de trabajar en .NET es que si pasas un tipo complejo a un método este siempre lo pasa por referencia, esto es cierto siempre y cuando ocupen el mismo espacio de memoria, que en el caso que nos ocupa NUNCA ocurre, porque para eso estamos a través de un proxy. Es preferible que tú método devuelva el mismo tipo y te lo pase cambiado y que los desarrolladores tengan muy clara la diferencia.

Aunque bueno para gustos los colores así que cada uno tendrá su opinión.

Hasta la próxima…

Mario Ropero…a medio gas…

CERRADO POR VACACIONES!!!!!

Mario Ropero — Fri, 31 Jul 2009 11:20:00 GMT

El armario se cierra por vacaciones, qué ilusión que me hace poder decir esto. Voy a pasar las siguientes 6 (seis!!!!!!!) semanacas descansando, intentaré aprovechar para leer algo y culturizarme un poco, pero no creo que tenga mucho tiempo para escribir, así que dejaremos la actividad por un tiempo.

Un saludo y disfrutad los que podáis.

Mario Ropero.

AYUDA : Validaciones vs Excepciones

Mario Ropero — Tue, 28 Jul 2009 08:23:00 GMT

Hola a todos, estamos en pleno periodo vacacional para algunos, otros no (nos queda poco, poco) y me ha surgido un problema, que espero que podáis ayudarme a resolver. Se refiere al tema de trabajar con validaciones o trabajar con excepciones y su rendimiento.

A la hora de desarrollar un método cuando este recibe parámetros lo “ideal” es comprobar que los parámetros que nos llegan son válidos para utilizarlos en nuestra lógica posterior, así que según dicho esto lo que yo creo como ideal, es que la primera parte de un método sería validar la entrada de los parámetros y si está todo ok, seguir adelante.

Bueno, en mi caso, la realidad es bastante diferente, en mi caso particular y “chapucero” (estoy intentando cambiar…), yo soy más de los de “try…catch” y listo y sí, debo admitir que algún catch vacío existe por mi código, aunque cada vez que lo veo digo “aghhhhhhh, mis ojos, mis ojos….”

Esto es MALO, porque cuando te llegan varios parámetros o parámetros complejos y te da un error en el catch, no tienes la certeza de saber en qué punto te ha dado, lo normal es el típico error de “Object reference not set…” y listo, ahora tienes que averiguar en qué punto se te ha ido la pinza…

En este caso está claro que lo mejor es validar la entrada y después hacer lo que tengas que hacer, pero mi problema está en el rendimiento, y pensaba que era mucho más eficiente validar que trabajar con la excepción, que costaría mucho más trabajar con una excepción que con validaciones, así que me generé un código sencillo para poder verlo.

static void Main(string[] args)
    {
      System.Diagnostics.Stopwatch sw = new System.Diagnostics.Stopwatch();
      sw.Start();
      for (int aux = 0; aux < 10; aux++)
      {
        DoSomething(null);
      }
      Console.WriteLine("Tiempo total Exception " + sw.Elapsed.TotalSeconds.ToString());
      sw.Stop();
      sw.Start();
      for (int aux = 0; aux < 10; aux++)
      {
        DoSomethingHasValue(null);
      }
      Console.WriteLine("Tiempo total HasValue " + sw.Elapsed.TotalSeconds.ToString());
      Console.ReadLine();
    }

    private static void DoSomething(int? i)
    {
      try
      {
        int local = i.Value;
      }
      catch (Exception)
      {
        Console.WriteLine("Valor de i nulo");
      }
    }

    private static void DoSomethingHasValue(int? i)
    {
      if (i.HasValue)
      {
        int local = i.Value;
      }
    }

Pues la salida de ese ejemplo es que las excepciones son un poco más rápidas que el “HasValue”, da igual que ponga 10, 100, 1000 o 10000, que compile en Debug o en Release, que ejecute dentro del Visual Studio o fuera.

Lo único que vi, es que con las excepciones en el windbg (herramienta molona) genera un montón de ruido, por otra parte normal.

Tengo varias cosas bastante claras, una es que se mucho mejor validar la entrada antes que dejar el control en un try…catch global, aunque no se por rendimiento, el mantenimiento posterior será mucho más sencillo. Otra cosa es que seguro que el código que he puesto está mal pero no consigo encontrar dónde y la verdad, me sorprendió mucho que sea más rápido capturar una excepción que hacer una validación.

Espero que podáis dedicar un tiempo y echarme una mano.

Muchas gracias a todos.

Mario Ropero.

EDITO: Gracias a un compi que ha visto el error del código que he puesto, he llegado a dos conclusiones, una soy un rato inútil por no haberlo visto antes y dos, realmente es mucho más eficiente validar antes que lanzar excepciones. Os dejo el código arreglado que lo comprueba:

static void Main(string[] args)
    {
      System.Diagnostics.Stopwatch sw = new System.Diagnostics.Stopwatch();
      sw.Start();
      for (int aux = 0; aux < 10; aux++)
      {
        DoSomething(null);
      }
      Console.WriteLine("Tiempo total Exception " + sw.Elapsed.TotalSeconds.ToString());
      sw.Stop();
      sw = new System.Diagnostics.Stopwatch();
      sw.Start();
      for (int aux = 0; aux < 10; aux++)
      {
        DoSomethingHasValue(null);
      }
      Console.WriteLine("Tiempo total HasValue " + sw.Elapsed.TotalSeconds.ToString());
      Console.ReadLine();
    }

    private static void DoSomething(int? i)
    {
      try
      {
        int local = i.Value;
      }
      catch (Exception)
      {
        Console.WriteLine("Valor de i nulo");
      }
    }

    private static void DoSomethingHasValue(int? i)
    {
      if (i.HasValue)
      {
        int local = i.Value;
      }      
    }

Gracias por vuestro tiempo.

Un saludico.

Mario.

Ejecutar un servicio de Windows en 32-bit en un Windows de 64-bit

Mario Ropero — Fri, 17 Jul 2009 06:54:00 GMT

Hola a todos, llevo un tiempo apartado de los maravillosos mundos de internés, porque estamos en fase de puesta en producción en mi proyecto actual, y ya sabéis como es eso. Muchos nervios por parte de la jefatura, se ven algún que otro látigo de siete colas, alguna que otra frase graciosa del tipo “¿Dormir? Para que necesitas dormir… a trabajar…” y cosas similares. Bueno, pues unos de los diversos cambios que se hizo fue en la plataforma y pasamos de un bonito Windows Server 2003 32 bit a su esplendido predecesor el Windows 2008 Server 64-bit. Y después de unas pruebas de concepto con la aplicación vimos que todo funcionaba incluso un poco mejor, pero…¿todo?, NO todo no funcionaba a la perfección. Teníamos un pequeño servicio de Windows que se encargaba de ejecutar unos procesillos asíncronamente que decidió dejar de funcionar.

La situación fue un poco caótica, un procesillo del que nadie se había acordado, paso a ser la prioridad número uno, vamos que se caía el mundo si eso no funcionaba. Y allí estaba yo, con un montón de jefes revoloteando a mi lado, mirando la pantalla de mi ordenador y sus smartphones viendo que el mundo se caía, y haciendo los típicos comentarios que imagino que todos hemos escuchado alguna vez “¿Ya está?”, “¿Seguro que eso es por (poned aquí cualquier cosa que paso el día anterior que no tenga nada que ver con esto)?”, “Esto tiene que estar ya”. Y yo ahí aguantando el chaparrón y el servicio sólo me decía “No encuentro la xxx.dll”, y yo… “Joé, que la dll está aquí, ¿dónde quieres que te la deje corazón?”.

Lo único que había cambiado era la plataforma, así que me dije, voy a ejecutarlo en 32-bit y a probar, y… más problemillas no tenía acceso al código para compilarlo para la plataforma x86, que sería la solución ideal, y busqué por internet y encontré una pequeña maravilla que se esconde en el Windows 2008 SDK (esta herramienta es más antigua, pero para el 2008 se encuentra ahí), la herramienta 'CorFlags.exe'.

Esta herramienta se encuentra en “C:\Program Files\Microsoft SDKs\Windows\v6.0\Bin\x64\CorFlags.exe “, y sirve para activar el modo 32BIT a un ejecutable, en mí caso el servicio.

Para ejecutarla, es muy sencillo, si queremos poner el modo 32BIT:

CoreFlags.exe Ejecutable.exe /32BIT+

Si queremos quitar el modo 32BIT:

CoreFlags.exe Ejecutable.exe /32BIT-

Y con eso todo empezó a funcionar. Y el pequeño proceso dejó de ser la prioridad uno, y todo el mundo respiró más tranquilo. Luego estuve investigando un poco más, y el problema no era el proceso en sí que puede ejecutarse en 32 o 64, era la dll que referenciaba (un proveedor de base de datos) que no estaba instalado en modo 64bit porque no existía.

Hasta la próxima.

Una de TransactionScope por favor!!!!

Mario Ropero — Wed, 08 Jul 2009 07:48:00 GMT

Buenos días a todos, no tenía pensado en escribir nada de este maravilloso elemento, pero estamos haciendo una pequeña refactorización de código porque algún DBA nos dijo que en nuestra aplicación teníamos un poco de contención con las transacciones y yo pensé “Transacciones?? Si prácticamente no las usamos”, infeliz de mí, luego hice una búsqueda sencilla por el código y aquí estoy quitando código y escribiendo sobre esto.

Lo que me he encontrado hasta la saciedad es esto

using (TransactionScope scope = new TransactionScope(TransactionScopeOption.Required))
{    
    //Acción sobre base de datos
    DoSomething.....
    scope.Complete();
}

Dónde el DoSomething es un Insert, un Update, un Delete o un Select (sí, sí… se ven cosas que dan mucho miedito), a ver…

¿PARA QUÉ NECESITAS UNA TRANSACCIÓN?, es que parece que si un insert está dentro de una transacción mola más o debe ser algo parecido, pero lo único que hace es NADA, o dar un poco por saco en todo caso.

Otro caso gracioso es poner una transacción para una sentencia de selección, joe… esa es buenísima y la he visto demasiadas veces por desgracia, ahora imaginaos una select entre varias tablas de vuestra base de datos que sea pesada y que tenga un transactionscope con IsolationLevel a Serializable (uuuuuuuuuuuuhhh escalofríos me entran sólo de pensarlo).

Otro tema son los transactionscopes encadenados, para hacer justamente eso, una acción, esto encima tiene delito porque pones a trabajar al DTC en una transacción distribuida, os pongo un ejemplito de código que me he encotrado, para que veáis:

private void Metodo1()
{
    using (TransactionScope scope = new TransactionScope(TransactionScopeOption.Required))
    {    //Acción sobre base de datos    
        Metodo2();
        scope.Complete()    
    }
}

private void Metodo2()
{
    using (TransactionScope scope = new TransactionScope(TransactionScopeOption.Required))
    {    //Acción sobre base de datos    
        DoSomething...
        scope.Complete()    
    }
}

Conclusión

Los TransactionScope están para lo que están, no para abusar de ellos porque nos pueden poner en situación bastante perjudiciales para el rendimiento de nuestra máquina, y nos pueden a llevar a bloqueos en base de datos sin quererlo. Así que se tienen que usar con cabeza y vuelvo a repetir, UNA ÚNICA OPERACIÓN EN BASE DE DATOS NO NECESITA UN TRANSACTIONSCOPE.

Perdonad por el tono del post, es que estoy muy cabreado con esto, que estoy aquí pico y pala quitando transactionscopes que me salen por las orejillas, intentaré escribir algún post con algún ejemplo más tangible.

Saludicos.

[WCF] Pasar información entre las distintas “capas” del servidor

Mario Ropero — Tue, 07 Jul 2009 06:49:00 GMT

Hola a todos, siguiendo con los artículitos de WCF, os vengo a hablar de una solución que implementamos en un cliente para pasar información a través de su parte servidora sin tener que tocar la firma de los métodos, porque había unos cuantos. Esto se implementó a través del OperationContext que nos ofrece la activación del servicio WCF y la verdad es que funciona de vicio. Pero cómo me dijo un gran crack sobre esto, hay que tener cuidado con el OperationContext porque no deja de ser una sesión de servidor, pero es finita y se sabe en qué momento se invalida y se crea. Os paso a contar el problema que teníamos…

El problema

Bueno, el problema era más o menos sencillo, en la solución implementada existían entidades de datos muy, muy, muy pesadas y obtenerlas consumía mucho tiempo de base de datos e impactaba muchísimo en el rendimiento de la aplicación. Cómo la solución tenía una sesión de servidor ya implementada (cosa que ya quitamos), pues se metió una especie de cache que se creaba cuando se iniciaba la llamada al servicio y se destruía cuando se terminaba la ejecución del servicio. Pero estaba construida de aquella manera y cuando se sometió a pruebas de concurrencia… en fin, podría haber salido mejor.

¿Qué necesitabamos?

La necesidad era poder pasar las entidades que ya se habían obtenido de un método a otro, o de una capa a otra del servidor, para no tener que volver a obtenerlas una y otra vez. La respuesta clara y más sencilla… pasemos esa información en la llamada a los métodos. Después vimos que había que tocar muchos, muchos, muchos métodos y se descartó por tiempo y esfuerzo :-(

La solución que implementamos

Un compañero muy listo que tengo me dijo “oye, mira a ver si en el contexto de operación puedes pasar información personalizada”, así que me puse manos a la obra y encontré que se puede, vaya si se puede, a través de la interfaz IExtension. La verdad es que se pasa una hashtable (nos encantan las hashtables, tenemos kilo y medio de ellas) con la información que queremos, no es muy bonito, de hecho es feote, pero funciona (esta frase es uno de los peores males en esto de la programación…).

Para hacer esto, creamos una clase que implemente la interfaz IExtension<IContextChannel>, porque queremos almacenar la información en el canal, y tenemos que implementar los métodos “Attach” y “Detach”.

Algo parecido a esto

using System.Collections;
using System.ServiceModel;

namespace TestIExtension
{
    public class ExtensionTest : IExtension<IContextChannel>
    {
        Hashtable mHash = null;

        public Hashtable Hash
        {
            get { return mHash; }
            set { mHash = value; }
        }

        #region IExtension<IContextChannel> Members

        public void Attach(IContextChannel owner)
        {
            if (mHash == null)
            {
                mHash = new Hashtable();
            }
        }

        public void Detach(IContextChannel owner)
        {

        }

        #endregion
    }
}

Pensad que en vez de una hashtable en modo cajón desastre, se puede poner cualquier tipo de información.

Para utilizar esta extensión en vuestro código, para recoger la información o para insertarla tendremos que utilizar el siguiento código:

if (OperationContext.Current != null &&
    OperationContext.Current.Channel != null &&
    OperationContext.Current.Channel.Extensions != null)
    {
        TestIExtension testExtension = OperationContext.Current.Channel.Extensions.Find<TestIExtension>();
        if (testExtension != null)
        {
            return cacheExtension.Hash;       
        }
    }

Como esta información está “viva” durante toda la activación del servicio, da exactamente igual desde que “capa” llamemos a este código porque siempre estará disponible.

Otra cosa que encontramos que estaba bastante bien, es que aunque los servicios estén en modo Single, esta información se genera en cada llamada al servicio. Cosa totalmente lógica y normal, pero bueno en esto nunca se sabe :).

Conclusiones

WCF mola!!!! y el contexto de operación está genial y se le pueden hacer mil y una perrería, pero si me queda una cosa clara es que, la información que necesite un método se le debería pasar siempre por parámetros, vamos que un método debería disponer de toda la información que necesita de forma explícita y así no llevar a ninguna confusión, esto puede no ser cierto en todos los casos, pero en la medida de lo posible la simplicidad ayuda mucho (Keep it simple!!!!).

Saludicos.

[MSBuild] Crear y depurar una task personalizada

Mario Ropero — Tue, 30 Jun 2009 11:02:00 GMT

Hola a todos, vengo a hablar de una cosa que es tan sumamente sencilla que no haría falta escribir sobre ella, pero justamente por eso vamos a describirla. Vamos a crear una task personalizada para que nuestras builds automatizadas del VSTFS las ejecuten por nosotros.

Lo primero sería deciros que las task sirven para casi cualquier cosa que se nos ocurra en nuestras build, en mi caso particular la última vez que hice una era para sustituir un fichero .bat que organizaba unos ficheros de salida y claro con el task realmente hacia lo mismo, pero era más versátil y molaba más.

Crear una task

Esto es lo más sencillo, creamos un proyecto de tipo class library (por poner un ejemplo), y añadimos las siguientes referencias:

Microsoft.Build.Framework (en mi caso la versión 3.5)
Microsoft.Build.Utilities.v3.5

Generamos una clase y la hacemos heredar de “Task” (que se encuentra en Microsoft.Build.Utilities). Realizamos una implementación del método “Execute” de la base y listo, ya tenemos nuestra task personalizada.

Quedaría algo similar a esto,

using Microsoft.Build.Utilities;

namespace TestTask
{
  public class HolaNombreTask : Task
  {
    public override bool Execute()
    {
      Log.LogMessage("Hola Mario!!!");
      return true;
    }
  }
}

Notad que no he usado el hola mundo, he usado hola Mario porque soy un poco egocéntrico (aunque me contento con poquillo)

Añadir parámetros obligatorios

Ya tendríamos el task, ahora lo ideal es pasarle algún que otro parametrillo, la forma es igual de fácil, sólo tenemos que añadir una propiedad pública y ya lo tendríamos.

Vamos a añadir un parámetro obligatorio para que se indique un nombre.

Al final el código quedaría cómo sigue,

using Microsoft.Build.Utilities;
using Microsoft.Build.Framework;

namespace TestTask
{
  public class HolaNombreTask : Task
  {
    [Required]
    public string Nombre { get; set; }

    public override bool Execute()
    {
      Log.LogMessage("Hola " + Nombre);
      return true;
    }
  }
}

Vamos a ver cómo se depura esto a través del visual studio, porque lo que interesa es que se ejecute a través de msbuild, no probar el método que vemos que es muy sencillo y no debería fallar…

Depurar task con msbuild

Necesitaremos generar un xml que pueda leer el msbuild y que haga ejecutar nuestra task. Así que creamos un nuevo fichero xml (testtask.xmldebug) con el siguiente contenido

<?xml version="1.0" encoding="utf-8" ?>
<Project DefualtTargets="Debug" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <UsingTask TaskName="HolaNombreTask" AssemblyFile = "C:\TestTask\bin\Debug\TestTask.dll" />
  <Target Name="Debug">
    <HolaNombreTask
      Nombre="Mario!!!"
      />
  </Target>
</Project>

A tener en cuenta, el tag “UsingTask” que evidentemente sirve para utilizar una task que esté en el ensamblado que le pongamos, en nuetro caso el que acabamos de generar, y poquito más, creo que está bastante claro el documentito xml.

Ahora tenemos que ir a las propiedades de nuestro proyecto, a la “pestaña” Debug y,

Marcamos la opción de “Start external program:” y buscamos el MSBuild.exe que normalmente se encuentra en %windir%\Microsoft.NET\v3.5\MSBuild.exe
Y en “Command line argumetns” ponemos la dirección dónde se encuentra el fichero xml que hemos generado, en el caso del ejemplo (“C:\TestTask\testtask.xmldebug”)
Ponemos algún puntico de parada si queremos
Pulsamos F5 y ya está…

Ya tenemos nuestra task funcionando y depurándola a nuestro gusto.

Como podéis observar es super sencillo generar nuevas task.

Un saludico y hasta la próxima.

[WCF] InstanceContextMode.Single y variables globales

Mario Ropero — Thu, 25 Jun 2009 09:10:00 GMT

Los servicios WCF (esos grandes amiguitos), tiene varios modos de instanciación (PerCall, PerSession y Single), la documentación oficial la podéis encontrar aquí, pero quería hablaros del comportamiento del single.

En mi proyecto actual se decidió cambiar la forma de instanciación de los servicios a Single para ganar rendimiento, y en un principio viendo el coste del cambio, “unas dos líneas de código”(jajajajajaja), se decidió hacerlo. Yo en un principio era un poco escéptico porque conocía como estaba construida la “casa” y en fin… tenía mis dudillas, y la verdad se nos complicó un poco el cambio, os cuento…

Un poquillo de culturilla, cuándo se instancia un servicio en modo Single, se crea una única instancia si no existe y si ya existe no se crea nada (lo que viene siendo un Singleton), esto es genial, lo que pasa es que todas las llamadas que haga ese servicio a nuevas clases realmente van a tener una única referencia y no se van a estar creando nuevas clases una y otra vez, vamos que el “new class()” realmente no tiene por qué crear una nueva instancia, si no reutilizar una ya creada. Este comportamiento, totalmente lógico, puede dar algún problema porque no es del todo explícito.

Yo hasta aquí, no le veo más que ventajas, nuestro proyecto actual tenía un montón de problemas de rendimiento porque se generaban muchas llamadas a servicios (bueno esa era una de las muchísimas razones), así que nos pusimos manos a la obra y… zas en toda la boca. De buenas a primeras los servicios no conseguían levantarse, y los que lo conseguían en unas mínimas pruebas de carga empezaron a dar problemas de concurrencia y los que no los daban no funcionaban como tenían que funcionar.

Después de los primeros momentos de pánico y miradas asesinas hacia los pobrecillos que hicimos el cambio, nos pusimos a mirar detenidamente y vimos que en nuestras clases de lógica de negocio y acceso a datos se usaban muchas, muchísimas variables globales (no, no, no…chicos malos). El “problema” es que cuando se está trabajando en un servicio en modo Single, cualquiera de sus clases que estén dentro del contexto de la llamada del servicio estarán apuntando a una única referencia y también “están” en modo single, así que a todos los efectos

public class UnaDAL()
{
    List<int> listaEnteros = new List<int>();
}

se convierte en algo similar a esto

public class UnaDAL()
{
    static List<int> listaEnteros = new List<int>()
}

Pues claro si luego la utilizas sin locks y sin pensar en la concurrencia, esto no funciona.

Conclusiones

Todos a una… “Las variables globales son malas”, aunque las generalizaciones son malas, en general no se deberían utilizar salvo en casos realmente necesarios y controlados. Y por otra parte, creo que utilizar los servicios en modo single se tiene que hacer cuándo tú aplicación lo soporta o está medianamente bien diseñada. En nuestro caso actual, estamos trabajando en ello y parece que vemos la luz del túnel y la verdad es que ahora mismo nuestras clases tienen mucha mejor forma y salud… Aunque debo deciros que los primeros momentos de pánico fueron muy graciosos…

Un saludico y hasta la próxima.

[WCF] Usar ClientMessageInspector para añadir información a las soapHeaders

Mario Ropero — Sun, 14 Jun 2009 08:56:35 GMT

Hay ocasiones que queremos pasar información del cliente al servidor, o vicerversa y no queremos cambiar la fachada de nuestros métodos, o bien porque implicaría mucho cambio, o bien porque la información que queremos transportar es una información de “estado” que no tiene sentido que esté en la fachada de nuestros métodos.

Pues esto lo vamos a poder hacer a través de los behavior de los endpoint y de los MessageInspector, que existen de dos clases, los de cliente (IClientMessageInspector) y los de servidor (IDispatchMessageInspector). Y me vais a perdonar porque no tienen que estar necesariamente en cliente o en servidor, pero este es un punto de partida.

1.- Definimos una clase que va a ser nuestro MessageInspector y hacemos que implemente la interfaz IClientMessageInspector

        1: namespace ClientInspector

       2: {

       3:     public class ClientMessageInspector : System.ServiceModel.Dispatcher.IClientMessageInspector

       4:     {

       5:         #region IClientMessageInspector Members

       6:  

       7:         public void AfterReceiveReply(ref System.ServiceModel.Channels.Message reply, object correlationState)

       8:         {

       9:  

      10:         }

      11:  

      12:         public object BeforeSendRequest(ref System.ServiceModel.Channels.Message request, System.ServiceModel.IClientChannel channel)

      13:         {

      14:             return Guid.NewGuid();

      15:         }

      16:  

      17:         #endregion

      18:     }

      19: }

2.- En el método BeforeSendRequest, es dónde tenemos que añadir información en las soapHeaders, en el ejemplo vamos a insertar un guid, pero se podría insertar cualquier cosa

       1: public object BeforeSendRequest(ref System.ServiceModel.Channels.Message request, System.ServiceModel.IClientChannel channel)

       2: {

       4:     MessageHeader<Guid> mhg = new MessageHeader<Guid>(Guid.NewGuid());

       5:     MessageHeader untyped = mhg.GetUntypedHeader("GuidToken", "gtk");            

       6:     request.Headers.Add(untyped);

       7:     return Guid.NewGuid();

       8: }

Ahora mismo tenemos definido el MessageInspector de cliente y lo que hará cuando se llame, lo siguiente es aplicarlo a través de un EndPointBehavior.

3.- Definimos un custom Behavior para que aplique nuestro message inspector, así que creamos una clase que implemente la interfaz IEndpointBehavior

       1: namespace ClientInspector

       2: {    

       3:     public class InspectorBehavior : IEndpointBehavior

       4:     {

       5:         #region IEndpointBehavior Members

       6:         public void AddBindingParameters(ServiceEndpoint endpoint, System.ServiceModel.Channels.BindingParameterCollection bindingParameters)

       7:         {

       8:         }

       9:  

      10:         public void ApplyClientBehavior(ServiceEndpoint endpoint, System.ServiceModel.Dispatcher.ClientRuntime clientRuntime)

      11:         {

      12:         }

      13:             

      14:         public void ApplyDispatchBehavior(ServiceEndpoint endpoint, System.ServiceModel.Dispatcher.EndpointDispatcher endpointDispatcher)

      15:         {

      16:         }

      17:  

      18:         public void Validate(ServiceEndpoint endpoint)

      19:         {

      20:         }

      21:         #endregion        

      22:     }

      23: }

4.- En el método ApplyClientBehavior, es dónde añadimos el MessageInspector que hemos creado en los pasos anteriores

       1: public void ApplyClientBehavior(ServiceEndpoint endpoint, System.ServiceModel.Dispatcher.ClientRuntime clientRuntime)

       2: {

       3:     ClientMessageInspector inspector = new ClientMessageInspector();

       4:     clientRuntime.MessageInspectors.Add(inspector);

       5: }

Con esto ya tendríamos el behavior listo y para aplicarlo por código, en una service reference ya creada en nuestro proyecto, tendríamos que añadirlo a la lista de behaviors del EndPoint, un ejemplo de esto sería.

       1: client.Endpoint.Behaviors.Add(new ClientInspector.InspectorBehavior());

Con estas tres líneas se puede leer la cabecera que hemos insertado. Esto se haría en la parte “servidora”

       1: //Leer información de las cabeceras

       2: //Recoger la cabecera que ha insertado el behavior

       3: if (OperationContext.Current.IncomingMessageHeaders.FindHeader("GuidToken", "gtk") >= 0)

       4: {

       5:     Console.WriteLine(OperationContext.Current.IncomingMessageHeaders.GetHeader<Guid>("GuidToken", "gtk").ToString());

       6: }

Os dejo el código fuente del ejemplito aquí.

Ya estaría, aunque faltaría un punto bastante importante, nosotros queremos hacer todo esto a través de un fichero de configuración porque no apetece nada tener que ir por el código añadiendo el behavior a cada service reference que tengamos… ¿verdad?…

¿Cómo añadir un behaviorExtension al fichero de configuración?

Bueno pues ese problema también está resuelto heredando de BehaviorExtensionElement.

1.- Añadimos la clase al ejemplito anterior

       1: using System;

       2: using System.Collections.Generic;

       3: using System.Linq;

       4: using System.Text;

       5: using System.ServiceModel.Configuration;

       6:  

       7: namespace ClientInspector

       8: {

       9:   public class InspectorBehaviorExtension : BehaviorExtensionElement

      10:   {

      11:     /// <summary>

      12:     /// BehaviorType

      13:     /// </summary>

      14:     public override Type BehaviorType

      15:     {

      16:       get { return typeof(InspectorBehavior); }

      17:     }

      18:  

      19:     /// <summary>

      20:     /// CreateBehavior

      21:     /// </summary>

      22:     /// <returns></returns>

      23:     protected override object CreateBehavior()

      24:     {

      25:       return new InspectorBehavior();

      26:     }

      27:   }

      28: }

Con esta clase ya compilada y funcionando, ya podríamos configurar el behavior en el fichero de configuración, aplicarlo al endpoint y quitar la llamada del código que hemos puesto.

Os muestro el fichero de configuración y luego os comento las entradas “especiales” (que no tienen nada de especiales) para que esto funcione. He quitado la parte del binding… porque en este caso no nos preocupa…

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <system.serviceModel>
        <behaviors>
            <endpointBehaviors>   
                <behavior name="BehaviorConInspector">
                  <InspectorExtension />
                </behavior>
            </endpointBehaviors>
        </behaviors>
        <extensions>
            <behaviorExtensions>
                <add name="InspectorExtension" type="ClientInspector.InspectorBehaviorExtension, ClientInspector, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
            </behaviorExtensions>
        </extensions>
        <bindings>
            <ws2007HttpBinding>
                <binding name="WS2007HttpBinding_ISampleService" ...>
                </binding>
            </ws2007HttpBinding>
        </bindings>
        <client>
            <endpoint address="http://localhost:8090/SampleService" behaviorConfiguration="BehaviorConInspector"
                binding="ws2007HttpBinding" bindingConfiguration="WS2007HttpBinding_ISampleService"
                contract="ServiceReference1.ISampleService" name="WS2007HttpBinding_ISampleService" />
        </client>
    </system.serviceModel>
</configuration>

Aquí las cosas que hemos cambiado son, extensions, behaviors y el endpoint de client.

BehaviorExtension

Lo primero de todo es añadir una behaviorextension que es lo que hemos conseguido haciendo la clase que heredaba de BehaviorExtensionElement (su propio nombre lo indica), eso se añade con

<extensions>
    <behaviorExtensions>
        <add name="InspectorExtension" type="ClientInspector.InspectorBehaviorExtension, ClientInspector, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
    </behaviorExtensions>
</extensions>

Behavior

Hay que añadir un nuevo behavior que tenga nuestra extension para que se ejecute el inspector, como queremos hacer

<behaviors>
    <endpointBehaviors>   
        <behavior name="BehaviorConInspector">
            <InspectorExtension />
        </behavior>
    </endpointBehaviors>
</behaviors>

Aquí además se puede añadir cualquier tipo de configuración asociada a los behavior como se hace normalmente.

Client endpoint

Lo último, y bastante importante, es decirle a nuestro endpoint de cliente que utilice ese behavior, porque si no, esto no habría valido para nada :)

Para esto, sólo hay que añadir en la configuración de cliente el atributo behaviorConfiguration = “BehaviorConInspector”.

Y listo, ya podríamos probar quitando la línea que añade el inspector explícitamente en el código y funcionaría exactamente igual

Este post se acabó….

Os dejo el código fuente con esto cambiado aquí, por si queréis comparar.

Cómo habréis podido observar, me he roto los cuernos pensando los nombrecicos así que no lo toméis muy a mal… :). Esto de meter información en las cabeceras de los mensajes mola!!!. En el proyecto actual, lo usamos para quitar una sesión de servidor (sí…es malvada y no permite escalar las aplicaciones… por eso la queríamos quitar), y la verdad es que va muy bien.

Saludicos y hasta la próxima.

Producir, producir y producir!!!!

Mario Ropero — Thu, 11 Jun 2009 17:51:34 GMT

Actualmente, estoy trabajando desplazado en un cliente ayudándoles (o al menos intentándolo) al sacar adelante su aplicación interna de gestión, el trabajo es duro y el tiempo es corto… vamos que estamos en la mejor de las situaciones que imagino que muchos de vosotros, por desgracia, conoceréis.

De ahí, el tema del “post”, en una situación como la actual lo que se pide a los desarrolladores es que produzcan, produzcan y que produzcan… y que además lo produzcan bien (bueno esto último es un decir). Para ello nos dan una herramienta maravillosa que se llama Microsoft Visual Studio 2008 y una “bonita” solución de… 200 proyectos (y sí, habéis leído bien 200 proyectos!!!).

Nosotros le hemos cogido cariño a la solución y es nuestra “bicha”, y la susodicha tarda aproximadamente 20 minutos en compilar… ¿Os podéis imaginar el tiempo que se pierde para corregir una incidencia?……… MUCHO, de hecho muchísimo… además pierdes la concentración y al final pierdes las ganas de arreglar las incidencias.

¿Cómo se ha llegado a esto?

La verdad, no tengo ni idea, yo solo pasaba por allí. Pero hay una mezcolanza de arquitecturas y de formas de dividir una solución que al final hay muchísimos proyectos, todos relacionados entre sí y hasta alguna referencia circular… (sí, ya se que Visual Studio no te deja… pero es que también usamos reflection a cascoporro… así que “si quieres, puedes”).

Yo aquí sólo diría que una vez que nos ponemos a intentar organizar una solución y todos sus proyectos, podemos hacer divisiones de ensamblados funcionalmente, o técnicamente… que podemos dividirlos por “LogicaNegocio”, “CapaDatos”, “Modelo”,…. o por “Compras”, “Proveedores”, “Clientes”… pero por favor no los mezcléis porque si no… terminaréis con una “bicha” y os aseguro que no es para nada bueno…

¿Por qué tarda tanto en compilar?

La respuesta es sencilla y tiene dos o tres puntos:

1. Son muchos proyectos

2. Los proyectos tienen muchas referencias del tipo “Proyecto” a los distintos proyectos (redundante ¿eh? :-))

3. Existe algún proyecto excesivamente grande o con un número demasiado grande de referencias

Seguro que existen muchas más razones pero estas son las que se me ocurren a mí…

¿Se podría reducir el tiempo de compilación?

Sí, y la primera respuesta que se me viene a la cabeza es… “REUNIFICANDO PROYECTOS”, aunque también se podrían poner las referencias a ensamblados previamente compilados y no tardaría mucho, o intentar redefinir los proyectos con un elevado número de referencias.

¿Tiene algún tipo de fundamento reorganizar el código en menos proyectos?

Una vez visto el problema que tenemos en la parte de desarrollo y no olvidando nunca que nuestra función fundamente es producir, producir y producir un poquito más, estuve buceando un poco por Internet y preguntando a algún que otro crá de esto de la informática y al final creo que el sentido común es lo que triunfa.

Así que es mejor tener un proyecto un poco más grande que tener cinco proyectos pequeñitos, y cuándo este número crece mucho, se hace bastante importante, porque:

1. Se reduce el número de proyectos (esto es obvio)

2. Se reduce el número de referencias

3. Se puede evitar el efecto “rebase” (esto no es muy importante cuando se tienen pocos proyectos pero bueno… algo es algo)

4. El JITTER utiliza menos tiempo

5 …

Esto viene todo de un bonito sitio que se llama “Microsoft Pattern & Practices” y bueno parece que estos chicos saben un poquillo de esto, os dejo los links que son bastante aclaradores.

http://msdn.microsoft.com/en-us/library/ms998547.aspx#scalenetchapt05_topic33

http://msdn.microsoft.com/en-us/library/ms979052.aspx

¿Conclusión?

Bueno la conclusión es sencilla… da igual de qué forma se optimice el tiempo de compilación pero es un tiempo que debería ser nulo o muy pequeño si no queremos que el ritmo de producción se vea alterado por otras causas ajenas a nuestras meteduras de pata. Yo en este cliente en particular intento reducir el número de proyectos.

Perdonad por el rollazo, este es mi primer post de lo que espero sea una larga lista de ellos, y no tengo intención de que sean de este tipo si no algo más orientado a ayudas con el código para hacer ciertas cosas, pero es que este tema me tiene comidita la moral y creo que es muy importante que nosotros los desarrolladores no nos muramos cada vez que intentemos compilar una solución.