26 mar 2011

Blog de MTB e Informatica

Un buen compañero hace poco inauguró su blog de Mountain Bike e Informatica. Desde aquí mi sincero apoyo, porque si algo he descubierto con Foyland es que cuesta mantener un Blog con entradas constantes, cada 'cierto' tiempo, inclusive aunque solo sea con el ánimo de mantener una referencia (bitácora) propia como lo es este blog.

De momento y desde el punto de vista informático, tiene una entrada con respecto a la metodología de desarrollo SCRUM, bastante interesante y completa. La verdad sea dicha, las otras entradas de MTB también me parecieron interesantes aunque esta disciplina/deporte no sea mi fuerte.

Mucha Suerte!

12 mar 2011

Determinando la Version del Framework

Para determinar que versiones del .Net Framework se encuentran instaladas, digamos, en nuestro servidor. Podemos hacerlo chequeando la siguiente ruta en el registro de windows:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP

aquí organizadas en carpetas nombradas como las versiones veremos las que tenemos instaladas y dentro de cada uno de las mismas encontramos la llave Version que nos diría exactamente cual version de cada uno de los frameworks tenemos instalada.



Muy útil si queremos indicarle a alguien encargado de servidores que nos diga si, por ejemplo, cuenta con la version 3.5 instalada.

Ya que estamos en esto si queremos saber si AJAX (las Web.Extensions) están instaladas, tenemos que ir al GAC a verificar que estén allí. Hay que comenzar por saber cual es la direccion de GAC: %windir%\assembly (donde %windir% es la direccion de la carpeta windows, C:\Windows en mi caso)

Aquí veremos todos los assemblies (ensamblados) registrados en el GAC junto con su version arquitectura y demas datos. Como estamos buscando el AJAX, necesitamos ubicar el assembly System.Web.Extensions, si no existe aquí entonces no esta instalado



Aqui un link de refencia para tener mas métodos de como encontrar versiones del framework instaladas, particularmente me gusto el primero javascript:alert(navigator.userAgent) el cual se puede poner directamente en la barra de direcciones del Internet Explorer.

18 feb 2011

Dessincronización del codigo?

"There is no source code available for the current location" Error que emite Visual Studio en medio del debuggueo. Se da porque se produce una desincronización entre los diferentes proyectos de una solución (entre otras razones). Si al aparecernos por primera vez le dimos en el boton "NO" Entonces Visual Studio guardará una referencia del proyecto problemático para ignorarlo las próximas veces que se debugguea, por lo que cada vez que queremos depurar ese código nos va a aparecer "There is no source code available for the current location" para desesperarnos.

Para solventar esta situación damos clic derecho sobre la Solución (NO sobre el proyecto). En "Common Properties" vamos a "Debug Source Files" y una vez ahí borramos las entradas del proyecto problemático que se encuentren en la sección inferior de la pantalla de la derecha denominada "Do not look for these source files". Esto provocará que Visual Studio no ignore las entradas del proyecto y nos permita de debugguearlo.

Finalmente mientras nos encontramos en las properties de la Solución, Nos vamos a "Configuration Properties" y dentro de esta a "Configuration" y nos aseguramos que el check "Build" de los proyectos este checkeado, lo cual le indicará a Visual Studio que estos proyectos tienen que compilarse cuando ejecutamos la solución en modo de debuggeo. Damos clic en aceptar y Generamos. Ya con esto deberíamos tener sincronizado nuestro código y el error en cuestión debería dejar de rondar por nuestra solución.

10 ene 2011

Los Zombies

Comienza a caer la noche. Estas cómoda y tranquilamente sentado en tu escritorio, ejecutando una trivial prueba de una funcionalidad que acabas de terminar. Tu último compañero acaba de salir, lo miras de reojo mientras abandona la oficina. En ese momento te das cuenta que quedas completamente solo. De pronto lo presientes, te sobrecoge una sensación extraña. Te re acomodas en tu silla, miras a tu alrededor, suspiras y te dices "no pasa nada". Te enfocas de nuevo en el monitor y das el siguiente enter para finalizar el test y... entonces sucede: salta atropelladamente desde tu pantalla directo a tus ojos. Un Zombie!
Ok, un poco dramático, pero esta basado en una historia de la vida real. Hace un tiempo se me presentó el siguiente error

This SqlTransaction has completed; it is no longer usable. at System.Data.SqlClient.SqlTransaction.ZombieCheck() at System.Data.SqlClient.SqlTransaction.Rollback()

Un Zombie molestándome a estas alturas del partido y haciendo un Rollback
Resulta que esto se produce porque en algún punto de la transacción que estamos llevando a cabo; o finalizó satisfactoriamente o ya hicimos un rollbak (o sucedió algún otro fenómeno "inexplicable"). Posteriormente, y muy probablemente debido a un fallo en nuestra implementación (quizás en el manejo de errores), volvemos a invocar el rollback sobre la transacción que, como dijimos antes, por una u otra razón ya fue finalizada.
Nuestra implementación del Rollback probablemente fuese similar esto:
    trn = con.BeginTransaction();
    try
    {
         ...
         //Lógica de la transacción
         ...
         trn.Commit();
    }
    catch(Exception ex)
    {
         ...
         //instrumentalización del error
         ...
         trn.Rollback();
    }

Si la transacción ya ha sido finalizada (por alguna situación en la lógica de la misma) e invocamos la linea trn.Rollback();, entonces se producirá el error en cuestión. Para paliar este tipo de posibles situaciones, la recomendación de Microsoft es simplemente ubicar un try/catch para la ejecución del rollback:
    trn = con.BeginTransaction();
    try
    {
         ...
         //Logica de la transaccion
         ...
         trn.Commit()
    }
    catch(Exception ex)
    {
         ...
         //instrumentalización del error de la transacción
         ...
         try
         {
              transaction.Rollback();
         }
         catch (Exception ex2)
         {
              ...
              //instrumentalización del error del Rollback
              ...
         }
    }
Como aprendí no es tan difícil lidiar con zombies... Al menos por el momento...
Aquí un link con información adicional

27 dic 2010

Failed to access IIS metabase.

Estaba ejecutando una aplicación aspnet 2.0 en un windows XP (sí aun habemos personas que ejecutamos XP) y se me presentó el error: Failed to access IIS metabase.

Lo que ocurrió es que se había instalado primero el Visual Studio 2005 que el IIS, por lo que sucede es que el aspnet no esta bien registrado en el IIS. Para asegurarme de que quede bien instalado ejecuté las siguientes sentencias en el command.


aspnet_regiis -u
aspnet_regiis -i

una vez realizado ya pude ejecutar el sitio en cuestión.