En algunos escenarios (por ejemplo en migraciones de datos y entornos), es posible que necesitemos actualizar o asignar los campos de sistema de los elementos de una lista de SharePoint.

Los campos de sistema, serían: Creado, Creado por, Modificado y Modificado por.

Os paso el código necesario para actualizar el campo Creado, de un item de una lista.

En el código anterior tan sólo accedemos a la lista que nos interesa, y llamamos al método de actualizar:

Fijaros en que hacemos uso de la clase SPBuiltInFieldId Esta clase nos permite acceder a los IDs de todos los campos de SharePoint que vienen OOB.

Ojo, aunque existe una propiedad de esta clase que es: “Created_x0020_By”, el campo que realmente almacena lo que vemos en el item como “Creado por”, es el campo “Author”.

Fijaros como aparece un item que he creado desde la interfaz de SharePoint:

Y así quedaría cuando ejecutamos el código:

PD: No lo he probado en Office 365, pero si lo usamos en un webpart y sacamos el SPWeb del contexto, debería funcionar igual, ya que el resto de operaciones son permitidas en modo Sandbox.

Saludos!

Actualmente he estado trabajando en una Feature que creaba varias propiedades administradas en el buscador. Como he tenido que probarlo bastante para asegurarme que funcionaba bien en varios entornos, me hice un script power shell que las eliminaba.

Os paso el script por si a alguien le puede ser útil:

Saludos!!

Pues eso, que cuidado. Ale, hasta luego!

Si necesitas crear Scripts power shell para algún proyecto de SharePoint, seguramente lo más cómodo es que puedas hacerlo usando Visual Studio. Tienes varias posibilidades a la hora de trabajar con ficheros PS1 desde Visual Studio. A groso modo:

• Crearlo como fichero de texto con extensión .PS1. Y no necesitas nada más. No tendrás sintaxis coloreada, ni debug paso a paso, pero funciona.
• Instalar alguna extensión para Visual Studio. Algunas que pintan bien:
  • Power GUI: Disponible desde el administrador de extensiones de Visual Studio. Antes de instalar el add-in, hay que instalar el Power GUI (como tal). Este pluggin nos dará intellisense, sintaxis coloreada, un tipo de proyecto para scripts power shell, etc.
  • Power Studio: Muy similar al anterior.

Yo personalmente uso el Power Studio, pero porque lo encontré primero.

Sin embargo, tras la última actualización del power studio, ahora tengo un error cuando intento abrir un fichero PS1. Entonces, lo que hice fue, “abrir con” sobre el fichero

Y elegir la consola de Power Shell ISE.

Power Shell ISE es la consola gráfica de Microsoft para Power Shell, y que podéis instalar desde la opción de añadir características de Windows. Pinta así:

También tiene depuración, colorea, y tal y tal.

Sin embargo, al abrir Power Shell ISE desde Visual Studio, al ejecutar mis scripts power shell de SharePoint, me encuentro con el siguiente error:

El motivo era que Visual Studio me abría el Power Shell ISE de 32 bits, y los scripts de SharePoint necesitan la versión de 64 bits. Una vez abierto el Power Shell ISE x64, todo funcionó a la primera.

Si queréis añadir el Power Shell ISE para x64 desde Visual Studio, estas son las rutas:

x64: C:Windowssystem32WindowsPowerShellv1.0

x86:    C:WindowssysWOW64WindowsPowerShellv1.0

Saludos!!

Si necesitas realizar ciertas operaciones con el buscador de SharePoint, de forma programática, como por ejemplo crear nuevos scopes de búsqueda, necesitarás obtener un objeto SearchServiceApplication.

En algunos ejemplos de internet, he visto un código como este:

¿“Osearch14”?… ¿“Search Service Application”?

No sé vosotros, pero yo, cuando veo algún string “a piñón”, me entran los tembleques. Más aún, cuando en el caso de SharePoint, el “Search Service Application”, es el nombre que se le ha dado a la aplicación de servicio de búsqueda, y que no solo depende de cómo se haya instalado el servicio, sino que, en el caso de que se utilice el nombre por defecto que pone el asistente de instalación, también será diferente, según el idioma de la instalación.

Si lo que queremos, es conectarnos al servicio de búsqueda, del site en el que estamos trabajando, podemos hacer lo siguiente (partimos de un SPSite, que podemos recuperar del contexto de SharePoint, o abrir el sitio concreto):

De esta forma, estamos tirando del contexto, y no tenemos que “picar” ningún nombre concreto.

Espero que os sirva.

Saludos!!

Este post (más bien Tip) es totalmente válido en modo Sandbox, por lo que sirve para desarrollos en Office365.

Si vemos ejemplos de código para insertar/actualizar items en listas de SharePoint, en la mayoría de los casos nos encontraremos algo como:

Creamos el SPListItem, damos valor a sus campos, y finalmente, llamamos al método Update, para hacer el “Commit” definitivo.

Ahora bien, ¿qué ocurre si queremos actualizar algunos campos de la lista, pero conservar los valores originales en las columnas de sistema “Modified” and “Modified By”? Pues podemos utilizar otro método de la clase SPListItem, llamado SystemUpdate

De esta forma podemos actualizar un elemento sin modificar estos cambios. Incluso tiene una sobrecarga para no actualizar tampoco la versión del item.

Saludos!!