martes, 29 de julio de 2014

Creando una aplicación web con host header en SharePoint 2013

Antes de crear cualquier aplicación Web dentro de SharePoint para manejo de contenido es recomendado planificar como vamos a organizar el contenido. Una buena guía para ello es el plan de gobernabilidad de SharePoint.  Puede iniciar leyendo el siguiente enlace: http://technet.microsoft.com/es-gt/library/ff598584(v=office.15).aspx

Un modelo sugerido para las colecciones de sitios

A veces encuentro aplicaciones web dentro de instalaciones no planficadas con puertos raros 4534 y 3452, etc.   Y esto se debe al desconocimiento del uso de Host header que nos permite utilizar el mismo puerto 80 para diferentes aplicaciones Web.  

Abajo de SharePoint tenemos el IIS que es el Servidor Web y cuando creamos una aplicación Web en SharePoint.  SharePoint crea un Sitio Web en el IIS entonces, como diferencia el IIS a que aplicación esta solicitando el usuario si utiliza el mismo puerto 80.  Bueno a través de los Host Header habrán varios sitios Web a nivel del IIS escuchando sobre el puerto 80 pero con diferente nombre ese el el host header.

En este ejemplo ya tenemos una aplicación Web creada en el puerto 80 mysite.Infocloud.com y ahora vamos a crear otra aplicación Web en el puerto 80 llamada sharepoint.infocloud.com.

Ahora para que el navegador, el IIS y SharePoint puedan resolver este nombre necesitamos ayuda de nuestro amigo el DNS Server.  Allí debemos de registrar el nombre sharepoint.infocloud.com para que el navegador de los usuarios dentro de la red y el servidor de SharePoint donde esta el IIS puedan resolver el nombre.

Paso 1:

Debemos entonces registrar en el DNS Server el nombre sharepoint.  Con una cuenta administradora de dominio podemos accesar al servidor DNS de la organización y crear un nuevo registro Host AAAA

image

image

image

Ahora desde el servidor de SharePoint probamos el nombre para ver si nos responde:

PS C:\Users\spadmin> ping sharepoint

Pinging sharepoint.INFOCLOUD.COM [212.117.213.8] with 32 bytes of data:
Reply from 212.117.213.8: bytes=32 time<1ms TTL=128
Reply from 212.117.213.8: bytes=32 time<1ms TTL=128
Reply from 212.117.213.8: bytes=32 time<1ms TTL=128
Reply from 212.117.213.8: bytes=32 time<1ms TTL=128

Ping statistics for 212.117.213.8:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms
PS C:\Users\spadmin>

Listo ahora vamos a crear la aplicación Web desde SharePoint a través del CA.  Luego Application Management y luego Manage web applications.

image

Allí presionamos el botón New.  Se levantará una ventana de dialogo allí cambiamos el puerto por el 80, luego en Host header escribimos el FQDN que recién registramos, es decir: sharepoint.infocloud.com

image

Bueno y la parte de autenticación se la dejamos en NTLM standard Windows para autenticar y nos enfocamos en el grupo de aplicaciones para el IIS, sugiero sea separada a las otras y utilicemos una cuenta de dominio que no sea adminsitradora local sino solo una cuenta sin privilegios en mi caso SPWebApp.  Nombramos la base de datos por ejemplo: WSS_Content_PortalPrimario (Esto para mantener el estándar que dice que debemos colocar el prefijo WSS_Content_ para las bases de datos de contenido de SharePoint).

image

Presionamos el botón OK para que inicie la creación del sitio Web en el IIS y lo deje registrado en la base de datos de Configuración de la granja SharePoint_Config.

image

Listo cuando finaliza con éxito mostrará la siguiente imagen.

image

Y para que podamos acceder a ella necesitamos crear la estructura lógica para que tenga por lo menos una página destino donde dirigirse para atender las solicitudes de los usuarios.  Para ello presionamos la opción “Create Site Collection”, en vez de presionar el botón OK.

image

Ingresamos un título, la plantilla que para este ejemplo Team Site esta bien, porque tiene elementos básicos como Biblioteca, noticias y tareas.

Bueno para finalizar colocamos los administradores de la colección de sitios y listo podemos presionar el botón OK

image

Cuando termina recibiremos este mensaje.

image

Ahora si hacemos clic sobre el enlace ingresaremos al sitio con la dirección sharepoint.infocloud.com.  Si nos pide repetidas veces la clave es problema del Loopback que valida que si no es el nombre del hostname y tiene la misma ip no admite la dirección en el navegador desde el servidor.  Para deshabilitar esto en el registro de windows podemos hacerlo vía PowerShell, escribiendo la siguiente línea:

Windows PowerShell
Copyright (C) 2012 Microsoft Corporation. All rights reserved.

PS C:\Users\spadmin> New-ItemProperty HKLM:\System\CurrentControlSet\Control\Lsa -Name "DisableLoopbackCheck" -value "1"
-PropertyType dword


DisableLoopbackCheck : 1
PSPath               : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa
PSParentPath         : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control
PSChildName          : Lsa
PSDrive              : HKLM
PSProvider           : Microsoft.PowerShell.Core\Registry

Listo intentamos de nuevo y listo ya funciona.

image[59]

Si revisamos el IIS, encontraremos dos Sitios Web que escuchan en el puerto 80 pero con diferente host header

image

Listo, hemos completado nuestra misión que era tener dos aplicaciones Web escuchando sobre el puerto 80.

Por los que preguntan y la otra aplicación Web como la accedemos… bueno luego de configurar el servicio de Perfiles de Usuario, puedes en la parte superior derecha donde aparece el login del usuario conectado acceder a esta aplicación Web como lo muestro en la imagen de abajo.

image

Bueno eso es todo por este artículo.  No olvide leer el documento Plan de Gobierno de SharePoint 2013.

SharePoint4Fun!,

Juan Manuel Herrera

lunes, 28 de julio de 2014

Cómo cambiar la cuenta administradora de la granja de SharePoint

Pueda que necesitemos cambiar la cuenta administradora de la granja de SharePoint por muchas razones, pero cómo hacerlo?.

Bueno a continuación detallo el procedimiento.

Desde la Administración Central hacemos lo siguiente:

1) Hacemos clic sobre Security

2) Luego hacemos clic sobre “Manage the farm administrators group”

3) Luego presionamos el botón New y agregamos la cuenta de dominio a reemplazar.

image

4) Luego otra vez clic sobre Security

5) Luego clic sobre “Configure service accounts“ y seleccionamos Farm Account y seleccionamos la nueva cuenta y presionamos el botón OK.

image

6) Por ultimo debes de asignar permisos a las bases de datos que tenía la cuenta anterior con la nueva.

Puedes hacerlo revisando desde el Management Studio el usuario que bases de datos tiene mapeada o bien vía algún Script de T-SQL que de liste y asigne de una vez los permisos.  Eso lo dejo en sus manos amigos lectores.

Validaciones manuales:

Puedes validar que la cuenta SPFarm o como le hallas nombrado este en los siguientes grupos y/o objetos.

SPFarm debe de pertenecer a los siguientes grupos locales del servidor de Windows donde esta instalado SharePoint:

Local Adminsitrators

WSS_WPG

WSS_ADMIN_WPG

Que este ejecutando los siguientes servicios de Windows

image

A nivel de SQL Server debe de tener los siguientes roles

image

Y mapeada todas las bases de datos de Aplicación de Servicios y la configuración de la granja y el Central Administration.

image

SharePoint4Fun!,

Juan Manuel Herrera Ocheita

Evitando el error “The Application Database Server does not have the Full-Text Search feature installed.” en SharePoint 2013

 

Para el servicio de Access que fundamentalmente traduce una aplicación de Access en listas de SharePoint se requiere que la base de datos a utilizar tenga habilitado el Full-Text Search de SQL Server. 

image

Si fuese otra instancia o servidor de SQL Server donde deseamos se creen las nuevas bases de datos de las aplicaciones que Access que subiremos a SharePoint, igual debemos de validar que esta característica Full-Text Search esta instalada.

image

image

Cuando termine, recomiendo reiniciar ambos servidores e intentar de nuevo la creación de la aplicación de Servicio Access.

image

No olvide levantar el servicio en el servidor a través de SharePoint.Guiño

image

SharePoint4Fun!,

Juan Manuel Herrera

sábado, 26 de julio de 2014

Lista de verificación para levantar a la primera vez el servicio de sincronización de los Perfiles de Usuario en SharePoint Server 2013

Esto debería ser la norma pero es lo que menos frecuentemente sucede y es porque olvidamos algún paso para que suceda de esta mantera.  Abajo les detallo primero los prerrequisitos antes de intentar levantar el servicio.

I. Tener una cuenta de dominio Administradora de la granja de SharePoint (SPFarm):

1) Asegúrese de tener una cuenta de dominio para administrar la granja, por ejemplo SPFarm.

2) Asegúrese cuando ejecuto el Asistente de Tecnologías y Productos de SharePoint en la cuenta de dominio para crear la base de datos SharePoint_Config sea la cuenta administradora de la granja por ejemplo DOMINIO\SPFarm.

image

3) Que explícitamente se le de permisos a la cuenta de Permitir Logon a la cuenta con la política local del servidor.

image

image

4) Que tenga permisos de administrador local en el servidor de SharePoint.

II. Este creada la aplicación Web para hospedar los sitios de los usuarios

Debemos de crear primero la aplicación Web… solo recuerde utilizar la plantilla My Site Host (http://technet.microsoft.com/en-us/library/ee721049.aspx#UPSAProc).  También es necesario registrar la cuenta administrativa que ejecutará esta aplicación Web en SharePoint.

image

III. Utilice otra cuenta de dominio para sincronizar con el Directorio Activo

Las mejores prácticas dictan que debemos crear una cuenta de dominio sin ningún privilegio más que la delegación de permiso para replicar los cambios del directorio activo.  http://technet.microsoft.com/en-us/library/hh296982.aspx

Conceptos Erróneos

La cuenta administradora de la granja necesita permiso de Replication Directory Changes.  No es cierto, esto es para la cuenta de dominio que se utilizará para sincronizar con el directorio activo, pero no para iniciar el servicio de sincronización de Perfiles de Usuario en SharePoint.

Que la cuenta del servicio Forefront Identity Manager Service manualmente debemos de iniciarla con la cuenta cuenta de dominio administradora de la granja SPFarm, eso es falso.  Esto lo hace solito SharePoint al momento de provisionar el servicio de sincronización entre tanto tengamos los pre-requisitos cubiertos.

image

El procedimiento correcto

1) Crear la aplicación Web que hospedará “My Site”

image

2) Crear la aplicación del servicio de Perfiles de Usuario

image

3) Levantar el Servicio de Perfiles de Servicio

image

4) Levantar el Servicio de Sincronización de Perfiles de Usuario

image

Y luego de unos minutos…el servicio se levantará!… Eh…

image

SharePoint4Fun!,

Juan Manuel Herrera

lunes, 7 de julio de 2014

El programa de preestreno de Autohosted Apps venció

Noticia muy importante para desarrolladores de Apps para SharePoint en Office 356.  Definitivamente el tema de no tener control sobre los recursos en Azure de la Aplicación auto contenida integrada con SharePoint fue el mayor determinante para que Microsoft no renovará el programa o lo lanzara finalmente.  El 30 de junio del 2014 venció y no se espera que se relance aunque el comunicado de MS así lo estipula… más bien empoderarán a las Apps Tipo Provider Hosted para conectarse ambientes Azure con la libertad y control que los desarrolladores deseamos en las soluciones que construimos.

La buena noticia es que las Apps que están instaladas antes del 30 de Junio seguirán soportadas en Office 365, aunque no indefinidamente en el futuro MS publicará la fecha de caducidad, por el momento hay que prestar atención a como migrarlas a Provider Hosted y a Azure en un ambiente controlado por el usuario (para más información sobre esto ver el siguiente enlace: http://msdn.microsoft.com/EN-US/library/office/dn722449(v=office.15).aspx).  Pero las nuevas aplicaciones o las que estaban en desarrollo ya no se permitirá su uso. 

Microsoft sigue evolucionando en el nuevo modelo de Apps y escuchando a los clientes y desarrolladores para responder a las necesidades del mercado.  Esperamos que podamos ver un modelo maduro ágil y efectivo.

Hice algunas pruebas y esto fue el resultado:

Una aplicación de Prueba Auto Hosted sigue funcionando en SP 2013

image

image

Si le cambio de versión y la actualizó también me lo permite como dice el artículo:

<App xmlns="http://schemas.microsoft.com/sharepoint/2012/app/manifest"
     Name="SharePointAutoHostedApp"
     ProductID="{c990646d-33a7-4aee-9ea3-e4e288ce7e88}"
     Version="1.2.0.0"
     SharePointMinVersion="16.0.0.0"
>

clip_image001

Al parecer todavía es permitido subir Apps Auto Hosted hasta esta fecha aquí los pantallazos que lo prueban

image

 

image

image

image

image

 

Para más información puedes ver el artículo en el siguiente enlace:

http://blogs.office.com/2014/05/16/update-on-autohosted-apps-preview-program/

Apps4Fun!,

Juan Manuel Herrera Ocheita

miércoles, 25 de junio de 2014

Autohosted App

Estas Apps o Aplicaciones están diseñadas hasta el momento únicamente para suscriptores de Office 365 ya que se hospedan de forma automática y sin poder contralar los recursos asignados en Windows Azure, por ello Microsoft no ha hecho disponible que este tipo de Apps puedan ofrecerse en Microsoft Office Store, por lo que quedan fuera hasta el momento, Microsoft no ha descifrado como proveer la asignación de los recursos en Azure y como cobrar los recursos asignados a las aplicaciones de SharePoint hospedadas en Windows Azure.  El problema es más complejo de lo que parece ya que están hospedados en alguna ubicación que prácticamente es tierra de nadie y que dependiendo de la ubicación del Office 365 asumo así asignarán en Azure la ubicación ya que no esta a la vista de los mortales.

Uno de los atractivos de este tipo de Aplicaciones es que podemos escribir código en el lenguaje de .NET de nuestra preferencia  C# o VB.  Aunque siempre debemos de invocar el modelo de objetos cliente CSOM cuando necesitamos acceder algún recurso de lado de SharePoint Online ya que como es un App corremos con las mismas limitaciones.  Ahora bien por otro lado como esto es hospedado en Windows Azure y esta corriendo en este, podemos cambiar el modelo de la Aplicación Web de Web Forms (Como es la forma standard de SharePoint) a ASP.NET MVC para los amantes de este modelo de desarrollo de aplicaciones Web. ya que prácticamente la aplicación en Windows Azure es incrustada dentro de un IFRAME en SharePoint, pero esta realmente corriendo en Windows Azure.

Aquí interviene otro amigo para validar los permisos para ejecutar las llamadas de CSOM al portal de SharePoint llamado OAuth que es el protocolo standard para validar permisos entre diferentes “dominios” (Windows Azure / SharePoint Online).  Esto requiere conocer un conjunto de nuevas instrucciones para invocar y consumir los recursos de SharePoint que no necesitamos en el tipo de Apps SharePoint Hosted que invocamos a través de Java Script ya que este esta hospedado en el mismo domino SharePoint Online.

Bueno empecemos con nuestra primera App Autohosted, para ello invocamos Visual Studio 2013 (con Update 2 recomendado).

Luego seleccionamos la opción New Project… y dependiendo que plantilla de lenguaje escogimos deberemos de buscar la categoría Office/SharePoint, luego Apps y allí Apps for SharePoint.

image 

Escriba un nombre de aplicación a su elección y presione el botón OK.  Luego le preguntará la dirección URL de SharePoint Online donde desea instalar la aplicación. 

image

Recomiendo utilice una colección de sitios de desarrollo para que pueda hacer pruebas de depuración y sea sencillo el deployment del App (Para los que no tiene acceso a la administración de Office 365, es necesario solicitar al administrador que cree en SharePoint una colección de sitios de este tipo abajo la imagen que muestra el formulario de creación de una nueva colección de sitios).

image

De regreso en la ventana para especificar la ubicación de donde va instalarse la App es necesario indicar el tipo y aquí es donde debemos de seleccionar Autohosted.

image

Luego nos pregunta que tipo de Aplicación Web deseamos Web Forms o MVC.  Le sugiero elija la que esta habituado a desarrollar ya que de lo contrario le costará adaptarse al nuevo modelo.  Una vez dominado el nuevo modelo ya puede seleccionar el que desconoce así no tendrá  el stress de entender un nuevo modelo además de la infraestructura de SharePoint necesaria para ejecutar este tipo de aplicaciones.  Para este ejemplo seleccionaremos Web Forms.

image

Luego levantará una ventana de dialogo para autenticarnos a Office 365.  Si necesita una cuenta de Office 365 de prueba o en planes que permitan el desarrollo de Apps en SharePoint, creo que son las E1…E4.

image

La primera ventana en aparecernos es la página Default.aspx de la aplicación.

image

Si vemos hacia la esquina derecha donde aparece el contenido del proyecto creado desde la ventana del Explorador de la Solución veremos dos proyectos.  El proyecto de SharePoint que servirá para enmascarar el proyecto Web que será hospedado en Windows Azure.  De lado de SharePoint tenemos dos elementos básicos la imagen de la aplicación que utilizará para desplegarla una vez instalada y el manifiesto de la aplicación que es una declaración en XML.  De lado de la aplicación Web de forma predeterminada nos incluye las librerías de Jquery, la página Default.aspx, el archivo de configuración de la aplicación web.config, como el del empacado de la aplicación packages.config además dos archivos de código para manejar el contexto de SharePoint y la seguridad.

image

Ahora veamos que podemos encontrar en el manifiesto de la aplicación de SharePoint

image

En la pestaña General encontraremos el Titulo de la aplicación, el nombre interno de la aplicación, la versión que estamos instalando, el icono de la aplicación, la página de inicio, la cadena de consulta que se incluirá en la URL de la aplicación {StandardTokens} (esta incluye la URL del App, del sitio Host entre otros).  Ahora veamos la pestaña de Permisos.

image

En la casilla Scope o Alcance definimos el recurso o servicio de SharePoint que vamos a utilizar dentro de la aplicación y luego el Permiso que requerimos (Lectura, Escritura, Administración o Control Total).

image

Esto deberá de ser consultado en las referencias de MSDN de Microsoft para obtener el permisos correcto para consumir un servicio o la combinación de estos http://msdn.microsoft.com/en-us/library/office/fp142383(v=office.15).aspx.

NOTA: Mucho cuidado con el permisos que le damos a la aplicación este antes de instalarse el usuario será preguntado si permite conceder los permisos que solicita la aplicación para su uso.  Si los permisos son muy elevados el usuario podría denegar los permisos y no instalar la aplicación.  A parte la aplicación vía código deberá manejar los permisos sobre los recursos que se crean para proteger la información dentro de la aplicación. 

image

Otro tema importante es saber que los permisos que requiere la aplicación se refiere a un Sitio Web o a una lista es sobre el Host Web es decir al sitio Web donde se adicionó el App.  En el caso de Autohosted recuerde que el App esta hospedado en Windows Azure y no en SharePoint. 

El terminó App Web para el caso de las Autohosted no aplica ya que esta se refiere a un sitio Web en SharePoint para el App donde se pueden crear listas, bibliotecas y páginas.  Esto no es aplicable para Autohosted ya que es una aplicación Web que esta hospedada en Windows Azure y tiene recursos como una base de datos y una aplicación ASP.NET no de SharePoint.  Por lo que si requerimos crear una biblioteca será en el Host Web y no el App Web como sucede en las Apps de tipo SharePoint Hosted.

Pestaña de Prerequisitos, en esta pestaña definimos los recursos que utilizaremos de lado de Windows Azure y de SharePoint la versión mínima requerida para ejecutar la aplicación.  Deforma predeterminada incluye de lado de Windows Azure Web Site, pero podemos agregar SQL Database si planeamos almacenar alguna información en base de datos de Azure (Por el momento son los dos únicos recursos disponibles en Azure disponibles para aplicaciones Autohosted). De lado de SharePoint repetiremos los servicios que incluimos en la pestaña de permisos pero con la versión mínima requerida si así deseamos definir la aplicación.

image

En la pestaña de idiomas soportados o Supported Locales, definiremos el idioma que soporta la aplicación y el archivo de recursos con el diccionario de términos que la aplicación reemplazará dependiendo de la ubicación donde se instale y este disponible.  Para ello es necesario desarrollar la aplicación para que en vez de escribir el texto , se definan etiquetas que hagan referencia aun terminó maestro con el prefijo “$Resources:” y este sirva para mapear en el archivo de recursos el terminó en el idioma disponible en la aplicación.

image

Para más información sobre crear Apps para SharePoint en diferentes idiomas puede ver el siguiente enlace: http://msdn.microsoft.com/en-us/library/office/fp179919(v=office.15).aspx

Cuando no se define ningún idioma soportado en la pestaña de Supported Locales el predeterminado es inglés.

Pestaña de Remote Endpoints o Extremos remotos son utilizados para especificar el dominio remoto. El proxy web valida que las solicitudes emitidas a dominios remotos se declaran en el manifiesto de la aplicación. Puede crear hasta 20 entradas y solo se considera en la URL la parte de la autoridad emisora por lo que el resto es omitida.  Con ello puede utilizar una sola URL para consumir diferentes recursos dentro de la misma y evitar la validación de seguridad de dominios cruzados o Cross-domain.  Para más información puede consultar el siguiente enlace: http://msdn.microsoft.com/en-us/library/office/fp179895(v=office.15).aspx

image

Si seleccionamos el archivo de manifiesto desde el explorador de la solución y presionamos el botón derecho del ratón y escogemos la opción para Ver Código o View Code, podremos ver la declaración en XML de lo configurado.

 

image

Aquí se nos muestra otra información que nos es ocultada como el ProductID y la versión mínima de SharePoint soportada por la aplicación que en el caso de SharePoint Online es la 16 ya que es una versión que esta más actualizada que la ofrecida en la versión para instalarla localmente.

image

Bueno ya casi terminamos el alcance de este artículo introductorio.  Por lo que vamos a modificar únicamente la página default.aspx para ejecutar la aplicación y revisar como luce. 

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="SharePointApp1Web.Default" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title></title>
</head>
<body>
    <form id="form1" runat="server">
    <div>
        Hola Mundo!
    </div>
    </form>
</body>
</html>

Para ello vamos a agregar las Palabras Hola Mundo! y revisar como se muestra con solo presionar la tecla F5.

Me pregunta si deseo otorgar los permisos solicitados por el App.

image


Le indico que si confío o Trust It.  Y la aplicación es desplegada

image

Otra forma de hacer un deploy menos automático y un poco manual es de la siguiente manera:

1) Desde Visual Studio 2013 en el Explorador de la Solución haga clic derecho y seleccione la opción Deploy Solution

image

Esta operación desinstalara la versión anterior y instalará de nuevo la solución en la URL que indicamos que lo hiciera cuando creamos el proyecto.

Luego volverá a preguntar si confiamos en la solución.

image

A diferencia de la opción anterior el App lo deja instalado y podemos verlo a través de la opción Site Contents de SharePoint.

https://infowareplus.sharepoint.com/sites/mherrera/_layouts/15/start.aspx#/_layouts/15/viewlsts.aspx

image

Si hacemos clic sobre el App nos ejecutará la aplicación y nos llevará a la página Default.aspx

image

Si desglosamos la URL notaremos los siguientes valores:

https://eb0185ff-11b6-443e-bce5-ba6e4632ceca.o365apps.net/Pages/Default.aspx

?SPHostUrl=https%3A%2F%2Finfowareplus%2Esharepoint%2Ecom%2Fsites%2Fmherrera

&SPLanguage=en-US

&SPClientTag=0

&SPProductNumber=16%2E0%2E2930%2E1220

El ID del App y luego los siguientes parámetros: SPHostUrl,  SPLanguage, SPClientTag, SPProductNumber.

El único parametro no explicado hasta ahora es SPClientTag y se refiere a: El número de control de caché de cliente (etiqueta de cliente) para el sitio web actual.

Bueno eso es todo por este artículo en los siguientes profundizaremos temas como incluir el branding del SharePoint en ejecución a través del control chrome y como invocar los recursos de SharePoint desde una aplicación Autohosted que se hospeda en Windows Azure.

Apps4Fun!,

Juan Manuel Herrera Ocheita