Los que me conocéis sabéis que soy un fanático (hasta niveles enfermizos) de los depliegues puristas de soluciones en SharePoint. La obsesión que tengo por seguir las buenas prácticas en ese sentido y de querer automatizar al máximo los procesos de instalación me ha traído muchos problemas en el pasado... y en el presente. Soy consciente de que en ocasiones un documento adjunto con 3 pasos manuales habrían salvado muchas de mis horas de trabajo pero qué le vamos a hacer, es el único vicio confesable que tengo y he aprendido a aceptarme tal cual ;).
En esta entrada no quiero hacer un análisis exhaustivo de lo que yo entiendo por despliegue sobre MOSS. La verdad es que si empezase a hablar del tema no acabaría nunca, y no es mi objetivo para este blog. Lo que quiero comentar es un detalle con el que me he estado peleando últimamente y que me ha hecho desesperar en algunos momentos. Lo más grave del caso es que es una cosa que conocía desde hace mucho tiempo pero siempre se había quedado en el tintero por razones diversas. Espero que el hecho de escribirlo sirva como terapia para no olvidarlo en el futuro.
Para empezar, os pongo en situación, pero simplificando mucho el escenario. Imaginad que necesitáis desplegar un fichero a una carpeta bajo el directorio c:\inetpub\wwwroot\wss\virtualdirectories\xxxx, siendo xxxx el puerto de la aplicación web donde queréis utilizar dicho fichero. Compliquemos este escenario teniendo la necesidad de desplegar ese mismo fichero a las carpetas relativas a cada una de las extensiones de la aplicación web en cuestión. Un pasito más: necesitamos desplegarlo además a todos los servidores de la granja de MOSS. Lo rematamos, el fichero está incluído dentro de un proyecto en modo hosted.
Nota: El hecho de que el proyecto sea de esta tipología complica mucho el escenario, porque no estamos hablando de crear un portal y mantenerlo, sino de darle a tu cliente la posibilidad de crear tantos portales como necesite. Si no se os ocurre ningún proyecto de estas características, os puedo recomendar leer algo de CSP.
Si todavía queréis más complicación, imaginad que tenéis que desplegar también cambios en el web.config de todas las zonas que he comentado anteriormente. En realidad, la complicación la podíamos reducir a tocar elementos fuera de la estructura de la carpeta 12. Recordad la restricción que tenemos de no poder ir al servidor a tocar uno de estos ficheros a mano, y la necesidad de que todo esto se mantenga de una manera robusta aunque el cliente siga creando portales (hablo aplicaciones web, no de sitios y colecciones de sitio) a medida que los necesita.
Todo esto es más o menos complejo y requiere de feature receivers para realizar todas las acciones que necesitamos y, en este caso, necesitamos un tipo concreto de características que se activen a nivel de aplicación web. Estas características tienen un elemento que las hace diferentes al resto ya que, por defecto, se activan automáticamente en las nuevas aplicaciones web que se crean. Esto puede resultar útil en muchos casos pero, si lo que necesitamos es copiar un elemento a la carpeta que antes he mencionado, o tocar un web.config y, encima, tenemos varias extensiones y varios servidores, existe una gran probabilidad de que las carpetas no existan cuando se activa la característica.
Bueno, y después de todo este rollo, la solución. Basta con añadir una propiedad al fichero feature.xml: ActivateOnDefault="FALSE". Por defecto, la propiedad tiene valor verdadero pero si lo cambiamos conseguiremos que la característica sólo se active cuando nosotros se lo decimos. En fin, espero que esta nota mental me sirva para no volverlo a aparcar en futuros proyectos.
0 comentarios:
Publicar un comentario