Pro tip: Parse utiliza la configuración regional.

Si algo puede salir mal... saldrá mal. 

 

Murphy

Murphy es un tipo del cual todos han escuchado y nadie nunca ha visto, algúnos tienen la teoría de que fué víctima de sus propias leyes.

Si trabajan en informática me van a entender muy bien la siguiente anécdota: Imaginense en un viernes por la tarde, preparandose para salir de la oficina, su sistema que ha pasado en pruebas los últimos dos días funciona a la perfección en su maquina de pruebas y solo tienen que hacer la migración al servidor de producción.

Cinco minutos antes de salir, copian su sistema al servidor de producción y sorpresa: ¡¡¡No funciona!!! Yo se que en algún moemento que todos han sentido este sentimiento de frustración, pero sin embargo resulta aún más frustrante cuando te das cuenta de que tu sistema no genera errores, ni excepciones y "pareciera" funcionar normalmente, con el único problema que no guarda los datos que tiene que guardar.

 

Los italianos y el sofware

Nuestro proveedor de hosting es italiano, así que el servidor tiene la configuración regional de Italia. El sistema que intentamos instalar es un simple lector de Feeds Atom que guarda las entradas nuevas a una base de datos y hace las notificaciones correspondientes a los clientes que están suscritos al sistema.

Al momento de la carga, se utilizan unos parámetros de configuración que determinan que entradas se leen y cuales se ignoran. Los feeds son, obviamente, generados en inglés.

 

El problema

Resulta que los parámetros que estabamos utilizando ocupaban decimales y la configuración regional de Italia considera la coma (,) como el separador decimal, obviamente el feed en inglés utilizaba el punto (.) y las condiciones simplemente no se evaluaban de manera correcta.

Descubrimos, de mala manera, que las funciones Parse de los tipos básicos de .NET utilizan la configuración regional del sistema en que se esté corriendo el programa. Microsoft en su "soberana inteligencia" decidió que cuando un símbolo no es separador decimal, entonces es un separador de grupo... ¡¡¡Gracias Microsoft!!! ¡¡Solo a ustedes se les puede ocurrir que un punto en 16.23456123 es un separador de grupo!! Por tanto y al lograrse leer, no genera errores, ni excepciones, ni absolutamente nada que se pueda depurar fácilmente.

 

La solución

Como se nos hacía imposible cambiar el idioma del servidor (les cuento de los problemas que ello implica en otra entrada), entonces nos vimos obligados a modificar un poco el código para cambiar la configuración regional del programa en tiempo de ejecución.

Si algún día se encuentran con este problema pueden utilizar el siguiente código para cambiar la configuración regional en C#.NET:

// Cambia la configuración regional para el
// hilo en ejecución.
Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo("en-US", false);

Espero el código les sea útil y recuerden... el método Parse de los tipos básicos utiliza la configuración regional local.

+Solución al problema en StackOverflow
+Referencia de la lectura de tipos numéricos en MSDN