¡La culpa es tuya!

Por cuestiones varias totalmente ajenas a mi voluntad (léase “política de empresa”) me veo obligado a pasar de Microsoft Visual Studio 2003 (un entorno de desarrollo sobre .NET, para profanos) a Microsoft Visual Studio 2008 (el mismo entorno ligeramente mejorado y altamente maquillado); como es habitual en cualquier programa de la marca Microsoft, los documentos de versiones nuevas del mismo programa se almacenan de manera totalmente distinta, por lo que al abrir mi proyecto con la nueva versión me comenta que va a actualizarlo “de manera 100% segura, aunque por si acaso haremos una copia de seguridad previa”.

Por precaución (sabia y siempre buena precaución), decido romper mano con un proyecto de entrenamiento, uno de esos proyectitos que utilizamos para trastear. El programa actualiza mi proyecto y, cuando voy a comenzar a trabajar, me pega la primera en la frente: un mensaje de error que golpea mi cara cual bofetada de novia despechada simplemente con intentar abrir un fichero.


Investigo el error y resulta que la causa principal, lo que verdaderamente ha petado, es el propio entorno de desarrollo (para aquellos que entiendan de programación y de tratamiento de excepciones, fijaos en que el origen del error está en Microsoft.VisualStudio.Design.Serialization.CodeDom.XML.CodeDomXMLProcessor). Me fijo en ese enlace arriba a la derecha que me dice ¿Por qué estoy viendo esto? (Why am I seeing this?), y para allá voy.

Y aquí es donde viene lo mejor. Si consultáis el enlace veréis que lo que dice es que, aunque parezca que lo que ha fallado es el entorno de desarrollo, en realidad la culpa es de tu código, y te da ciertos consejos para “escribir código que no haga fallar el entorno de desarrollo”. Por sí mismo esto ya es bastante lamentable, ya que vender un producto a precio de oro y luego pedir al programador que vaya con cuidadín no sea que se lo cargue no suena a candidato al premio “Mejor estrategia de márketing”, pero si tenemos en cuenta que el susodicho fichero que invocó al Arcángel Gabriel para provocar el Sodoma y Gomorra de la programación fue generado por el propio entorno de desarrollo llegamos a que ni ellos mismos son capaces de generar un fichero que asegure la estabilidad de su programa. ¡Tres hurras por Microsoft!

La solución final la encontré a la vieja usanza, a la del programador nato: abres el fichero y lo editas tú mismo a mano, ni entornos gráficos, ni asistentes, ni Clipo mutando a nave espacial. Y todos contentos.