Blog de Eugenio Serrano

Debido a una pregunta que me hizo mi amigo Ezquiel Jadib, de como se traduciria una linea de C# a Visual Basic me he decidio a escribir esta entrada ya que casi no hay informacion al respecto.

La pregunta que me hizo mi amigo es muy simple:

¿ Cómo se traduce esta linea de codigo de C# a VB.Net, teniendo en cuenta que i1 e i2 son interfaces ?

bool result = (i1.GetType() == i2.GetType());

Yo le dije rapidamente, pues asi…

Dim result As Boolean = (i1.GetType() Is i2.GetType())

A lo que me respondio tambien muy rapidamente.. Jeje, ya lo probe, no compila…

Y efectivamente no compila debido a que el metodo GetType se hereda de System.Object, pero las interfaces no tienen dicho metodo, y las variables i1 e i2 estan declaradas como interfaces no como clases.

Recordemos que por otro lado se puede usar la Insturcción GetType ( type ) pero, es para obtener el tipo de un tipo y no de una variable.

La cuestión es que despues de probar un poco encontramos que haciendo un Cast la cosa funciona:

Aqui hay un ejemplo completo:

Public Interface IFoo1
   Sub Foo1()
End Interface

Public Interface IFoo2
   Sub Foo2()
End Interface
    
Public Class Foo1
   Implements IFoo1
   Public Sub Foo1() Implements IFoo1.Foo1
   End Sub
End Class
 

 Public Class Foo2
   Implements IFoo2
   Public Sub Foo2() Implements IFoo2.Foo2
   End Sub
End Class
   Y luego…
 

Dim a As IFoo1 = New Foo1
Dim b As IFoo1 = New Foo1
Dim c As IFoo2 = New Foo2

If DirectCast(a, Object).GetType Is DirectCast(b, Object).GetType Then
   Debug.WriteLine(“A Implements the same interface that B”)
End If
If DirectCast(a, Object).GetType IsNot DirectCast(c, Object).GetType Then
   Debug.WriteLine(“A Doesn’t implements the same interface that C”)
End If

Hoy he recibido un mail por parte de Microsoft donde me informan que he sido reconocido nuevamente como MVP (Profesional muy valorado), por mis colaboraciones a la comunidad durante el año 2006.
Es la cuarta vez consecutiva que recibo este premio y mentiría si diría que no me llena de alegria y orgullo este reconocimiento por parte de la empresa mas importante de software del mundo. Si quiere conocer mas sobre el programa MVP, haga click aquí:

http://mvp.support.microsoft.com/Default.aspx

Y aqui 2 excelentes posts en castellano de mi MVPLead Fernando Garcia Loera donde explica que es ser MVP y como hacer para intentar ser uno:

http://blogs.msdn.com/mvplead/archive/2005/10/31/487534.aspx

http://blogs.msdn.com/mvplead/archive/2005/11/08/490532.aspx

Saludos,
Eugenio

Aprovechando para pulir los últimos de detalles antes de liberar la versión final de Cooperator Framework, estuve estos días optimizando un proceso que ya tenemos en producción desarrollado sobre nuestro Cooperator y que lee y escribe intensivamente en la base de datos.

Para la optimización use estas 3 herramientas.

1) SQL Profiler: Con el pude ver las conexiones abiertas por la aplicación, a que Stored Procedures estaba llamando en cada caso, cuantas lecturas/escrituras se hacian en cada operación, etc.… Ver más.

2) CLR Profiler: Es una herramienta que básicamente chequea como  actua el Garbage Collector y como es el ciclo de vida de los objetos dentro de nuestra aplicación. Muy buena, también me permitió ver que objetos tenía mas cargados, que tipos eran más usados, etc.. Ver más.

3) Enterprise Performance Tool: Aunque no funciona del todo bien en Windows Vista, la utilicé para “medir”, cuales son los métodos que más tardan en ejecutarse, cuales son los métodos más llamados, etc.. Ver más.

Recomiendo revisar los procesos con esas 3 herramientas ya que se puede ajustar muchísimas cosas que de otra forma no se pueden ver. Yo en mi caso, ajustando tanto las librerías de clases base de Cooperator, como el código de mi aplicación logre bajar a más de la mitad el tiempo en que  se ejecutaba el proceso y a la vez consumir menos recursos.
Por ejemplo con la herramienta de rendimiento de Visual Studio 2005, me di cuenta que estaba llamando más de 1.000.000 de veces a un determinado método. Bueno después de cambiar algunas cosas logre reducir notablemente ese caso particular poniendo una colección en un diccionario de generics y preguntando si tal objeto estaba en el diccionario… Es impresionante como caminan los diccionarios en .Net 2,0 ! 

Saludos,
Eugenio

¿ Usted cree en las brujas ? Hay algunos dias que me hago esa pregunta …

Les cuento de un error de por más interesante que me estaba dando una aplicación que lee y escribe datos intensivamente sobre una base de datos SQL Server y que me motivó a escribir esta entrada en mi blog.

Es un error súper extraño y gracioso a la vez. Antes que nada, mostremos el stack del error:

Stack Trace
   at System.Data.SqlClient.SqlTransaction.Zombie()
   at System.Data.SqlClient.SqlInternalTransaction.ZombieParent()
   at System.Data.SqlClient.SqlInternalTransaction.CloseFromConnection()
   at System.Data.SqlClient.TdsParser.Deactivate(Boolean connectionIsDoomed)
   at System.Data.SqlClient.SqlInternalConnectionTds.InternalDeactivate()
   at System.Data.SqlClient.SqlInternalConnection.Deactivate()

¿¿¿¿ System.Data.SqlClient.SqlTransaction.Zombie() ????
Pues sí, y sinceramente jamas habia visto este error ni nada parecido !!

Está bien que era sábado cerca de las 12 de la noche, pero el Zombie en ese caso debería ser yo y no tenía porque serlo ADO.Net, a no ser que las brujas existan… 

Lo peor de todo esto es que este error sucedía solamente cuando compilaba mi aplicación en Release y no en Debug !
Con Debug funcionaba todo perfectamente tal cual estaba programado.

En otro caso, aleatoriamente me daba: referencia no establecida a instancia de objeto.  Empecé entonces a revisar todo el proceso paso a paso para ver si mis objetos eran Thread Safe, si mis colecciones están trabajando correctamente, etc.. Pero como en Debug la aplicacion funcionaba correctamente era evidente que por mas que me pase horas y horas recorriendo paso a paso mi aplicacion no iba llegar al problema.
Busqué el error del “Zombie” en internet y prácticamente no encontré ninguna información acerca del mismo, y en la ayuda nada de nada…
Termine apagando mi equipo y me fui a hacer un poco de vida familiar antes de irme a dormir.

Hoy domingo mi pequeña hija me despertó tempranito y aproveche para ponerme a estudiar el misterioso caso del Zombie que tenía en mi Pc.

Después de un par de horas de revisar mi código buscando sin éxito algún problema me puse a revisar las opciones de compilación de cada proyecto ya que era muy extraño que en Debug funcionara y en Release no.
Al fin encontré como solucionar el problema, y era que en Release, uno de mis ensambles tenía en la opción Generar Información de Depuración = None, mientras que otros tenían pdb-only.  En Debug esto es por defecto Full.

¿ Conclusión que saco ?

Hay que usar para todos los proyectos que forman parte una aplicación la misma configuración avanzada de compilación. Esto es: None para todos, ó pdb-only para todos, ó Full (Debug) para todos, ya que de lo contrario obtendremos resultados inesperados.

Bueno, con eso mi aplicación quedó andando (y muy rápido), pero si alguien me puede explicar este extraño comportamiento se lo agradeceré….

Aquí paso las ventanas tanto en Visual Basic como en C# de cómo cambiar esta configuración.