Error occurred in deployment step 'Recycle IIS Application Pool': The local SharePoint server is not available

Estos días he tenido que pelearme un poco con un servidor MSS2010 de desarrollo debido al error que da el título a este artículo, os pongo en antecedentes:

Situación inicial

Estamos desarrollando una WebPart para MSS 2010, nada fuera de lo común, una WebPart sencillita, cuyos detalles además no vienen al caso.

Por motivos que tampoco vienen al caso, el desarrollo se estaba realizando con un usuario ‘genérico’ mediante escritorio remoto. Todo funcionando de lujo hasta que otro compañero necesita conectar en remoto también con ese usuario, como ya sabréis no puede haber (creo) dos conexiones remotas distintas con el mismo usuario (si se puede ya me avisaréis).

El caso es que ya no se puede desarrollar con el dichoso usuario ‘genérico’… Ningún problema, inicio el escritorio con mi usuario, mapeo el código de TFS y a funcionar…

El problema

El proyecto se abre sin problema, compila de lujo (como era esperado) pero (siempre hay un pero) al ir a realizar el despliegue de la Web Part, de repente mensaje de error:

y en los detalles del error en la ventana de “Error List”:

Ay ay ay, uy uy uy…

Menos mal que nos queda Google… Revisando por ahí posibles soluciones al problema, resulta que el error viene (lógico por otra parte) por un problema de permisos de mi usuario en la infraestructura Sharepoint del servidor de desarrollo.

La solución

Gracias al siguiente artículo, el problema se soluciona utilizando el comando Add-SPShellAdmin.

¿Cómo lo utilizamos para solucionar el problema?

Iniciamos una consola de administración de Sharepoint y ejecutamos el comando:

Add-SPShellAdmin dominio\usuario

Puede producirse un error de conexión con el servidor local (el mismo que nos da desde Visual Studio) si se produce no nos queda otra que pedir que nos ejecuten el comando con el usuario ‘genérico’

Una vez ejecutado el comando, al intentar realizar el despliegue, puede producirse el siguiente error:

Si revisamos el visor de sucesos del servidor, podemos ver que se trata de un acceso denegado con la Base de Datos de contenido del servidor Sharepoint. Para solucionar este problema, tenemos que utilizar el mismo comando anterior, especificando el id de la Base de Datos de Contenido que nos indica en el visor de sucesos.

Averiguar el ID de la Base de Datos de contenido

Ejecutamos el siguiente comando PowerShell:

Get-SPDatabase | Select Name, Id

Localizamos el nombre que hemos obtenido en el Visor de Sucesos, y apuntamos el Id, que utilizaremos en la siguiente instrucción:

Add-SPShellAdmin dominio\usuario –database Id

 

y con esto, a funcionar!!!

Instalar una aplicación web ASP.NET en un sitio de Sharepoint 2010

Una de las preguntas que vuelve de tiempo en tiempo es ¿Cómo ponemos una aplicación ASP.NET en un sitio web que esté ocupado por Sharepoint?
La respuesta en principio es sencilla, basta con generar un directorio virtual en el sitio web de Sharepoint en el que alojar la aplicación.
Peeeero, es muy probable que nos aparezcan errores relacionados con el archivo web.config de la aplicación, ya que como ya sabemos los archivos web.config se van heredando en la estructura IIS, y el primer web.config que aparece en la estructura es el de Sharepoint, que añade sus entradas (y que normalmente interfieren con nuestra aplicación)
A continuación vamos a ver una serie de posibles problemas que podemos encontrar y una solución ‘sencilla’ para los mismos.

NOTA: Los errores que vamos a ver a continuación, ni son todos los que están, ni están todos los que son. Conforme vayamos encontrando más problemas, los iremos añadiendo a la lista.

Security Exception

Uno de los primeros errores que podemos encontrarnos es este, provocado por la configuración de seguridad del sitio web.

Solución

Cuidadito, porque igual esto no podemos / debemos hacerlo a la ligera.
En el web.config de la aplicación indicamos explícitamente el nivel de confianza de la aplicación, como por ejemplo:
<system.web>
….
    <trust level="Full" originUrl="" />
</system.web>

Problemas con la sesión

Otro problema que podemos encontrarnos tiene que ver con las variables de sesión, ya que Sharepoint gestiona las sesiones de una manera específica.

Solución

En el web.config de la aplicación añadimos el módulo ‘estándar’ de gestión de la sesión de .net:
<system.webServer>
…
    <modules>
    …
        <add name="Session" type="System.Web.SessionState.SessionStateModule" />
    </modules>
</system.webServer>
A continuación configuramos las páginas de la aplicación para habilitar la gestión de la sesión:
<system.web>
…
    <pages enableSessionState="true">
…
    </pages>
…
</system.web>

A funcionar (por el momento)

Cómo acceder a una aplicación ASP.NET externa desde Sharepoint

Situación inicial

No preguntéis por qué, pero surgió la necesidad de acceder desde un servidor Sharepoint 2010 a una aplicación ASP.NET alojada en otro servidor, ambos accesibles desde internet y en distintos dominios.
Pongamos que la ruta de acceso al servidor Sharepoint 2010 era “www.mss2010.es” y la ruta de acceso a la aplicación era “aplicacion.aplicaciones.es”

Solución sencilla

Nada complicado, vamos al servidor Sharepoint, añadimos una Web Part “Visor de Páginas” y configuramos la URL de acceso para que muestre la página de inicio de la aplicación. ¡Listo!

Problema

¿Listo? Noooo. Una vez realizada la operación, podemos observar que la aplicación externa hace (perdón por la expresión) ‘cosas raras’. Por ejemplo:
Al acceder a la aplicación, almacenamos una serie de información en variables de sesión (de nuevo, no preguntéis por qué) que luego se utilizan en distintas páginas de la aplicación. Cuando accedemos a la aplicación directamente desde el navegador web, todo funciona sin problemas, pero al acceder a la aplicación desde el Visor de Páginas de Sharepoint 2010, esas variables de sesión NO se mantenían al navegar por la aplicación; es más, cada página a la que accedemos dentro de ese visor reiniciaba la sesión en la aplicación externa
Después de mirar y remirar por ahí, llegamos a la conclusión de que este funcionamiento es correcto. ¿Por qué? el navegador de internet (en este caso Internet Explorer, y no, por favor no preguntéis por qué) detecta que estamos incluyendo en una página de un dominio (www.mss2010.es) un marco (el visor de páginas) cuya información proviene de otro dominio (aplicacion.aplicaciones.es) esta operación por defecto es considerada como ‘insegura’ en las zonas de sitios de confianza e Internet.

¿Cómo lo solucionamos?

La opción “sencilla” pasaría por configurar los clientes para que tanto el sitio web de Sharepoint como el de la aplicación estuvieran en la zona de Intranet Local…
¿Perdón?¿Hola? estamos en Internet, NO podemos hacer eso!
La segunda posibilidad pasa por poner las dos aplicaciones en el mismo dominio de Internet (reconozco que no lo he probado, porque en este caso no era una posibilidad)
La tercera opción es modificar la aplicación web para que se identifique como ‘segura’ ante el navegador de internet, pero claro, cuidado porque para hacer esto tenemos que poder modificar la aplicación externa. En este caso podíamos hacerlo, así que lo hicimos.

Al turrón

Entiendo que habrá múltiples maneras de hacerlo, pero resultó muy sencillo modificar el archivo global.asax de la aplicación externa para que cuando se inicia la petición a la aplicación, ésta añada un encabezado concreto a la petición HTTP que marque la aplicación como segura. Por ser más ‘puristas’ este es un extracto en inglés explicando un poco más el tema:

Starting in Internet Explorer 6 support for the Platform for Privacy Preferences (P3P) Project was introduced. The P3P standard notes that if a FRAMESET or a parent window references another site inside a FRAME or inside a child window, the child site is considered third party content. Internet Explorer, which uses the default privacy setting of Medium, silently rejects cookies sent from third party sites. So consequently a large percentage of your visitors may end up having an unhappy experience on your site.
You can add a P3P compact policy header to your child content, and you can declare that no malicious actions are performed with the data of the user. If Internet Explorer detects a satisfactory policy, then Internet Explorer permits the cookie to be set.

Al final, el método en el evento “Application_BeginRequest” queda como se ve a continuación (ojo, que está en VB.NET)
Sub Application_BeginRequest(ByVal sender As Object, ByVal e As EventArgs)
    HttpContext.Current.Response.AddHeader("p3p", "CP=""CAO PSA OUR""")
End Sub

Una vez añadido el evento y compilada y publicada la aplicación externa, el sistema comienza a funcionar de nuevo…

Cómo conectar Visual Studio 2008 con TFS 2010

Este es un mini post con las instrucciones básicas para conseguir conectar Visual Studio 2008 con proyectos en Team Foundation Server 2010.

Al turrón

1. Instalar el Service Pack 1 de Visual Studio 2008
2. Instalar la actualización para TFS 2010 (Visual Studio 2008 SP1 Compatibility Update for TFS 2010)
3. Instalar el Team Explorer (Visual Studio Team System 2008 Team Explorer)

Estos tres primeros pasos son ‘opcionales’ lógicamente si ya tenemos instalado el Service Pack 1, el paso 1 nos lo podremos saltar, así como la instalación del Team Explorer si ya lo tenemos o si la versión de Visual Studio 2008 es la “Team Suite”

Lo último que hay que hacer es añadir manualmente el servidor de TFS. Para esto, en el registro de Windows tendremos que añadir la entrada correspondiente a dicho servidor. ¿Dónde?

1. Navegamos a la entrada “[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\TeamFoundation\Servers]”
2. Creamos un nuevo Valor de Cadena y en el nombre ponemos el nombre del servidor, y en el valor ponemos la url de acceso al TFS, como podemos ver en la captura posterior.
3. Creamos una nueva Clave con el nombre del servidor utilizado en el paso 2.
4. En la nueva Clave, creamos dos valores DWORD con las características de la tabla que aparece más abajo

Y ya estamos listos para conectar desde Visual Studio al servidor TFS, abriendo la ventana del Team Explorer y seleccionando el servidor entre la lista de disponibles.

Más información:

Registro del servidor TFS (Paso 2)

Datos de configuración del servidor (Paso 4)

Nombre	Valor
AutoReconnect	1
Offline	0

 

Si tenemos que hacer esta configuración en varios equipos, es conveniente generar un archivo .reg para automatizar la modificación del registro, este sería el contenido con los datos que hemos utilizado:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\TeamFoundation\Servers]
"ServidorTFS"="http://servidorTFS:8080/tfs/ProjectCollection"

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\TeamFoundation\Servers\ServidorTFS]
"Offline"=dword:00000000
"AutoReconnect"=dword:00000001

Selección del servidor en Team Explorer:

Visual Studio y el misterio de las plantillas desaparecidas

Hoy al arrancar Visual Studio (2010) me he encontrado con la siguiente sorpresa (muy desagradable, por cierto) al ir a generar un nuevo proyecto:

¿Dónde están mis plantillas de proyecto? Sudores fríos por la espalda… menudo comienzo de día ¡Socorro!

Al turrón

Tras el primer momento de pánico, he recordado que Visual Studio proporciona una serie de parámetros de ejecución del IDE (devenv.exe) que permiten por ejemplo resetear las personalizaciones realizadas al Visual Studio, regenerar paquetes instalados, etc.
Investigando un poquillo, he encontrado lo que necesitaba:

1. Cerramos Visual Studio.
2. Iniciamos el “Visual Studio Command Prompt (2010)” (Como Administrador en Windows Vista / 7)
3. Ejecutamos devenv.exe /installvstemplates.
4. Esperamos a que termine (para asegurarnos, lo mejor es abrir el Task Manager y esperar a que el proceso “devenv.exe *32” desaparezca.
5. Arrancamos Visual Studio, y

Ya está!!! Sencillo ¿verdad? ahora lo único que queda pendiente es averiguar por qué de buenas a primeras habían desaparecido prácticamente todas las pantallas de proyectos (tengo un par de componentes sospechosos, pero si llego a alguna conclusión la haré pública.

NOTA: Este comando se puede ejecutar mínimo desde la versión de Visual Studio 2005.

Probar aplicaciones en un dispositivo iOS

O como comenzar a programar sin pasar por el AppStore

¿Cuál es el problema?

Este artículo tiene la intención única de explicar una posibilidad “desconocida” al menos para mí relacionada con el desarrollo de aplicaciones para dispositivos iOS. Lo vi en varios sitios que no voy a indicar aquí por si acaso.

Las versiones utilizadas en esos artículos eran las siguientes:

Mac OS X 10.6.6

Xcode 3.2.5

 

En principio, cuando desarrollamos una aplicación para dispositivos iOS, la única opción “gratuita” que tenemos es probar dicha aplicación en el simulador integrado en el sistema. Esto es más que suficiente en la mayoría de los casos, pero existen situaciones en las que se queda un poco corto (por ejemplo, interactuar con el GPS)

En condiciones normales, cuando comenzamos el desarrollo de este tipo de aplicaciones, tenemos que ‘comprar’ una licencia a Apple, que nos puede dar derecho tanto a publicar nuestra aplicación en el AppStore como a configurar hasta 100 (me suena que eran 100) dispositivos ‘autorizados’ para realizar pruebas. ¿Qué sucede si no tenemos esa licencia?

La licencia es una suscripción anual y puede ser que únicamente queramos realizar pruebas antes de comenzar el desarrollo ‘en serio’, pero necesitando poder probar ‘en vivo’ las aplicaciones.

¡OJO! Reconozco que no tengo ni idea de si este procedimiento es legal o no, cada cual que haga lo que quiera, yo sólo he visto que existe esta posibilidad y quería recogerla en el lenguaje de Cervantes. Si alguien me advierte de que esto es ilegal, lo elimino y aquí paz y después gloria, que aquí estamos para aprender!

Proceso

Lo primero que se indica es que el dispositivo que queremos utilizar para realizar pruebas tiene que tener hecho el proceso de Jailbreak. Esto ya puede suponer un problema, ya que en función de la versión de iOS del dispositivo, es posible que no se pueda hacer jailbreak. Además del Jailbreak, es dispositivo por lo visto necesita tener instalada la aplicación “AppSync”

Una vez que cumplimos con esos requisitos, arrancamos nuestro MAC

Al turrón

Mediante el “Acceso a Llaveros” generamos un nuevo certificado:

1. Acceso a Llaveros
2. Asistente para certificados
3. Crear un certificado
4. El certificado a crear tiene que ser de tipo “Raíz autofirmada”.

Una vez generado el certificado, tenemos que realizar una modificación a un archivo de configuración de Xcode:

1. Finder
2. Developer
3. Platforms

Una vez en la carpeta “Platforms” elegimos con qué plataforma de las disponibles queremos trabajar (por ejemplo “iPhoneOS.platform”

¡OJO! En los artículos que he visto no mencionaban si alguna de las plataformas es incompatible con este método, supongo que si no funciona habrá que googlear un poco.

Editamos el archivo “Info.plist” (abridlo mejor con “TextEdit” y, lógicamente, guardad antes una copia del archivo)

Localizamos una de las secciones <dict>, concretamente la que comienza con la línea:

<key>ARCHS</key>

A continuación de las líneas:

<key>PLIST_FILE_OUTPUT_FORMAT</key>

<string>binary</string>

Introducimos las siguientes líneas:

<key>PROVISIONING_PROFILE_ALLOWED</key>

<string>NO</string>

<key>PROVISIONING_PROFILE_REQUIRED</key>

<string>NO</string>

A continuación, ejecutamos Xcode y abrimos el proyecto que queremos depurar.

¡OJO! Estos pasos hay que repetirlos en todos los proyectos que queramos depurar en un dispositivo físico, recordad que por regla general es suficiente con el simulador integrado.

1. Menú Project
2. Edit Project Settings
3. Pestaña Build
4. Sección Code Signing

En las propiedades “Code Signing Identity” y “Any iOS” establecemos el certificado local que creamos en su momento para montar todo este tinglado.

Y para acabar, en el desplegable del proyecto, elegimos el dispositivo en lugar del simulador y a jugar!!!

Consideraciones finales

Otra vez quiero indicar que desconozco si esta práctica es 100% legal, en principio realizar un Jailbreak a un dispositivo iOS es legal, aunque se pierde la garantía del aparato. El resto de pasos son cambios a archivos de configuración, con lo que entiendo que no debería suponer ningún problema.

Seguiré vigilando el tema y en el momento en el que tenga sospechas de la legalidad del mismo, actualizaré el artículo en consecuencia.

Ahora sí, para terminar, una ‘pequeña’ justificación, no he podido / querido utilizar capturas de pantalla, ya que yo no he probado el procedimiento y tampoco quería utilizar capturas de terceros.

Generar builds en TFS para proyectos de Sharepoint

O cómo compilarlos automáticamente sin morir en el intento.

Los últimos días he retomado el desarrollo de componentes para Sharepoint, que tenía bastante “oxidado” y como no podía ser de otra manera, he integrado el proceso de desarrollo dentro del TFS 2010. La situación que tenía (para tener claro de qué estoy hablando) era la siguiente:

• Equipo de desarrollo: Windows 2008 R2 de 64 Bits.
• Sharepoint Server 2010 instalado en el equipo de desarrollo.
• Visual Studio 2010.
• Servidor de fuentes: Team Foundation Server 2010.

 

Pasos Previos

Lógicamente antes de nada, hay que realizar las operaciones clásicas cuando utilizamos TFS (creación del Team Project, rama Main, etc.)

Hasta aquí nada nuevo bajo el sol, estuve realizando el componente (en este caso una WebPart) y llegó la hora de probarlo en el entorno de Preproducción.

Para la instalación en ese entorno, únicamente utilicé el WSP que genera Visual Studio al ‘empaquetar’ el proyecto de Sharepoint, pero se me ocurrió que tenía que ser posible utilizar las Builds de TFS para que ese paquete WSP se genere automáticamente, como el resto de productos alojados en TFS.

La verdad es que no resultó tan sencillo como yo esperaba, aunque los problemas y pasos para solucionarlos tienen mucho sentido.

Primer intento

Lo primero que intenté fue lo típico, generé una nueva Build Definition, y la ejecuté… Resultado:

Como vemos, al realizar la compilación el agente detecta que en el proyecto hay referencias que no le gustan, o que no conoce, vamos, que no existen en el servidor…

Esto es normal, ya que ni Visual Studio ni, por supuesto, Sharepoint están instalados en el servidor de compilación.

Segundo intento

Como no funcionó, tocó “googlear” un rato, y lo primero que encontré fue un “apunte” en el que indicaba que con una Build Definition ”normal” no se conseguía generar el WSP para el componente. Para solucionar ese problema, es suficiente con añadir el parámetro “/p:IsPackaging=True” en la sección de “MSBuild Arguments” de la Build Definition:

Pero aún hay más, encontré una pequeña ‘maravilla’ que en principio simplifica el proceso. Dicha maravilla es un script de Powershell que en un primer paso permite coger los ensamblados de Sharepoint de la máquina de desarrollo, y en una segunda pasada los copia y registra en el servidor de compilación. No voy aquí a repetir los pasos de ejecución de dicho script, ya que está suficientemente explicado aquí, pero baste una captura para ver el resultado de la compilación una vez ejecutado el script tanto en la máquina de desarrollo como en el servidor de compilación:

Bueno, tampoco íbamos a esperar que funcionase a la primera no?

Lo que ha pasado es que el script que hemos ejecutado sólo coge los ensamblados básicos de Sharepoint:

"Microsoft.SharePoint.dll"
"Microsoft.SharePoint.Security.dll"
"Microsoft.SharePoint.WorkflowActions.dll"

Como nuestro proyecto es una Web Part que hereda de un tipo de "Microsoft.Office.Server.Search.dll", tendremos que añadir dicho ensamblado en la sección “$Script:SharePoint14ReferenceAssemblies” del script que hemos ejecutado.

NOTA: Al ejecutar el nuevo script en la máquina de desarrollo es posible que nos dé un error de que ese ensamblado no se puede localizar, si es el caso, basta con copiarlo desde la carpeta ISAPI de Sharepoint a la carpeta “Files” que se genera al ejecutar el script (si no sabes dónde está la carpeta ISAPI, creo que te has equivocado de post)

Al final, después de pruebas y error, llegamos al…

Tercer intento

En el script mágico tuve que añadir los siguientes ensamblados en la sección que indicaba antes:

"Microsoft.Office.Server.dll"
"Microsoft.Office.Server.Search.dll"
"System.Web.DataVisualization.dll"

Tras ejecutarlo en el servidor de compilación, lanzamos la Build y:

¡Por fin! ya tenemos compilaciones automáticas desde TFS 2010 de proyectos para Sharepoint; además, podemos observar en la carpeta de los Drops que la compilación ha generado el paquete WSP:

Nota final

Como podemos ver en la última captura, la Build no sólo genera el paquete WSP, sino que también está llevando a la carpeta de Drops los ensamblados que hemos añadido durante el proceso. He investigado un poquillo y parece ser que se podrían eliminar de dicha carpeta en uno de los pasos del Workflow de la Build Definition, pero reconozco que no he ahondado más en el tema. Si por lo que sea llegamos a tener problemas de espacio, podemos borrar todos esos ensamblados de las distintas compilaciones. Oye, aunque tengamos que borrarlos a mano, sigue siendo mejor que lo que teníamos antes no?