Error al conectarse al administrador de deshacer del archivo de código fuente

“Error al conectarse al administrador de deshacer del archivo de código fuente c:blahblaharchivo.designer.cs” es un mensaje con el que Visual Studio (tanto la versión 2005 como 2008) me ha abofeteado en numerosas ocasiones cuando estoy desarrollando sitios web ASP.NET.

Y la verdad, es uno de esos casos en los que no sabes qué hacer: recompilas, limpias la solución, abres y cierras el IDE… pero nada, cuando le da por ahí, no hay forma de hacerlo entrar en razón:

Error al conectarse al administrador de deshacer del archivo de código fuente

Como ya habría corregido el problema en el momento de escribir este post y no pude reproducirlo para capturar la ventana,
os muestro cómo luce en su versión en inglés 😉

imageBuscando un poco de información, parece ser que se trata de un problema que aparece al editar el archivo .aspx mientras se está depurando la página, siguiendo una secuencia determinada.

Una de las formas de solucionarlo es un poco bestia, pero funciona (al menos en VS 2008): basta con eliminar el archivo xx.designer.cs indicado por el error (previo backup, por si acaso, aunque hasta ahora no me ha hecho falta nunca ;-)) y forzar al entorno a que lo genere de nuevo, pulsando el botón derecho del ratón sobre el archivo .aspx y seleccionando la opción “Convertir en aplicación web” que habrá aparecido en el mismo.

De momento no le he visto contraindicaciones, y estoy de lo más contento 🙂

 

 

 

 

Hábilmente crossposteado desde: Error al conectarse al administrador de deshacer del archivo de código fuente  @ Variable not found
Hey, ¡estoy en twitter!

Cambiar el location.href conservando el Referer

¿Se pierde el Referer al cambiar el location.href? El HTTP Referer es una variable que nos envían los navegadores en cada petición, permitiéndonos conocer de dónde viene el usuario, es decir, la página donde se encontraba el enlace, botón o formulario cuya activación ha provocado el salto a nuestro sitio.

Por ejemplo, si un servidor recibe esta solicitud:

GET / HTTP/1.1
Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, (...omitido...), */*
Referer: http://www.google.es/search?hl=es&rls=ig&q=variable&btnG=Buscar&meta=&aq=f&oq=
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; (...omitido...) )
Accept-Language: es
Accept-Encoding: gzip, deflate
Host: www.variablenotfound.com
Connection: Keep-Alive
analizando el campo Referer se puede determinar de forma muy sencilla que se trata de un usuario que proviene de Google, y que estaba buscando el término “variable”. Esta característica aporta una información, que aunque no es demasiado fiable (se puede alterar y desactivar muy fácilmente),  se utiliza con mucha frecuencia con fines estadísticos, o para adecuar el contenido de la página a las intenciones del usuario.

Sin embargo, como se trata de una característica manejada directamente por el navegador, podemos encontrarnos con que no todos actúan de la misma manera… o en otras palabras, es Internet Explorer es el que actúa de forma diferente al resto 😉

Si la visita a nuestra página se produce como consecuencia de la ejecución de un script que ha modificado dinámicamente el location.href, o ha invocado a location.replace, Internet Explorer saltará a la nueva dirección, pero no enviará el Referer en los encabezados de la petición, por lo que en el punto de destino no se podrá conocer el origen de la misma.

Por tanto, un código como el siguiente hará que la página editar.asp no pueda conocer desde dónde se le ha referenciado:

<input type="button" value="editar" onclick="location.href='editar.asp';">
Dado que Microsoft todavía está considerando modificar este comportamiento, hay que darle un poco las vueltas para conseguirlo provocando el salto hacia la página de destino sin utilizar los mecanismos citados anteriormente.

Una forma muy ingeniosa que he encontrado se basa en crear dinámicamente un tag <a> con su correspondiente href establecido, y simular la pulsación del mismo invocando al evento click:

function navigateWithReferrer(url) {
   var fakeLink = document.createElement("a");
   if (typeof (fakeLink.click) == 'undefined')
      location.href = url; 
      else {
         fakeLink.href = url;
         document.body.appendChild(fakeLink);
         fakeLink.click();   
      }
}
Visto en: Velocity Reviews
Crossposteando desde el location.href: Cambiar el location.href conservando el Referer @ Variable not found.

Por sorpresa… ASP.NET MVC 2 RC 2

Hace unas horas Phil Haack ha anunciado la publicación de la penúltima revisión del framework MVC 2 antes de la versión final.

Según se recoge en el documento de notas de la revisión, la única característica añadida ha sido el cambio en la forma de validar las entidades del Modelo. En versiones anteriores, durante el binding se evaluaban las restricciones establecidas en las propiedades cuyos valores eran recibidos por el servidor, mientras que ahora se valida la entidad completa.

También, aunque de menor calado, han sido introducidos otras mejoras interesantes, como el nuevo método Peek() del diccionario TempData, el incremento del rendimiento en varios puntos, o una nueva forma de indicar parámetros opcionales en las rutas, que son eliminados para no interferir otros datos recibidos en la petición.

Desafortunadamente, aún no podemos probarla con las versiones preliminares de VS2010, y sólo funcionará con la versión 2008 del IDE. 🙁

Enlaces:

Publicado en: Variable not found.

Actualizando el equipo con Disk2Vhd

Por cosas de la procrastinación, tenía una máquina pendiente de formatear desde hace unos años ;-P, y he aprovechado el fin de semana para hacerlo. Como sabréis, esto no es tarea fácil, se requiere mucho pragmatismo, gran concentración y, principalmente, vencer al Diógenes digital que todos llevamos dentro ;-D.

Y claro, una vez que nos ponemos, el problema es cómo conseguir minimizar los daños colaterales. Esta máquina, aunque algo antigua, estaba todavía en uso y tenía gran cantidad de archivos y software instalado en su disco de sistema. También contaba con un disco exclusivamente para datos, pero éste no me suponía ningún problema.

En estos casos normalmente no basta con hacer un salvado del disco duro, a lo bruto, sobre otro disco, formatear y listo; así sólo conseguiremos tener acceso desde la nueva máquina a los ficheros físicos del sistema anterior, pero no podremos realizar tareas de nivel superior, como copiar configuraciones, exportar o importar datos desde aplicaciones, etc. Y lo que es imposible, al menos en mi caso, es planificar este movimiento con tanta exactitud que no se quede ni un byte por detrás.

La conclusión a la que llegué es que la única forma de hacerlo con cierta tranquilidad era virtualizando el sistema anterior. Esto me permitiría acceder en vivo a la configuración anterior y traspasar archivos con la seguridad que necesitaba.

Dis2VhdY aquí es donde ha entrado en juego Disk2Vhd, la magnífica herramienta de Sysinternals (¿he dicho Microsoft? ;-)), que es capaz de generar un disco duro virtual (archivo con extensión .vhd) a partir de un disco duro físico. Y lo mejor de todo, que puede hacerlo sobre el propio equipo que está generando el volcado, es decir, en caliente.

El único requisito es disponer de espacio libre (por ejemplo, como yo lo hice, en un disco duro externo), estar corriendo Windows XP SP2, Windows Server 2003 SP1 o superiores, incluyendo sistemas x64, y suficiente espacio en un disco duro como para almacenar el archivo resultante del volcado.

La aplicación es muy sencilla de utilizar. Se descarga desde su sitio web y se ejecuta, no requiere instalación (también puedes usarla directamente); tras ello, simplemente debemos elegir los discos a virtualizar, seleccionar una ubicación de salida para el archivo .vhd, esperar unas horitas y ya lo tenemos. Normalmente bastará con virtualizar el disco de sistema.

Consejo #1: para que la conversión se realice más rápidamente, lo mejor es hacer que el .vhd a generar resida en un disco duro distinto del que estamos virtualizando, aunque se puede realizar sobre el mismo.

Una vez con el archivo .vhd a buen recaudo, ya podemos formatear tranquilamente el disco del sistema, montar el nuevo sistema operativo y comenzar a instalar las aplicaciones que vayamos a necesitar.

Para acceder al sistema anterior tal y como estaba antes de la masacre, basta con instalar Virtual PC, crear una máquina virtual, “engancharle” el disco .vhd que hemos generado, y arrancar normalmente, pero ojo:

Consejo #2: haz una copia de seguridad del archivo .vhd antes de realizar cambios sobre el disco duro virtual. Me he encontrado algunos callejones sin salida en los que me ha venido de perlas (p.e., petes del Virtual PC al instalar las Virtual Machine Additions que me dejaban la máquina virtual inutilizada).

La primera vez que enciendes la máquina virtual se llevará un buen rato arrancando Windows; es lógico, pues todos los controladores que tiene instalados corresponden a la máquina física, y el nuevo entorno debe ser configurado, prácticamente igual que si hubiéramos instalado el disco duro físicamente en otro equipo y arrancáramos desde él. Cuando esta reconfiguración finaliza, podremos utilizar con normalidad la máquina virtual e ir pasando las configuraciones y archivos al nuevo sistema tranquilamente.

Consejo #3: revisa la configuración básica de tu máquina virtual para evitar conflictos y funcionamiento anómalo en algunas aplicaciones; nombre de máquina, dirección IP, variables de entorno del sistema operativo, etc. En mi caso, la variable TMP/TEMP apuntaba a una unidad inexistente en el entorno virtual, y provocó algún que otro problemilla.

Y por si lo que queremos acceder a los datos del equipo anterior en bruto, existe la posibilidad de montar un archivo .vhd como si fuera un disco duro más y acceder a su contenido directamente, por lo que podemos evitar la incomodidad de tener que arrancar Virtual PC para todo. Si usas Windows 7 (o 2008), esta capacidad viene “de serie”, sólo tienes que activarla desde el administrador de discos:

Montando un VHD en Windows 7

Virtualmente crossposteado desde Actualizando el equipo con Disk2Vhd @  Variable not found

Forzar validación desde cliente con ASP.NET Webforms

 

Validación de formularios ASP.NET desde javascript Cada vez que tengo que forzar la validación de los datos de un formulario Webforms mediante javascript me veo obligado a preguntarle a Google, ese que todo lo sabe, cómo era el nombre de la función. Cosas de la edad, supongo 😉

Así que, a modo de auto-recordatorio y con la intención de que pueda ser útil a alguien más, ahí va: la función se llama Page_ClientValidate(). Retorna “true” si, una vez evaluados todos los validadores de la página, el valor de los campos es correcto (al menos en cliente; otra cosa son las comprobaciones en servidor, p.e., las definidas en un CustomValidator).

Y como ejemplo de uso, puede valer el siguiente. Se trata de un botón de envío en un formulario donde se compone un correo electrónico:

   1: ...

   2: <asp:Button ID="btnEnviar" runat="server" Text="Enviar mail" 

   3:      OnClick="btnEnviar_Click"

   4:      OnClientClick="return confirmar();"

   5: />

   6: ...

   7:  

   8: <script type="text/javascript">

   9:     function confirmar() {

  10:         if (!Page_ClientValidate())   // Fuerza la validación en cliente

  11:             return false;             

  12:             

  13:         return confirm('¿Seguro que desea realizar el envío?');

  14:     }

  15: </script>

 

Como se puede observar, en el atributo OnClientClick del botón incluye un script en el que se retorna el valor devuelto por la función confirmar. Si el retorno es false, se cancela el Postback, evitando así que se invoque al evento btnEnviar_Click que es el que realiza el envío del mail propiamente dicho.

En el cuerpo de la función confirmar(), en primer lugar, validamos la página; si ésta no supera el proceso, los validadores habrán mostrado sus mensajes de error y retornamos falso, haciendo que se anule el postback. Si la validación es correcta, solicitamos al usuario que confirme la acción y retornamos su decisión.

Publicado en: Variable not found.