Para aquellos que no estén familiarizados con linq 2 sharepoint, os recomiendo este link con un sencillo “Get Started”:

• SP 2010: Getting started with LINQ to SharePoint in SharePoint 2010 

Como veréis en el link, se hace referencia a la herramienta de SharePoint SPMetal, que nos permite sacar entidades tipadas de nuestras listas de SharePoint (similar a lo que hace Entity Framework con una base de datos).

Ahora bien, si intentamos lanzar la herramienta SPMetal contra un site de Office 365, veremos que nos dará un error de acceso denegado, a pesar de haber utilizado los comandos de useremoteapi, user y password

Al parecer, según comentan los ingenieros de MS del foro de soporte de Office 365, la herramienta SPMetal no está diseñada para funcionar con sitios de SharePoint Online.

Sin embargo, Linq to SharePoint sí está soportado en desarrollos sandbox, tal y como podemos ver en este enlace: http://msdn.microsoft.com/en-us/library/hh147180.aspx

La pena es que sin SPMetal, tiene poca utilidad.

Si tenéis mucho interés en utilizar linq2sp en vuestros desarrollos para Office 365, y disponéis de algún servidor SharePoint on-premise, podéis utilizar un sencillo truco para hacerlo.

Lo que yo he hecho (sólo por probar si era viable. no he hecho nada serio), ha sido:

• Crear una lista en mi SharePoint Online. Ejm. Products
• Guardamos esa lista como plantilla y la exportamos a nuestro sitio de SharePoint on premise.
• Desde SharePoint On Premise, ejecutamos SPMetal, y usamos el parámetro /parameters que nos permite pasarle un fichero XML con un esquema predefinido que permite configurar mucho la forma en que SPMetal genera las clases desde las listas. Esto nos ayudará a generar código sobre las listas o tipos de contenido que nos interese, evitando posibles problemas de tipos entre el sitio completo de Office 365 y el de OnPremise. Yo he utilizado el siguiente fichero XML, para generar el código únicamente de la Lista de Products

• SPMetal detectará posibles dependencias entre tipos de contenido, y añadirá todo lo necesario para generar las entidades a partir de la lista Products, como por ejemplo, incluyendo una entidad para el tipo de contenido “Item”, ya que la lista de products hereda de ese tipo de contenido.
• Una vez generado el fichero de código, ya lo podemos añadir a nuestra solución de usuario en Visual Studio y probarlo.
• Para las pruebas, he creado un webpart visual en modo sandbox, con 2 botones que ejecutan una sencilla consulta LINQ y sacan ítems de la lista Products.

• Este es el código utilizado:

De esta forma, si vuestro requerimiento de usar linq 2 sharepoint es muy fuerte, se puede llegar a conseguir.

Para acabar, comentar una curiosidad que me ha pasado durante estas pruebas. Inicialmente he intentado usar un GridView de asp.net para mostrar la información, configurando el DataSource al resultado de la query de Linq, y dejando la propiedad AutoGenerateColumns a true. Esto no me ha funcionado, ya que el GridView, de forma interna, ha intentado generar las columnas usando Reflection, y esas operaciones no están permitidas en la Sandbox.

Espero que os sirva.

Saludos!!

Como ya sabemos, cuando en Visual Studio 2010 creamos un nuevo proyecto de SharePoint, nos da la opción de desplegar en modo granja, o en modo sandbox:

Si hemos elegido el modo granja, y posteriormente queremos pasar a modo sandbox, podemos hacerlo desde las propiedades del proyecto:

Y ya está? pues sí, pero que sepáis, que automáticamente, Visual Studio, ha modificado el archivo assembly.info, añadiendo esta línea:

y esto es importante, porque como os contaba en este otro post esto es necesario para todos los componentes que queremos ejecutar en la sandbox.

Para acabar, si además estamos migrando una solución que ya tenía código, tendremos que asegurarnos de que todo lo que hacemos está permitido en la sandbox. En esta url tenemos detallados los namespaces y clases permitidas en sandbox: http://msdn.microsoft.com/en-us/library/ee537860(office.14).aspx

Espero que os sirva.

Saludos!!!

En este post (más bien nota), aclaro algunos de los procesos del sistema relacionados con SharePoint, y que podremos utilizar a la hora de adjuntar el depurador de Visual Studio 2010 y debuguear alguno de nuestros desarrollos:

• w3wp.exe: este es sin duda el más conocido. Nos adjuntaremos a él para depurar la mayoría de los desarrollos de SharePoint en modo Farm: Webparts, Manejadores de eventos, Workflows…
• owstimer.exe: este es el encargado de los Timers de SharePoint. Nos adjuntaremos a él para depurar nuestros jobs de SharePoint personalizados.
• spucworkerprocess.exe: en este proceso corren nuestras soluciones sandbox, así que nos debemos adjuntar para depurar nuestros desarrollos sandbox y por lo tanto, todo lo que queramos subir a Office 365

Si os estáis preguntando para qué sirve el proceso spucworkerprocessproxy.exe, es el encargado de recibir las peticiones del spucworkerprocess.exe y ejecutar las llamadas al modelo de objetos completo de SharePoint. En principio no es necesario para los debugs. Lo tenéis mucho mejor explicado aquí.

Espero que os sirva.

Saludos!!

Por todos es conocido la facilidad que nos proporciona Visual Studio 2010 para trabajar con controles de usuario de ASP.NET, a través de la opción de carpeta mapeada de SharePoint:

Y luego, desde nuestro webpart podemos cargar el control de usuario que queramos, si hacemos:

Sin embargo, si dentro de nuestro UserControl, queremos insertar otro UserControl que también tenemos en la carpeta mapeada, podemos encontrarnos con problemas para que Visual Studio lo “entienda” y nos deje compilar, sobre todo, si el UserControl “hijo” no ha sido desplegado todavía dentro de SharePoint.

Imaginemos el caso en el que hemos arrancado un nuevo proyecto de Visual Studio, hemos mapeado la carpeta ControlTemplates, y hemos creado 2 user controls, donde el ChildUserControl.ascx se utiliza dentro del ParentUserControl:

Ahora, en el control padre, añadimos el Register de toda la vida, pero vemos que Visual Studio no lo reconoce.

Para solucionarlo, hacer un Deploy de la solución. Aunque no os reconozca el Tag, os dejará compilar y hacer el deploy. Después de hacer el deploy, los ascx se colocarán en la carpeta de SharePoint, entonces, cerramos Visual Studio y lo volvemos a abrir, ya nos reconocerá el control y podremos usar el intellisense.

Y comprobamos que funciona la anidación:

Espero que os sirva.

Saludos!!

Como os decía el otro día, el pasado Jueves estuve en el CEUS VII celebrado por Microsoft.

Os paso la presentación que hice en una de los talleres técnicos de la tarde.

Si tenéis cualquier duda, quedo a disposición.

Para acabar, tan solo deciros que el CEUS estuvo bastante bien en líneas generales, y os dejo un post de mi compañero Hugo de Juan con una reflexión más larga e interesante que la mía

Tarde o tempano, trabajando con SharePoint, necesitaréis crear una vista sobre una lista o bibliteca, y agruparla por tipo de contenido. Algo que en MOSS 2007 se hacía facilísimo con las características OOB, en SharePoint 2010 (tanto Online, como OnPremise) se complica, ya que esta funcionalidad OOB ha desaparecido.

En la siguiente imagen podemos ver todas las opciones OOB que tenemos a la hora de agrupar, cuando se crea una vista en SharePoint:

Fijaros como no tenemos la opción de agrupar por tipo de contenido. Sin embargo, el campo Tipo de contenido sí lo podemos añadir para mostrarlo en la vista:

Pues bien, después de goglear un poco, he encontrado mucho posts con una misma solución. Os paso este mismo

Yo no lo he probado, sin embargo, la solución parece estar tan extendida por la red, que confío en que funcione. Sin embargo, esta solución es para usuarios avanzados, y no es sencilla de ser aceptada por un usuario “no avanzado”.

Existe otra alternativa que no está muy difundida, probablemente porque está en la página 4 de los resultados de búsqueda de Google, y ya se sabe que más allá de la página 2, sólo se llega si se está muy muy desesperado

Se trata de una Feature que está en codeplex, que funciona en modo Sandbox, y que con sólo activar la feature, ya tenemos disponible la opción de agrupar por tipo de contenido. Aquí tenéis el link:

http://sp10ctgrouping.codeplex.com/

y aquí algo más de detalle de cómo funciona. Básicamente inserta un javascript para añadir esa opción en el desplegable, con el valor exacto que espera SharePoint. Ingenioso, sí señor!!

Lo he probado en mi sitio de grupo de SharePoint Online, y funciona a las mil maravillas.

Espero que os sirva.

Hasta pronto!!

Tal y como ya ha contado Alberto, el jueves 10 de Noviembre se celebra la séptima edición de CEUS

En esta edición, entre otros patrocinadores, también está ENCAMINA y voy a tener la suerte de poder participar en los talleres paralelos de la tarde.

Ponencia: SharePoint como CMI colaborativo para hospitales
Horario: 16:30h
Sala: Roma II

y justo después, a las 17h, en la sala Madrid II, estaré compartiendo mesa redonda con los grandes de SharePoint:

Espero veros por allí!

Saludos.

En este post vamos a ampliar el post anterior para conseguir el mismo efecto, es decir, una nueva opción en el menú de Site-settings que nos lleve a la página principal de la administración del sitio de SharePoint Online, pero esta vez lo haremos todo desde código .NET. Así, podemos hacer el vínculo dinámico, según la URL de cada sitio de Office 365, y empaquetarlo como una pequeña funcionalidad.

Para ello, creamos un proyecto vacío de SharePoint, y añadimos una nueva feature:

Seguidamente, le añadimos un EventReceiver:

Descomentamos los eventos que nos interesan:

Y en el FeatureActivated, añadimos el código necesario para crear la CustomAction:

Como veis, hemos hecho uso de la clase SPUserCustomAction, que permite crear una nueva acción, y que tiene unas propiedades prácticamente idénticas a las que teníamos en el XML del post anterior.

Para sacar la URL del portal de admin, y que como ya vimos tiene el formato: portal-admin.sharepoint.com, me he creado una pequeña función que devuelve esa cadena, partiendo de la propia URL del SPWeb (no me he calentado mucho los cascos, supongo que se podrá optimizar):

La última consideración sobre el código, es que al ser creada desde código, conviene que podamos eliminarla, tb desde código, cuando se desactiva la Feature. Como veremos ahora mismo, para eliminar una Custom action desde código, debemos conocer su Guid interno. Cuando la creamos desde XML, ese Guid se lo podemos asignar “a mano”, pero desde código esto no es posible, ya que lo hace internamente SharePoint. Es por ello que debemos guardarnos de alguna forma el Guid de la nueva Custom Action, para que en el momento de desactivar la feature, lo podamos hacer.

Yo he elegido almacenar el GUID en el PropertyBag del propio SPWeb. Esto se consigue con este código:

Donde:

Es una simple constante que me he definido a nivel de Feature, para la Key de la PropertyBag.

Para acabar, aquí tenemos el código del desactivado:

Como vemos, sacamos el Guid de la PropertyBag, y eliminamos la CustomAction correspondiente.

Y nada más, generamos el WSP, lo subimos al sitio de SPOnline, y activamos la Feature.

Y como me acabo de empezar a leer la biografía de Steve Jobs, sólo puedo acabar diciendo: “Stay hungry, stay foolish!”

Pues eso, que no sé a vosotros, pero a mi me parece un poco lata que para poder saltar a la administración del sitio de grupo, o bien haya que saberse la URL (que como ya sabéis, se compone de [nombre_portal]-admin.sharepoint.com), o bien haya que ir al portal de administración de Office 365, y una vez allí, pinchar en el enlace que hay para ello:

Para solucionarlo, y de paso trastear un poco con las CustomActions para Office 365, me he creado una acción para abrir el menú de administración desde el propio “Site Actions” del sitio de grupo:

Para conseguir esto, tan solo necesitamos que el Elements.xml de nuestra feature, sea:

Recordar que tenéis que sustituir en la UrlAction, el $portal$ por el nombre de vuestro portal.

Consejo del abuelo cebolleta

Cuando desplegamos artefactos en SharePoint (tanto OnLine como OnPremise), que no tengan “code-behind” (ficheros xml, imágenes, otros ficheros, etc), es recomendable que hagamos esto en las propiedades del proyecto de SharePoint:

Esto evitará que la .dll generada por Visual Studio (una .dll que no tiene ninguna funcionalidad), se incluya en el paquete.

Y, ¿Si quiero saber más de las Cutom Actions y cómo personalizar la Ribbon?

Pues como siempre, nuestro Gurú Juan Carlos González tiene una serie de post muy buenos.

y algunos otros también muy buenos:

• Otra serie de posts de Chris O’brien
• Ejemplos de Localizaciones de Custom Actions: Una de las cosas que menos clara está a la hora de hacer una Custom Action, es cómo posicionarla en el punto de SharePoint que te interesa. Este recurso tiene ejemplos visuales de esas localizaciones. Están basados en WSS 3.0, pero son igual de válidos para SharePoint 2010.

Espero que os sirva.

Saludos!!