Un control adapter siempre está contenido en una DLL (puede ser la misma que genera nuestra aplicación web) que se debe desplegar en el directorio Bin de la aplicación. El paso final para el registro de un control adapter se hace a través de un fichero .browser, dentro de la carpeta app_browsers de la aplicación ASP .Net. Podeis mirar como se hace un control adapter y como se registra en muchos sitios, como en este artículo sobre control adapters.
Si queremos que la influencia de un control adapter sobrepase a nuestra aplicación web, digamos a nivel de máquina, el registro de este adaptador es ligeramente distinto, así como la ubicación de la DLL.
Lo más habitual es desplegar la DLL en la GAC, para lo que esta deberá estar firmada. Una vez hemos colocado la DLL en la GAC, el registro se hace también a través de un fichero .browser, pero en este caso este fichero debe colocarse en una carpeta del framework .net. En el caso de una máquina de 32 bits, sería en la carpeta "C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers". Si se trata de una máquina de 64 bits, la carpeta sería, como parece lógico, "C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG\Browsers".
Una vez colocada la DLL en la GAC y el fichero browser en la correspondiente carpeta del Framework, hay que generar una dll para que el framework sea capaz de aplicar el control adapter cuando sea necesario. Para generar esta DLL se debe utilizar el comando
aspnet_regbrowsers -i
Este comando genera una DLL que se instala en la GAC y que permite que el control adapter que hemos instalado actue.
En este escenario de control adapter que se publica a nivel de máquina, a veces no se consigue el efecto esperado. El síntoma es que, aunque se siguen los pasos y no parece que haya habido errores, el control adapter no consigue entrar en acción.
El escenario real en el que nos ha pasado en nuestro trabajo es el de un control adapter que se usa para mejorar la accesibilidad de Sharepoint 2007. Este adapter (en conjunción con otros elementos) modifica el HTML generado por el control WebPartZone, de forma que, cuando estamos en una página de publicación pero no la estamos editando, este control no genera tablas.
Pues bien, aunque parece bien registrado, el control adapter no actúa y sigue presentando tablas. No importa las veces que se ejecute el comando de registro ni las veces que se haga iisreset, no funciona. ¿Por qué? Pues la verdad es que no sabría decir por qué, pero si puedo decir cómo hemos conseguido solucionarlo.
En Sharepoint, cada aplicación web o cada extensión de las mismas tiene un directorio raíz, ubicado en c:\inetpub\wwwroot\wss\virtualdirectories. Dentro de estas aplicaciones web, que Sharepoint crea automáticamente, se ubica una carpeta app_browsers, con un fichero compat.browsers. Pues resulta que abriendo esos ficheros, modificándo cualquier parte (un espacio ente dos tags, por ejemplo, que no altera el significado del xml), y haciendo iisreset, se soluciona.
Mi hipótesis:las aplicaciones se crearon antes de que se registrara el control adapter a nivel de máquina, y, de algún modo, sus compat.browsers se compilaron y almacenaron en alguna misteriosa ubicación. Una vez introducido el nuevo .browser a nivel de máquina, no importa lo que hicieramos, estas versiones compiladas y misteriosamente almacenadas no se actualizaban con la nueva información. Al hacer la modificación en los ficheros compat.browser a nivel de aplicación, se recompilaron, teniendo en cuenta esta vez las configuraciones a nivel de máquina.
Esto nos habría venido muy bien saberlo hace un par de años, porque en más de una ocasión hemos perdido bastantes horas en algún cliente intentando implantar estos adaptadores, hasta que milagrosamente empezaron a funcionar. Parece que no tan milagrosamente, después de todo...
No hay comentarios:
Publicar un comentario