Hoy me he encontrado con un error bastante peculiar a la hora de desplegar una solución en una granja SharePoint. El error era básicamente algo parecido a lo siguiente:
Error occurred in deployment step 'Add Solution': Failed to extract the cab file in the solution.
Lo extraño era que la solución no tenía nada de particular. Simplemente un par de páginas ASPX que se desplegaban en la carpeta LAYOUTS, alguna hoja de estilos y algún que otro fichero javascript.
Después de unas cuantas vueltas he acabado dando con la raíz del problema. En algún punto del proceso de despliegue, SharePoint necesita extraer el contenido del paquete WSP en alguna ruta del sistema de archivos y debe haber alguna limitación en el tamaño máximo que puede tener una ruta en Windows que hacía que el proceso fallara. Es importante entender que a la hora de extraer el contenido de la solución, SharePoint crea una carpeta cuyo nombre coincide con el nombre del proyecto. La solución ha sido fácil: cambiar el nombre del proyecto por algo más corto. De todas maneras, esto me da pie a dar algún consejo a la hora de dar nombre y de organizar vuestras soluciones.
Lo primero que os recomiendo es no escoger nombres demasiado largos para vuestras soluciones. Es más habitual de lo que parece escoger nombres como el siguiente:
Empresa.Proyecto.Fase.WebpartsMolonesParaExtenderLaCapaSocialdeSharePoint
No os voy a decir que el nombre no es correctísimo para describir lo que contiene la solución pero, realmente creeis que es necesario? Seguramente sea más apropiado tener una solución que se llame “Proyecto” y dentro una característica que se llame “SocialWebParts”.
Hay mucha gente que es partidaria de construir multitud de paquetes dentro del paraguas de un mismo proyecto de cara a “protegerse” de otros desarrolladores y de los conflictos que pueda ocasionar el trabajo en equipo. Yo soy más partidario de todo lo contrario: un proyecto, un paquete. Para mí construir paquetes independientes se debe hacer únicamente en base a razones del tipo: “esta parte de la solución se tiene que poder desplegar de manera independiente” o “esta parte de la solución puede ser reutilizada sin la necesidad de desplegar todo el resto del proyecto”. Si el trabajo en equipo produce conflictos, soluciona el problema, no lo rodees.
Me he ido por las ramas. El segundo consejo que os voy a dar es organizar de manera adecuada vuestros elementos dentro de la solución. Hay elementos, como por ejemplo las características, que tienen que ir en un sitio determinado y ante lo que poco podemos hacer. Otros elementos, sin embargo, son más “flexibles”. En ocasiones me encuentro con proyectos con varias carpetas a nivel raíz. Esas carpetas no son más que carpetas mapeadas a los directorios LAYOUTS, IMAGES, RESOURCES, etc. de SharePoint. Mi recomendacion habitual es mapear únicamente la carpeta raíz (14, 15 o lo que venga) y crear la estructura que necesites dentro de esa carpeta mapeada. De esa manera te resultará mucho más fácil separar todo aquello que va a desplegarse directamente a los servidores de SharePoint de aquello que va a tener que aprovisionarse a través de características.
En general, si seguís estos dos consejos, o si no seguís ninguno de ellos, no os encontraréis nunca con el error al que hacía referencia al inicio de este artículo. Sin embargo, si seguís únicamente uno de los dos consejos, el riesgo es bastante alto. En mi caso, tenía los elementos muy bien organizados pero se me ocurrió la brillante idea de darle a mi solución un nombre extremadamente largo.
En casa del herrero…
0 comentarios:
Publicar un comentario