VELOCIDAD DE ESCAPE
Inicio > Historias > ERROR AL CAMBIAR EL NOMBRE DE ENSAMBLADO
2004-07-23
Eso sí, de cabezazos contra el monitor te pegas hasta que descubres lo que pasa.
Normalmente, nombramos el ensamblado de un proyecto y su Namespace del mismo modo, e incluso las librerías de clases también. Pero resulta que si renombramos el Ensamblado por la razón que sea, el viejo ensamblado no es eliminado sino que se le añade otro nuevo con el nombre que le acabamos de dar y se recompilan juntos. Seguimos trabajando, pasa el tiempo.
Todo funciona con normalidad hasta que subimos el proyecto al servidor. De repente comienza a pegar errores por todas partes. Se suele reconocer el problema porque uno de los primeros errores (si no el primero) el el que hace referencia al Gobal.asax. La aplicación de repente se vuelve loca y no logra encontrar ninguna librería.
Este es el momento en que vuelves a probar el ensamblado en la máquina de desarrollo y todo funciona a la perfección.
La vuelves a subir, y errores por todas partes. Cabezazos contra el monitor.
La razón es muy sencilla pero nada intuitiva. El proyecto local todavía tiene referencias al antiguo ensamblado con el antiguo nombre y de hecho, lo carga sin problemas. En cambio, al implementar en servidor, dicho ensamblado antiguo, como es natural, no se añade porque lo dejamos de usar en el proyecto.
Para ver el error localmente es tan solo necesario eliminar la antigua DLL de la carpeta BIN de nuestro proyecto. Veréis ahora los mismos errores que nos estaba dando al exportar al servidor de producción. Ahora es más sencillo corregir las llamadas a clases que no apuntan donde deberían apuntar.
Creo que en el nuevo Visual Studio 2005 (Whidbey) esto queda resuelto, pero no lo han confirmado todavía, así que no está de más mencionarlo.
ERROR AL CAMBIAR EL NOMBRE DE ENSAMBLADO
Hay un comportamiento extraño del entorno Visual Studio NET que a más de uno lo trae de cabeza al comenzar a programar páginas ASPX. Quizás sea un consejo un poco estúpido este, pero nunca está de mas mencionar algo que no he visto que nadie se molestase en explicar, quizás porque es tan elemental que se pasa por alto.Eso sí, de cabezazos contra el monitor te pegas hasta que descubres lo que pasa.
Normalmente, nombramos el ensamblado de un proyecto y su Namespace del mismo modo, e incluso las librerías de clases también. Pero resulta que si renombramos el Ensamblado por la razón que sea, el viejo ensamblado no es eliminado sino que se le añade otro nuevo con el nombre que le acabamos de dar y se recompilan juntos. Seguimos trabajando, pasa el tiempo.
Todo funciona con normalidad hasta que subimos el proyecto al servidor. De repente comienza a pegar errores por todas partes. Se suele reconocer el problema porque uno de los primeros errores (si no el primero) el el que hace referencia al Gobal.asax. La aplicación de repente se vuelve loca y no logra encontrar ninguna librería.
Este es el momento en que vuelves a probar el ensamblado en la máquina de desarrollo y todo funciona a la perfección.
La vuelves a subir, y errores por todas partes. Cabezazos contra el monitor.
La razón es muy sencilla pero nada intuitiva. El proyecto local todavía tiene referencias al antiguo ensamblado con el antiguo nombre y de hecho, lo carga sin problemas. En cambio, al implementar en servidor, dicho ensamblado antiguo, como es natural, no se añade porque lo dejamos de usar en el proyecto.
Para ver el error localmente es tan solo necesario eliminar la antigua DLL de la carpeta BIN de nuestro proyecto. Veréis ahora los mismos errores que nos estaba dando al exportar al servidor de producción. Ahora es más sencillo corregir las llamadas a clases que no apuntan donde deberían apuntar.
Creo que en el nuevo Visual Studio 2005 (Whidbey) esto queda resuelto, pero no lo han confirmado todavía, así que no está de más mencionarlo.
Programación | jomaweb | 0 Comentarios | Enlace
Referencias (TrackBacks)
URL de trackback de esta historia http://jomaweb.blogalia.com//trackbacks/20403