XAML unificato per WPF e Silverlight utilizzando T4?

Question

Sto scrivendo il codice che viene utilizzato sia in WPF che in Silverlight. In C# posso usare "#if SILVERLIGHT" per la compilazione condizionale e funziona.

In XAML, tuttavia, devo fare ricorso a file XAML completamente diversi, poiché alcuni attributi sono semplicemente incompatibili. I file XAML sono del 99% simili e tenerli sincronizzati è una seccatura.

vorrei convertirli in un modello T4, in modo da poter fare le cose come:

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

Dove ClipsToBounds() produce un testo diverso per WPF e Silverlight. I requisiti sono:

• Intellisense durante il lavoro sui modelli XAML
• generate al momento della compilazione
• Il progetto deve essere autonomo e il lavoro sulla versione di scorta di Visual Studio: installazioni di vari SDK e redattori 3rd party non sono accettabili
• I risultati dell'esecuzione del modello NON devono essere nel controllo sorgente. -

ho scoperto che posso cambiare custom tool su un file XAML da MSBuild:Compile to TextTemplatingFileGenerator e non perdere Intellisense. Tuttavia, i modelli risultanti vengono generati in fase di progettazione. Avere poi generato in fase di costruzione sembra un grande dolore.

Qualcuno ha avuto esperienza di successo con questo tipo di installazione?

Answer 1

Solo gli utenti generici che hanno comportamenti generici attraverso le piattaforme possono essere inseriti in PCL, tuttavia, il miglior suggerimento sarebbe mantenere viste xaml separate per ogni piattaforma.

Answer 2

Dal momento che nessuno sembra aver suggerito una soluzione basata su modelli come desiderato, condividerò alcune esperienze di lavoro con progetti rivolti sia a SL/WPF. Molte persone suggeriscono di utilizzare due file XAML completamente separati, una diversa visualizzazione per piattaforma e in molti modi questa è la cosa "purista" da fare. Ma se vuoi eliminare la duplicazione e ridurre il rischio che i tuoi 2 obiettivi si allontanino, ti suggerirei sicuramente di condividere i file XAML (con semplici collegamenti di progetto) che funzionano in modo accettabile.

ci sono un paio di incompatibilità comuni: esistono

• controlli in entrambe le piattaforme in diversi spazi dei nomi - sottoclasse la propria versione e si riferiscono a questo.
• Gli stili, ecc., Devono differire da una piattaforma all'altra: includono un dizionario comune di risorse, diverso per piattaforma e riferimento per chiave.
• I controlli sono sostanzialmente diversi o presenti in una sola piattaforma: introdurre il proprio controllo wrapper (che potrebbe richiedere un'implementazione sostanziale nel caso "mancante").
• Mancano le proprietà di base o la functonality - può spesso modificare qualcosa con un comportamento collegato (ad esempio, l'esempio ClipsToBounds viene trovato here).