El RFOG ya no es lo que era…

Os cuento una histora que me ha ocurrido esta misma tarde. Aparte de emocionarme al ver el nuevo iLiad con pantalla A4 (gracias, Alfredo Novoa) y de pensar que, pese a haber corregido varios defectos (ahora lleva para pasar página en tres de los cuatro lados), supongo que la velocidad leyendo Mobipocket va a ser la misma que con el iLiad, así que paso de momento.

Bueno, ya me he ido por los Cerros de Úbeda. En fin, que la historia comienza con el cierre de una aplicación que tengo que montar mañana… En mi máquina de desarrollo se carga perfectamente, en las de prueba, también, pero creo una máquina virtual nueva a partir de la de seguridad completamente limpia (es el escenario que me encontraré mañana) y me peta en el arranque.

Como desde que los chicos de Microsoft piensan que no debemos saber qué ha petado, sino que lo mejor es mostrarnos un cuadro en el que nos diga que reinstalemos la aplicación, el que suscribe se queda a oscuras.

Bueno, no es problema. Instalo el depurador remoto, hago dos cambios en la configuración y lanzo la aplicación.

Me salta una excepción que me dice que no puede cargar un ensamblado. Bueno, deciros que la aplicación consta de un programa escrito en C# que a su vez se apoya en tres DLL nativas hechas en C++ (accedidas mediante interop de atributos), en una cuarta escrita en C++/CLI que hace de puente a una quinta, también nativa (accedida mediante interop IJW). Y finalmente un ensamblado hecho también en C++/CLI que más o menos es mi biblioteca de utilidades. Pues bien, la excepción estaba en esta última.

Vamos, un escenario algo complejo pero perfectamente «legal» dentro de la filosofía de Microsoft. Evidentemente mi primera comprobación es verificar que el ensamblado está y que se trata de la versión adecuada.

La siguiente comprobación se debe a varios bugs (yo los llamo bugs, quizás Microsoft los llame «features») de Visual Studio: Cuando uno genera ensamblados .NET desde un sistema operativo de 64 bits, el ensamblado se crea por defecto como «AnyCPU», lo que no sería ningún problema si luego ese ensamblado funcionara bien tanto en x64 como en x86. No voy a entrar en detelles, pero si arranca como «AnyCPU» todos los ensamblados no nativos han de ser «AnyCPU» o la aplicación terminará petando tarde o temprano (en general temprano, a la hora de la carga del esnamblado). O si arranca bien, hará cosas raras según se ejecute en x86 o en x64 (aunque sea bajo Wow64, especialmente bajo Wow64).

Pues bien, uno abre el «Configuration Manager» y lo deja todo en Win32 y x86… borrando las configuraciones mixtas. Claro está, esto funciona hasta que al IDE le salga de los cojones pasar hasta el culo de ti y cambie algunas opciones a x64, otras a x86, otras a Win32, te cree varias configuraciones mixtas, y use cualquiera de ellas. Ayer cerraste el IDE funcionando y hoy ya no funciona.

Vale, también miré eso: estaba todo bien, pero el puñetero programa se negaba a cargar el puñetero ensamblado porque decía que faltaba el propio puñetero ensamblado o alguno de sus puñeteros componentes… ¡Pero si está solo, si es un p*to ensamblado mixto DLL! Bueno, se negaba a cargarlo en una configuración limpia, porque en mi portátil, en el ordenador de pruebas, y en dos o tres máquinas virtuales funcionaba bien…

Abro una máquina virtual de extrangis que tengo con una copia del Visual Studio 2008. Lo recompilo todo. Lo paso a la máquina virtual y… y…

¡Joder, funciona!

La única diferencia entre mi máquina de desarrollo y esa virtual es el sistema operativo. Bueno, no realmente, había otra diferencia por la cual yo quería compilar en la real y no en la virtual. Se trata de una diferencia que luego contaré. En mi cabeza en ese momento la única diferencia posible era el sistema operativo. Pero evidentemente me negaba a que la diferencia fuera esa… No puede ser que ocurra algo así, sería la debacle y la vergüenza más espantosa de Microsoft, así que sigo probando cosas.

Copio otra máquina virtual. Reinstalo el runtime del .NET, le doy una vuelta por Windows Update, le pongo una vela, me voy al patio a gritar, lo amenazo con la recortada, me acuerdo de algunos parientes cercanos y lejanos… y nada.

Me voy a dar una vuelta por ahí. Saco la basura. Miro el cielo. Vuelvo. Nada, que no funciona…

…….

Al final, claro está, lo encontré. ¿Sabéis qué era?

EL P*TO RUNTIME DE VISUAL C++

Me explico. Al ser un ensamblado hecho en C++/CLI compilado sólo con /clr, necesita el Runtime de C++ frente a C# que en general no lo necesita. Yo eso lo sabía, y sabía que tenía instalado el runtime en la máquina virtual limpia y en todas las demás… pero ¡tenía el del Visual Studio 2008, no el del Visual Studio 2008 SP1!

Es por eso el título de la entrada: efectivamente, el RFOG ya no es el que era, ya que en primer lugar era consicente de que al Visual Studio 2008 instalado en la máquina virtual le faltaba el SP1, y, como es lógico, yo quería recompilar con el que tiene el SP1 instalado. Pero me había obcecado en que la diferencia era el sistema operativo (XP frente a Vista). En segundo lugar, es una regla grabada a fuego: los runtimes. Nunca olvides los runtimes. Y, evidentemente, hacer la conexión entre una cosa y la otra era algo trivial… si no te ofuscas como me ha pasado a mi.

Así que ya sabes, si las cosas no funcionan, relájate, tómate un café, vete a dar una vuelta, y vuelve después.

6 comentarios sobre “El RFOG ya no es lo que era…”

  1. Claro y te vas con el sentimiento de culpa…, creo que tienes el sindrome de estocolmo, pienso que, con todos los parches, utilidades, actualizaciones y otros que Microsoft saca dia a dia, es facil volverse loco, con lo facil que seria ofrecer un mensaje de error diciendo «tio te falta el runtime de c++ para que esto funcione», y luego hablan de buenas practicas en el desarrollo de software, en fin, es para descojonarse…

  2. Juan, te doy la razón como a un santo… Además, en el texto ya lo digo de forma un poco más suave: «Como desde que los chicos de Microsoft piensan que no debemos saber qué ha petado, sino que lo mejor es mostrarnos un cuadro en el que nos diga que reinstalemos la aplicación, el que suscribe se queda a oscuras.»

    Además, antes (creo que antes del Visual Studio 2005), te decía exactamente qué fallaba y por qué.

    Vamos para atrás, como los cangrejos.

  3. Tranquilo hombre, que esas cosas le pasan a cualquiera 🙂

    Respecto al iRex Reader a mi no me importa mucho que no vaya bien con los Mobipocket, por que para eso ya tengo el Cybook. Si va bien con los PDF grandes entonces me vendría genial, aunque con la calculadora en la mano, eso tiene el tamaño de un A5 y no un A4, pero parece suficiente para la mayoría de los documentos y libros técnicos.

    De todas formas me voy a esperar a que publiquen críticas y a que alguien me lo traiga de Canarias para ahorrarme 100 pavos.

  4. Señor, en relación a los RUNTIMES; ¿cómo se puede instalar el C Runtime (msvcr71.dll) sin tener instalado (ni quererlo instalar) el VStudio 2005 para C++, estando en un WXP. En alguna parte de la web de Microsoft vienen los merges modules adecuados ??

    La idea es instalarlo, pues un componente externo de mi aplicación (PDFLib) necesita que en c:windowssystem32, esté la dll msvcr71.dll. El objetivo final sería tener un Setup Project para poder instalar esos merges modules del C Runtime, pero no he visto nada al respecto.

    Sería interesante unos post sobre interop de atributos, usar desde C# una DLL nativa en C++ y otra DLL C++/CLI. Yo lo más ha sido utilizar la API de Windows y algunos COM / ActiveX.

    Saludos y gracias.

  5. Jejejee…
    Algo parecido me ocurrió en un proyecto en el que trabajaba… n cafés, m cocacolas y dos días después para terminarnos dando cuenta de que teníamos una versión distinta del jodido runtime… xD

Responder a anonymous Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *