Silverlight: Element is already the child of another element

Terrible, apocalíptico. Así me atrevería a calificar este recurrente y opaco mensaje de error que aparece durante la ejecución de aplicativos Silverlight, de forma aparentemente caprichosa y que no proporciona absolutamente ninguna pista qué está sucediendo ni por dónde está fallando.

 

Unhandled Error in Silverlight Application 
Code:4004 
Category: ManagedRuntimeError 
Message: System.Windows.Markup.XamlParseException: Element is already the 
child of another element [Line:0 Position: 0]

Debugar este error es imposible, puesto que se produce durante el parseo de nuestros ficheros XAML y no existe manera de obtener una InnerException más clarificadora. Los foros van llenos de gritos en el desierto clamando por una manera de encontrar el motivo de estos errores.

El post mas interesante acerca de esto parece ser: http://whydoidoit.com/2010/08/30/debug-xaml-element-is-already-the-child-of-another-element/, en que Mike Talbot nos proporciona una herramienta que efectúa un parseo controlado de un fichero XAML, para que podamos invocarla pasándole el XAML sospechoso de estar causando el error. Desafortunadamente, en los casos que he podido probar, el error obtenido sigue siendo críptico y no indica qué elemento lo está provocando.

Llegado este punto tengo que decir que, aunque no existe salvación para la humanidad (por lo menos respecto a este error), siempre nos quedará el recurso de abrazarnos a la fe. La fe en Resharper.

Resharper es una poderosa herramienta capaz de, entre otras muchas cosas, detectar y señalar los potenciales conflictos del código de nuestras aplicaciones, y esto incluye el lenguaje XAML. Desde esta tribuna, os recomiendo conocerlo y familiarizaros con él para evaluar si os merece la pena adquirirlo (recuerdo que es una herramienta de pago).

En el caso de esta entrada, Resharper sí es una salvación. “Element is already the child of another element” suele indicar, en la immensa mayoría de casos, la imposibilidad de cargar un recurso (estilo, plantilla, imagen, etc.). Pero este tipo de conflictos son detectados por Resharper y visibles desde Visual Studio:

Si, en todos los XAML de nuestro proyecto (controles de usuario, ventanas, diccionarios) nos acostumbramos a repasar y corregir las indicaciones (errores –rojo-, advertencias –amarillo- y sugerencias –verde-) y prestamos especial atención a las sugerencias (indicaciones de recursos no encontrados), localizaremos y evitaremos la mayoría de los “Element is already the child of another element”. Cierto es que Resharper puede señalar algún falso positivo en alguna advertencia (en general no detecta el atributo “ResourceKey” y si utilizamos ViewModels definidos como recursos, puede que alguno de ellos no consiga resolverlo), pero compensa sobradamente la enorme utilidad que representa el vigilar que nuestro XAML no enfade al poco descriptivo Silverlight.

Visual Studio: Error occurred in deployment step: Activate Features Failed to activate feature Xxxx at scope

Haciendo referencia a un error cuyo workaround de solución ya ha sido proporcionado por varias fuentes:

http://blog.sharepointsite.co.uk/2010/12/problem-when-deploying-soluction-in-vs.html
http://social.technet.microsoft.com/Forums/en-CA/sharepoint2010programming/thread/7df631f5-d8e8-490d-9515-21daf4c9738e

Simplemente comentar que cuando un despliegue desde Visual Studio 2010 hacia un sitio de SharePoint os empiece a martillear con el error:

Error occurred in deployment step: Activate Features Failed to activate 
feature Xxxx at scope

Comprobad, antes que nada, si esta misma feature se activa bien desde PowerShell:

Enable-SPFeature -Url http://misitio -Identity Xxxx

Si es así, el workaround es tan sencillo como cerrar e iniciar de nuevo Visual Studio.

¿Qué ocurre en el entorno de ejecución de Visual Studio para que una simple activación de feature falle? ¿Alguna referencia interna? ¿Cómo funciona exactamente el deployment step “Activate features”?

Seguiremos informando.

Herramientas para rastreo de logs de SharePoint

Rastrear los ficheros de log de SharePoint es una actividad que realizamos demasiado a menudo como para dejarnos la vista en una ventana de Bloc de notas. La inercia del día a día nos lleva muchas veces a “mirar y buscar rápido”, pero deberíamos tomar como medida no pasar más de 1 minuto de reloj examinando el log en texto plano para 1) optimizar nuestra capacidad de producción y 2) cuidar nuestra salud física y mental.

Se que muchos ya las conocemos, pero desde aquí hago recordatorio de la existencia de dos utilidades en Codeplex cuya complejidad de ejecución es simplemente copiar un .EXE, ejecutarlo y especificar el/los fichero/s a rastrear.

SharePoint Log Reader: de interfaz simple, provee de tabulación, búsqueda y filtrado de los registros (por múltiples valores); incluye botón de copia a portapapeles y lee múltiples ficheros. Es WPF. No permite ordenación.

http://sharepointlogreader.codeplex.com/

 

ULS Log Viewer: de interfaz igualmente simple, provee de tabulación, búsqueda, ordenación y filtrado de los registros (por un solo valor a la vez); lee múltiples ficheros. Es WPF.

http://ulsviewer.codeplex.com/

¿Con cuál me quedo? Quizá el filtrado por múltiples valores le da una ventaja definitiva al SharePoint Log Reader, pero ambas son opciones perfectamente válidas para su cometido.

Cambiar visibilidad de una columna de tipo de contenido

 

En un entorno MOSS 2007 ya en producción con un tipo de contenido desplegado y millones de listas referenciándolo (exageración), necesitamos hacer una modificación sobre una de las columnas; concretamente ocultarla de los NewForm y EditForm. Para ello tenemos recursos suficientes y sabemos que es posible alterarla con PowerShell, llegando a SPWeb.Fields, de ahí obtener el SPField y modificar sus propiedades ShowInNewForm y ShowInEditForm.

Pero... ¡ay! Una vez realizada la modificación vemos que en las columnas de cada lista no se ha propagado el cambio. ¿Qué sucede? Vamos a repasar el esquema de propagación:

 

Columna de sitio –> Referencia a la columna en el tipo de contenido –> Columna de lista

 

En la columna de sitio hemos conseguido establecer los valores correctos de ShowInNewForm y ShowInEditForm pero si accedemos a la colección de SPField’s del tipo de contenido los valores no han cambiado. Es decir, el esquema de propagación se ha interrumpido a nivel de tipo de contenido.

 

¿Qué podemos hacer para actualizar esas propiedades sin tener que modificar el SPField lista por lista? Uno diría: si el tipo SPContentType tiene también una colección de SPField’s, podría modificarse desde ahí. Pues no. SharePoint devuelve el siguiente mensaje:

 

This functionality is unavailable for fields not associated with a list.

 

Otro observaría: el tipo SPContentType también dispone de la colección de SPFieldLink’s, quizá desde ahí podemos acceder. Pero tampoco; no tienen pública ninguna de las propiedades ShowIn****Form.

 

Tragedia. Llanto. Desesperación. Y finalmente, el destello de esperanza. Existe una rendija de la API que permite eliminar un SPFieldLink de un tipo de contenido y volverlo a añadir, todo en una misma “transacción” (es decir, eliminar, añadir y actualizar entonces el tipo de contenido). La cosa quedaría así:

 

// Eliminamos la referencia al campo y no llamamos aún a Update
contentType.FieldLinks.Delete(fieldDisplayName);

// Obtenemos la columna de sitio (configurada ya como queremos)
SPField siteColumn = web.Fields[fieldDisplayName];

// Añadimos la referencia a la columna de sitio
SPFieldLink fieldLink = new SPFieldLink(siteColumn);
contentType.FieldLinks.Add(fieldLink);

// Ahora sí, actualizamos el tipo de contenido (y especificamos que propague cambios)
contentType.Update(true);

Funciona. Los cambios se han propagado hasta nivel de lista. Internamente hemos realizado una modificación sobre el esquema Xml de campos del tipo de contenido, pero de forma un poco tramposa. Sea como sea, objetivo cumplido.

 

StreetScene, la versión lite de StreetCare, ya está en Codeplex

Muy recientemente -tengo el honor de decir que- he colaborado junto con mis compañeros David Martos y Maria Bellmunt en el lanzamiento de la versión de código abierto para la comunidad del producto StreetCare de Spenta Consulting, una aplicación en la nube para el reporte y seguimiento de incidencias en el ámbito de colaboración ciudadana (o lo que es lo mismo, una "crowdsourcing reporting tool"). Esta "community version" se ha denominado StreetScene y su release ya está disponible para descarga en codeplex, junto con los fuentes y la documentación asociada.

http://streetscene.codeplex.com/

StreetScene está diseñado para actuar como un acelerador para el desarrollo de aplicaciones basadas en un conjunto de tecnologías clave en el cloud computing como Microsoft Windows Azure, Silverlight, AppFabric, Access Control Service, WCF Ria Services o Bing Maps SDK, combinándolas con patrones de diseño como ASP.NET MVC, MVVM o IoC (inversión de control). La intención al combinar todos estos elementos es proveer de un ejemplo en el que puedan demostrar su funcionamiento y su eficacia más allá de los "hola mundo" y de los ejemplos teóricos. StreetScene no es una aplicación final, evidentmente su look&feel y sus funcionalidades están simplificados, pero debería poder utilizarse como el inicio para construir verdaderas aplicaciones profesionales sin nada que envidiar a StreetCare.



Os animo a que le echéis un vistazo y os hagáis una idea de la potencia y las capacidades de todas estas tecnologías trabajando unidas. Podéis ver en acción las posibilidades de StreetScene en http://streetscene.cloudapp.net/.