viernes, 5 de diciembre de 2008

Instaladores web en Windows Server 2008 e IIS 7

Una de las etapas del desarrollo de software que más me suelen preocupar es la de despliegue, no tanto por la importancia que tiene sino por la poca importancia que se le suele dar. Es demasiado habitual no tener esta etapa en consideración a la hora de planear el desarrollo de un proyecto y, llegado el momento, todo son prisas y problemas.

En el caso en que se tenga en consideración esta etapa, una de las maneras más sencillas para desplegar una aplicación es utilizar un paquete de distribución generado con Visual Studio. En muy pocos clicks obtendrás lo que buscas. Eso sí, no se debe menospreciar la dificultad que puede llegar a tener esta tarea en caso de que las cosas se compliquen.

La última muestra de esto que os cuento me sucedió esta semana cuando, tras haberlo hecho en alguna otra ocasión con éxito, intenté crear un proyecto de instalación para una aplicación web con Visual Studio 2008, para ser instalada en Windows Server 2008. El caso es que, a diferencia de las otras veces, una vez generado el programa de instalación, al ejecutarlo no llegaba ni a mostrar la página de bienvenida. En lugar de eso, aparecía un error similar al siguiente:

"The installer was interrupted before XXX could be installed. You need to restart the installer to try again." (copio el texto en inglés porque estaba ejecutando el instalador en un servidor WS 2008 English)

La traducción sería algo así como: "El proceso de instalación de XXX se canceló antes de finalizar. Reinicie el proceso de instalación para probar de nuevo".

Poca información, la verdad. La única solución que quedaba era mirar los logs del instalador, que pueden ser generados de la siguiente manera:

msiexec /i paquete.msi /lv errores.log

Tras un rato investigando los logs llegué a la conclusión de que el problema venía por la manera en que el instalador trataba de encontrar los metadatos de IIS7 y recordé que hay una manera de permitir que IIS7 pueda administrarse en modo compatible con IIS6, con el que nunca tuve problemas con este tipo de instaladores. Fui a la administración de roles del servidor y añadí esta opción, como muestra la figura:

Tras realizar esto, pude comprobar para mi tranquilidad que la instalación se realizaba sin ningún inconveniente. Podemos concluir que si queremos utilizar la herramienta que proporciona Microsoft para generar paquetes de distribución web compatibles con IIS7 deberemos tener como prerrequisito que el modo de compatibilidad con IIS6 esté activado. Eso, o crear una custom action que realice todo el proceso de creación del directorio virtual y copiado de los ficheros de manera automática. Lo dejo a vuestra elección.

martes, 2 de diciembre de 2008

Problema con variaciones de sitio y webparts de ASP.NET

Como ya sabréis, podemos utilizar dos tipos de webpart a la hora de personalizar Sharepoint. Por un lado tenemos los webparts propios de Sharepoint, herencia de versiones anteriores del producto, bajo el espacio de nombres Microsoft.SharePoint.WebPartPages, y por el otro tenemos los webparts genéricos de ASP.NET 2.0, bajo el espacio de nombres System.Web.UI.WebControls.WebParts.

En teoría tenemos libertad para elegir un tipo de webpart u otro en nuestros proyectos salvo algunos casos excepcionales (como por ejemplo la conexión de dos webparts en diferentes páginas). La razón por la que digo "en teoría" es porque en ocasiones te encuentras con alguna sorpresa al trabajar en un proyecto y, como muestra, un botón.

En un proyecto en el que estoy trabajando actualmente utilizamos variaciones de sitio para crear contenidos en cuatro idiomas: catalán, castellano, inglés y francés. Todo parecía estar funcionando a las mil maravillas en los cuatro idiomas hasta que a la hora de realizar las últimas pruebas nos dimos cuenta de que un único sitio se había generado para todos los idiomas salvo para el francés. Después de investigar un poco se llegó a la conclusión de que el problema venía por el uso de webparts de ASP.NET 2.0 ya que en cierto momento saltaba una excepción por no poder hacer un convertir un webpart al tipo Microsoft.SharePoint.WebPartPages.WebPart.

La primera solución que viene a la cabeza, obviamente, es cambiar todos los webparts para que hereden de la clase correcta pero, ¿es la solución? evidentemente no. Posiblemente un proyecto que actualmente está en desarrollo pueda aceptar este tipo de cambio pero, ¿qué ocurre con los proyectos que actualmente están en producción? ¿Perderemos la posibilidad de utilizar webparts de ASP.NET 2.0, con todas las ventajas que esto proporciona?

Como parecía claro que debía existir una solución mejor a este problema, creímos oportuno buscarla y, como no podía ser de otra manera, se encontró en forma de hotfix. Al parecer este hotfix no forma parte del SP1 de MOSS así que, si a alguno de vosotros se os presenta este problema, os recomiendo que lo descarguéis y probéis suerte.

Visita del equipo de producto de CRM a Spenta Consulting

Durante la celebración del pasado Tech·ed Developers 2008 tuvimos el honor de recibir la visita en las instalaciones de Spenta Consulting de un miembro del equipo de producto de CRM en Redmond. El encuentro tuvo lugar con dos objetivos fundamentales. El primero de ellos, mostrar al equipo de producto los desarrollos que se han realizado en el marco de CSP. El segundo, escuchar de primera mano las novedades que ya se habían presentado en el pasado PDC relativas a la nueva versión de CRM.

Os dejo a continuación la noticia que se publicó en la web de Spenta Consulting al respecto. En ella podréis leer más acerca del encuentro.

http://www.spenta.es/es-ES/noticias/Paginas/noticias.detalle.crmteam.aspx