Leyendo el título de este artículo alguno podría imaginar que voy a hablar mal de SharePoint o de Visual Studio pero, si me conocéis, sabéis que esto no sería demasiado normal. Aunque nunca diré que son productos perfectos que colman todas mis necesidades en cualquier momento, muchos de los problemas que les encuentro acaban teniendo una razón más humana de lo que parece inicialmente.
Hasta la llegada de Visual Studio 2010, aquellos que desarrollábamos proyectos basados en SharePoint teníamos bastante más trabajo y, a su vez, bastante más control. Sí, realizar un buen trabajo era más complicado pero cuando tu solución no se creaba o no se desplegaba solías tener más control sobre qué estaba pasando. Con la nueva versión de Visual Studio se había automatizado tanto el proceso que, en ocasiones, daba la sensación de que los desarrolladores habíamos perdido el control y en ocasiones pensabas qué pasaría con aquellos que comenzaban a desarrollar directamente para SharePoint 2010, ¿sabrían por qué pasaban las cosas y qué había detrás de cada elemento de la solución?
Hoy me he encontrado en uno de esos momentos en los que piensas que en realidad todo ha sido un paso atrás. La costumbre de que pulsando con el botón derecho del ratón sobre tu proyecto y seleccionando la opción Desplegar todo se llevase al sitio que tocaba de manera automática ha hecho que me relaje y he estado todo el día dándole vueltas a un error que aparecía sin razón alguna y, como no, he acabado culpando a SharePoint y a Visual Studio.
Al final he hecho lo que es más aconsejable en estos casos: irme a casa, relajarme, ver una peli y, con la mente limpia… volver a revisar el problema. Y ha sido entonces cuando he empezado a ver algo de luz. Cuando generaba la solución de SharePoint 2010 no aparecía ningún error en el proceso. Visual Studio no me sacaba ningún mensaje advirtiendome de que algo no iba bien. ¿O sí lo hacía…? Pues efectivamente, lo hacía. Una rápida mirada a la salida de la generación me ofrecía la siguiente visión:
Spenta.Beezy.WebParts -> c:\code\Spenta.Beezy\Spenta.Beezy.WebParts\bin\Debug\Spenta.Beezy.WebParts.dll
------ Build started: Project: Spenta.Beezy.Receivers, Configuration: Debug Any CPU ------
Spenta.Beezy.Receivers -> c:\code\Spenta.Beezy\Spenta.Beezy.Receivers\bin\Debug\Spenta.Beezy.Receivers.dll
Error: Object reference not set to an instance of an object.
========== Build: 10 succeeded or up-to-date, 1 failed, 0 skipped ==========
Hubiera agradecido que la parte que yo he resaltado hubiera sido más evidente en la ventana de Visual Studio pero en cualquier caso hay que decir que el error era bastante claro y era el primer sitio que tenía que haber mirado después de 20 veces buscando una razón para algo inexplicable. También tendría que haberme hecho recapacitar el hecho que la fecha de última modificación del paquete generado era de hacía unas horas. En cualquier caso, viendo la raíz del problema lo siguiente era investigar la causas y, claro está, resolverlas. Y aquí volveríamos al asunto sobre el cual gira este artículo: antes hubiera ido a la ventana de MS-DOS y hubiera ejecutado unos cuantos comandos para resolver el entuerto pero… ¿Qué hago ahora que todo está tan automatizado y tan integrado?
Me disponía ya a abrir la consola de comandos para hacerlo todo a la antigua usanza cuando el poco de sentido común que me queda me hizo pensar que era imposible que Microsoft no hubiera pensado en estas situaciones, y fue entonces cuando vi algo que hasta la fecha no había visto (en parte por no haberlo necesitado, en parte por mirar siempre la pantalla en diagonal).
Cuando tenéis ese error en la ventana de salida de compilación, veréis que podéis elegir que se muestre información sobre las SharePoint Tools en el desplegable al inicio de la ventana. En mi caso, al seleccionar esa opción vi lo siguiente:
{ProjectRoot}\pkg\Debug\Spenta.Beezy\Spenta.Beezy.WebParts.dll -> GAC
EXCEPTION: Access to the path 'c:\code\Spenta.Beezy\Spenta.Beezy\pkg\Debug\Spenta.Beezy\Microsoft.Practices.Unity.dll' is denied.
{ProjectRoot}\pkg\Debug\Spenta.Beezy\Microsoft.Practices.Unity.dll -> GAC
========== Copying to GAC/BIN succeeded ==========
Como podéis ver, el error era bastante evidente y era simplemente un ensamblado que no acababa de copiarse porque algún proceso lo tenía atrapado. Claro, una vez visto el problema real, la solución apareció en cuestión de segundos y todo empezó a funcionar a las mil maravillas. Moraleja: KISS (Keep It Simple Stupid), si algo que tiene que ir, no va, antes de buscarle los tres pies al gato busca las cosas más simpels.
0 comentarios:
Publicar un comentario