NullReferenceException en Microsoft.Office.Server.Administration. UserProfileApplicationProxy. get_ApplicationProperties

23.6.11 / Comments (1) / by Enric Carrión

Puede suceder que, accediendo a un sitio por navegador o través de la API (configurando navegación o accediendo al UserProfileManager), nos aparezca esta NullReferenceException provocada por el método get_ApplicationProperties de Microsoft.Office.Server.Administration.UserProfileApplicationProxy. Un posible stack trace puede ser:

Object reference not set to an instance of an object

at Microsoft.Office.Server.Administration.UserProfileApplicationProxy.get_ApplicationProperties()
at Microsoft.Office.Server.Administration.UserProfileApplicationProxy.get_PartitionIDs()
at Microsoft.Office.Server.Administration.UserProfileApplicationProxy.IsAvailable(SPServiceContext serviceContext)
at Microsoft.Office.Server.Audience.AudienceManager.IsCurrentUserInAudienceOf(AudienceLoader audienceLoader, String audienceTextRepresentation, Boolean showUntargetedAudience)
at Microsoft.SharePoint.Publishing.Navigation.PortalSiteMapNode.GetNavigationChildren(NodeTypes includedTypes, NodeTypes includedHiddenTypes, Boolean trimmingEnabled, OrderingMethod ordering, AutomaticSortingMethod method, Boolean ascending, Int32 lcid)
at Microsoft.SharePoint.Publishing.Navigation.PortalSiteMapNode.GetNavigationChildren(NodeTypes includedTypes, NodeTypes includedHiddenTypes, OrderingMethod ordering, AutomaticSortingMethod method, Boolean ascending, Int32 lcid)
at SetNavigationFeatureReceiver.SetNavigationFeatureReceiver.SetNavigation(SPFeatureReceiverProperties properties)
at SetNavigationFeatureReceiver.SetNavigationFeatureReceiver.FeatureActivated(SPFeatureReceiverProperties properties)
at Microsoft.SharePoint.SPFeature.DoActivationCallout(Boolean fActivate, Boolean fForce)

Bien, las pistas para la solución las da este post:

http://social.technet.microsoft.com/Forums/en/sharepoint2010setup/thread/bdb0ea0e-13f1-4191-8f92-9d2fc2605115


En principio, el usuario que ejecuta ese código (depende del contexto será el usuario logado al sitio, el que ejecuta la aplicación, el owstimer, el usuario del pool, ...) debería tener permisos suficientes sobre la User Profile Service Application.

Lo que se propone es que, si se está ejecutando desde Visual Studio, el usuario desarrollador logado en sesión Windows debería ser administrador de la User Profile Service Application y ser administrador de granja. Bien, yo añado sobre esto que es necesario realizar un IISRESET (no parece suficiente con reiniciar el app pool) para que empiece a funcionar.

SharePoint 2010 no hace caso de los anchor tags al cargar la página

23.6.11 / Comments (0) / by Enric Carrión

Tema candente en la comunidad forera de SharePoint, con aportaciones frescas en:

http://sharepoint.stackexchange.com/questions/10994/sharepoint-2010-and-anchor-tags
http://social.msdn.microsoft.com/Forums/en/sharepoint2010general/thread/f7eab808-da8a-44fd-9933-f9b992f5affc

La situación es que, al cargar una página de publicación o wiki con un anchor (es decir, mipagina.aspx#mianchor, donde mipagina tiene un <a id="mianchor" name="mianchor"></a>), SharePoint no pone el foco en dicho anchor sino arriba del todo de la página. Motivo: código javascript incrustado y ejecutado por el propio SharePoint. Categoría: probablement un bug de producto. Workaround: complicado. A falta de bucear en las procelosas aguas de los eventos javascript de la plataforma para intentar reescribir la función que causa este desaguisado, la única propuesta surgida en la comunidad es:
<script type="text/javascript">
 setTimeout(Reload,2000);
 function Reload()
 {
  window.location.hash=self.document.location.hash.substring(1);
 }
</script>

Es decir, un timeout que vuelva a "cargar" la página, lo que fuerce de nuevo el cambio de foco a nuestro anchor. ¿Funciona? Sí. ¿Es elegante? No. ¿Al cargar produce un efecto raro de foco arriba y abajo? Sí. ¿Seguiremos informando cuando podamos dar con una solución mejor? No hay duda.

Post dedicado a Carlos Giol.

Content query web part: The query cannot be completed because the number of lists in the query exceeded the allowable limit

1.6.11 / Comments (1) / by Enric Carrión

Bueno, una perla más de conocimiento adquirida gracias a la experiencia empírica de comprobar cómo un sitio de producción que funciona perfectamente, después de crear un nuevo subsitio, empieza a mostrar en web parts de consulta de contenido el siguiente mensaje:

There is a problem with the query that the web part is using. Check the configuration of the web part and try again.

Mirando el log de SharePoint aparece la siguiente excepción:

The query cannot be completed because the number of lists in the query exceeded the allowable limit.

Después de agotar la sarta de improperios producto del momento de tensión, la solución encontrada es localizada rápidamente y puesta en funcionamiento con éxito.

  • El límite de listas soportadas en un CQWP cross-site (o SPSiteDataQuery) por defecto es 1000.
  • Ese límite se puede ampliar al valor deseado o poner a 0 (infinito) pero mucho ojo con los efectos colaterales de rendimiento.
  • En un SPSiteDataQuery podemos usar directamente la propiedad MaxListsLimit para establecer ese valor.
  • En un CQWP debemos establecer la propiedad ListsOverride del web part a:
  • <property name="ListsOverride" type="string">
    <![CDATA[<Lists ServerTemplate="#ID_TEMPLATE_LISTA#" MaxListLimit="#LÍMITE#">]]>
    </property>

ID de templates de lista. Los más comunes:

100 Generic list

101 Document library

102 Survey

103 Links list

104 Announcements list

105 Contacts list

106 Events list

107 Tasks list

108 Discussion board

109 Picture library

119 Wiki Page library

301 Blog Posts list

302 Blog Comments list

303 Blog Categories list

850 Page Library

Más en http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.splisttemplatetype.aspx

 

Info extraída de http://technet.microsoft.com/en-us/library/cc263061(office.12).aspx#Content_query