Limitaciones en la serialización de XamlWriter.Save
La API Save se puede usar para serializar el contenido de una aplicación de Windows Presentation Foundation (WPF) como un archivo XAML. Pero existen algunas limitaciones notables relativas a qué se serializa exactamente. En este tema se documentan estas limitaciones y algunas consideraciones generales.
Representación en tiempo de ejecución, no en tiempo de diseño
La filosofía básica de lo que se serializa mediante una llamada a Save es que el resultado será una representación del objeto serializado, en tiempo de ejecución. Muchas propiedades en tiempo de diseño del archivo XAML original pueden haberse optimizado o perdido para cuando el XAML se carga como objetos en memoria, y no se conservan cuando se llama a Save para realizar la serialización. El resultado serializado es una representación efectiva del árbol lógico construido de la aplicación, pero no necesariamente del XAML original que lo ha generado. Estos problemas hacen que sea sumamente difícil usar la serialización de Save como parte de una superficie de diseño XAML extensa.
Autonomía de la serialización
El resultado serializado de Save es autónomo. Todo lo que se serializa está contenido dentro de una sola página XAML, con un elemento raíz único, sin referencia externa alguna a excepción de los URI. Por ejemplo, si en la página se hace referencia a recursos de los recursos de la aplicación, estos aparecerán como si se tratara de un componente de la página serializada.
Desreferenciación de extensiones
El proceso de serialización desreferenciará las referencias comunes a los objetos realizadas por diversos formatos de extensión de marcado, como StaticResource
o Binding
. Estas referencias ya se habían desreferenciado al crear los objetos en memoria en el tiempo de ejecución de la aplicación, y la lógica de Save no repite el XAML original para restaurar estas referencias en el resultado serializado. Esto inmoviliza potencialmente todos los valores obtenidos de los recursos o enlazados a datos en el último valor usado por la representación en tiempo de ejecución, y únicamente se dispone de una capacidad limitada o indirecta para distinguir este valor de cualquier otro establecido localmente. Las imágenes también se serializan como referencias de objeto a las imágenes tal cual existen en el proyecto, en lugar de como referencias originales del código fuente, con lo que se pierden los nombre de archivo o URI a los que se hizo referencia originalmente. Incluso los recursos declarados dentro de la misma página aparecen serializados en el punto donde se ha hecho referencia a ellos, en lugar de conservarse como una clave de una colección de recursos.
No se conserva el control de eventos
Cuando se serializan controladores de eventos que se agregan mediante XAML, no se conservan. XAML sin código subyacente (y sin el mecanismo relacionado x:Code) no dispone de ninguna manera de serializar la lógica de procedimiento en tiempo de ejecución. Dado que la serialización es autónoma y se limita al árbol lógico, no existe ningún medio para almacenar los controladores de eventos. Como resultado, los atributos de controladores de eventos, tanto el propio atributo como el valor de cadena que da nombre al controlador, se quitan del XAML de salida.
Escenarios realistas para el uso de XAMLWriter.Save
Aunque las limitaciones enumeradas aquí son bastante importantes, existen varios escenarios en los que es adecuado usar Save para la serialización.
Salida vectorial o gráfica: la salida del área representada se puede usar para reproducir el mismo vector o gráfico al volver a cargarla.
Documentos de texto enriquecido y dinámicos: el texto y el formato y la contención de todos los elementos se conservan en la salida. Esto puede ser útil para los mecanismos afines a la funcionalidad del Portapapeles.
Conservación de datos de objetos comerciales: si se han almacenado datos en elementos personalizados, tales como datos XML, los objetos comerciales se pueden perpetuar mediante la serialización siempre que sigan determinadas reglas básicas de XAML, como proporcionar constructores personalizados y conversión para valores de propiedades por referencia.
.NET Desktop feedback