XAML unificado para WPF y Silverlight con T4?

Question

Estoy escribiendo código que se usa tanto en WPF como en Silverlight. En C# puedo usar "#if SILVERLIGHT" para la compilación condicional, y funciona.

En XAML, sin embargo, debo recurrir al uso de archivos XAML completamente diferentes, ya que algunos atributos son simplemente incompatibles. Los archivos XAML son 99% similares, y mantenerlos sincronizados es una molestia.

quisiera convertirlos en una plantilla T4, por lo que puedo hacer cosas como:

<SomeControl <#=ClipsToBounds()#> /> 

Dónde ClipsToBounds() produce un texto diferente para WPF y Silverlight. Los requisitos son:

• Intellisense mientras se trabaja en el XAML
• plantillas generadas en tiempo de compilación
• El proyecto debe ser autónomo y trabajar en versión estándar de Visual Studio: instalaciones de varios SDK y editores de 3 ª parte no son aceptable
• Los resultados de la ejecución de la plantilla NO deben estar en control de fuente. -

he encontrado que puedo cambiar custom tool en un archivo XAML de MSBuild:Compile to TextTemplatingFileGenerator y no perder Intellisense. Sin embargo, las plantillas resultantes se generan en el momento del diseño. Tener entonces generado en el momento de la construcción parece un gran dolor.

¿Alguien ha tenido una experiencia exitosa con este tipo de configuración?

Answer 1

Solo los controles de usuario genéricos que tienen comportamientos genéricos en las plataformas se pueden colocar en PCL. Sin embargo, la mejor sugerencia sería mantener vistas xaml separadas para cada plataforma.

Answer 2

Dado que nadie parece haber sugerido una solución basada en plantilla como desearía, compartiré algo de experiencia trabajando con proyectos dirigidos a SL/WPF. Mucha gente sugerirá usar dos archivos XAML completamente separados, una vista diferente por plataforma, y ​​de muchas maneras esto es lo "purista" que hay que hacer. Pero si quiere eliminar la duplicación y reducir el riesgo de que sus 2 objetivos se separen, ciertamente sugeriría que compartir los archivos XAML (con enlaces de proyectos simples) puede funcionar aceptablemente bien.

Hay algunas incompatibilidades comunes: existen

• Controles en ambas plataformas en diferentes espacios de nombres - subclase su propia versión y se refieren a eso.
• Los estilos, etc. deben diferir entre las plataformas: incluyen un diccionario común de recursos, diferentes por plataforma y referencia por clave.
• Los controles son sustancialmente diferentes, o están presentes en solo 1 plataforma: introduzca su propio control de envoltura (que puede requerir una implementación sustancial en el caso de 'faltante').
• Propiedades básicas o falta de funcionalidad: a menudo puede hackear algo con un comportamiento adjunto (p. Ej., El ejemplo de ClipsToBounds se encuentra here).