sábado, agosto 02, 2003
“El trágico caso del infierno de las DLL”
La idea original era liberar en un servidor de Terminal Center (CITRIX) todas las aplicaciones corporativas de la compañía. Se revisaron las aplicaciones como actualmente están operando, y se detecto que estas tenían que ser modificadas. Esto debido a que había una concurrencia significativa de archivos. Mayormente a la hora de imprimir. ¿Porque? Básicamente porque la forma de impresión de los sistemas se base en abrir un archivo excel o word (según sea el caso), modificar el documento con los datos requeridos, salvar el documento como y mandarlo a impresión. El problema es que cada quien los hacia como se le antojaba, por lo que se decidió hacer un proceso estándar de impresión, y de ahí cada quien modificaría sus aplicaciones. Se liberaría y asunto terminado. Tan fácil que es la cosa.
Así, cada uno de los responsables de un equipo, se dio la tarea de modificar sus respectivas aplicaciones, en lo personal me tocaron 7 , todas en visual Basic 5 , tarea sencilla. Pasamos por alto los por menores de análisis, programación, etc, etc. Y nos pasamos a lo bonito del asunto.
Total que todos los responsables terminaron sus respectivas aplicaciones, yo termine mis aplicaciones antes que nadie, esto es debido a que solo estaba dedicado a ello, y me valí de 3 recursos externos. Liberamos en el ambiente CITRIX, hice las pruebas respectivas de liberación, y chan, chan, todo perfecto. La mayoría fue terminando después, y algunos hicieron sus pruebas unitarias en servidores de Desarrollo.
Se entregaron los instaladores a Calidad, y ahora si, empieza el proceso de pruebas de calidad
Oh sorpresa que nos llevamos algunos. Iniciaron los problemas, instaladores no tan actualizados, Eso fue lo menos critico, empezó el tétrico y fantasioso infierno de las DLL. Antes que nada, déjenme decirles que las aplicaciones que se iban a liberar son de dulce, de chile y de manteca. Visual 3, 4, 5 y 6.
Primera zancadilla, algunos tenían una versión de RDO 1.0 del año del 95 otros, más actualizados (¿???) Tenían la del 97. Y empieza la tronadera de aplicaciones. En realidad, eso fue lo más sencillo, debido a que éramos pocos los que usábamos esta versión, así que se decidió hacerla en la mas viejita por cuestiones de funcionalidad.
La segunda zancadilla sucedió cuando repentinamente, se instalo la aplicación de ultima persona que entrego sus aplicaciones. El unísono las demás aplicaciones empezaron a tronar (nos dimos cuenta 5 minutos después porque varios estábamos haciendo pruebas). El error en pantalla decía “Error 50003”.
Quien este familiarizado con ese error, sabrá que es con una de las DLL mas comunes de windows, la OLEAUT32.dll (también ocurre con la de common controls pero este no es el caso)
Y nos percatamos que ese instalador ocupaba una versión mucho más nueva, sospechamos por ser la única aplicación que hecha en visual 6. y empiezan las discusiones, y empiezan los dimes y diretes , y empieza a armarse la rebambaramba.
Todavía estamos en periodo de solucionar este problema, y otros más. Todo gracias a maldito DLL’s HELL
Tal vez fuimos ilusos al pensar que se podían liberar todas las aplicaciones en una misma maquina o ambiente de pruebas, tal vez fuimos descuidados al no tener un ambiente unitario para instaladores, tal vez nos falta homogeneizar las aplicaciones y hacerlas en una mismo ambiente. Pero esos, son problemas internos que no les voy a contar. Ahora alzamos los ojos al cielo, soñando nuestro más preciado anhelo, estamos viendo lejanamente nuestro futuro en una sola versión de Visual. Todo dirigido a Punto NET.
Pero, aun así, no creo que nos evitemos esa maldita transición de cambio de versiones. De hecho, me pude percatar que las aplicaciones hechas en el NET Framework 1.0 no pueden abrirse en el mas reciente, en la versión 1.1.
En conclusión, somos unos ilusos al pensar que las cosas son tan fáciles como las prometieron.
La idea original era liberar en un servidor de Terminal Center (CITRIX) todas las aplicaciones corporativas de la compañía. Se revisaron las aplicaciones como actualmente están operando, y se detecto que estas tenían que ser modificadas. Esto debido a que había una concurrencia significativa de archivos. Mayormente a la hora de imprimir. ¿Porque? Básicamente porque la forma de impresión de los sistemas se base en abrir un archivo excel o word (según sea el caso), modificar el documento con los datos requeridos, salvar el documento como y mandarlo a impresión. El problema es que cada quien los hacia como se le antojaba, por lo que se decidió hacer un proceso estándar de impresión, y de ahí cada quien modificaría sus aplicaciones. Se liberaría y asunto terminado. Tan fácil que es la cosa.
Así, cada uno de los responsables de un equipo, se dio la tarea de modificar sus respectivas aplicaciones, en lo personal me tocaron 7 , todas en visual Basic 5 , tarea sencilla. Pasamos por alto los por menores de análisis, programación, etc, etc. Y nos pasamos a lo bonito del asunto.
Total que todos los responsables terminaron sus respectivas aplicaciones, yo termine mis aplicaciones antes que nadie, esto es debido a que solo estaba dedicado a ello, y me valí de 3 recursos externos. Liberamos en el ambiente CITRIX, hice las pruebas respectivas de liberación, y chan, chan, todo perfecto. La mayoría fue terminando después, y algunos hicieron sus pruebas unitarias en servidores de Desarrollo.
Se entregaron los instaladores a Calidad, y ahora si, empieza el proceso de pruebas de calidad
Oh sorpresa que nos llevamos algunos. Iniciaron los problemas, instaladores no tan actualizados, Eso fue lo menos critico, empezó el tétrico y fantasioso infierno de las DLL. Antes que nada, déjenme decirles que las aplicaciones que se iban a liberar son de dulce, de chile y de manteca. Visual 3, 4, 5 y 6.
Primera zancadilla, algunos tenían una versión de RDO 1.0 del año del 95 otros, más actualizados (¿???) Tenían la del 97. Y empieza la tronadera de aplicaciones. En realidad, eso fue lo más sencillo, debido a que éramos pocos los que usábamos esta versión, así que se decidió hacerla en la mas viejita por cuestiones de funcionalidad.
La segunda zancadilla sucedió cuando repentinamente, se instalo la aplicación de ultima persona que entrego sus aplicaciones. El unísono las demás aplicaciones empezaron a tronar (nos dimos cuenta 5 minutos después porque varios estábamos haciendo pruebas). El error en pantalla decía “Error 50003”.
Quien este familiarizado con ese error, sabrá que es con una de las DLL mas comunes de windows, la OLEAUT32.dll (también ocurre con la de common controls pero este no es el caso)
Y nos percatamos que ese instalador ocupaba una versión mucho más nueva, sospechamos por ser la única aplicación que hecha en visual 6. y empiezan las discusiones, y empiezan los dimes y diretes , y empieza a armarse la rebambaramba.
Todavía estamos en periodo de solucionar este problema, y otros más. Todo gracias a maldito DLL’s HELL
Tal vez fuimos ilusos al pensar que se podían liberar todas las aplicaciones en una misma maquina o ambiente de pruebas, tal vez fuimos descuidados al no tener un ambiente unitario para instaladores, tal vez nos falta homogeneizar las aplicaciones y hacerlas en una mismo ambiente. Pero esos, son problemas internos que no les voy a contar. Ahora alzamos los ojos al cielo, soñando nuestro más preciado anhelo, estamos viendo lejanamente nuestro futuro en una sola versión de Visual. Todo dirigido a Punto NET.
Pero, aun así, no creo que nos evitemos esa maldita transición de cambio de versiones. De hecho, me pude percatar que las aplicaciones hechas en el NET Framework 1.0 no pueden abrirse en el mas reciente, en la versión 1.1.
En conclusión, somos unos ilusos al pensar que las cosas son tan fáciles como las prometieron.
