Unified XAML für WPF und Silverlight mit T4?

Question

Ich schreibe Code, der in WPF und Silverlight verwendet wird. In C# kann ich für bedingte Kompilierung verwenden, und es funktioniert.

In XAML muss ich jedoch komplett andere XAML-Dateien verwenden, da einige Attribute einfach nicht kompatibel sind. XAML-Dateien sind zu 99% ähnlich und es ist mühsam, sie synchron zu halten.

Ich möchte sie in eine T4-Vorlage konvertieren, so kann ich Dinge wie:

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

Wo ClipsToBounds() anderen Text für WPF und Silverlight produziert. Die Anforderungen sind:

• Intellisense während der Arbeit an den XAML
• Vorlagen bei der Erstellung generierten
• Das Projekt selbst auf Lager Version von Visual Studio enthalten und Arbeit werden muß: Installationen von verschiedenen SDKs und 3rd-Party-Editoren sind nicht akzeptabel
• Ergebnisse der Vorlage ausgeführt werden sollte nicht in der Quellcodeverwaltung sein. -

Ich fand, dass ich custom tool auf einer XAML-Datei von MSBuild:Compile to TextTemplatingFileGenerator ändern kann und ich nicht verlieren Intellisense. Die resultierenden Vorlagen werden jedoch zur Entwurfszeit generiert. Zu Buildzeit erzeugt zu haben, scheint ein großer Schmerz zu sein.

Hatte jemand erfolgreiche Erfahrung mit dieser Art von Setup?

Answer 1

Nur die generischen Benutzersteuerelemente mit generischen Verhaltensweisen auf den Plattformen können in PCL platziert werden. Der beste Vorschlag besteht jedoch darin, separate XAML-Ansichten für jede Plattform beizubehalten.

Answer 2

Da anscheinend niemand eine vorlagenbasierte Lösung vorgeschlagen hat, werde ich einige Erfahrungen mit Projekten teilen, die auf SL/WPF abzielen. Viele Leute werden vorschlagen, zwei völlig separate XAML-Dateien zu verwenden, eine andere Ansicht pro Plattform, und in vielerlei Hinsicht ist dies das "Puristische". Aber wenn Sie Doppelarbeit vermeiden und das Risiko verringern wollen, dass Ihre 2 Ziele auseinanderdriften, würde ich Ihnen sicherlich empfehlen, dass die XAML-Dateien (mit einfachen Projektverknüpfungen) akzeptabel funktionieren.

Es gibt ein paar gemeinsame Unverträglichkeiten:

• Kontrollen existieren in beiden Plattformen in unterschiedlichen Namensräumen - Unterklasse eine eigene Version und dem verweisen.
• Stile usw. müssen zwischen Plattformen unterschiedlich sein - ein gemeinsames Wörterbuch von Ressourcen enthalten, unterschiedlich je Plattform und Referenz für Schlüssel.
• Die Steuerelemente sind wesentlich anders oder nur in einer Plattform vorhanden - stellen Sie Ihre eigene Wrapper-Steuerung vor (die im "fehlenden" Fall eine erhebliche Implementierung erfordern kann).
• Grundlegende Eigenschaften oder Funktonalität fehlt - kann oft etwas mit einem angehängten Verhalten hacken (zB Ihr Clips- ToBounds-Beispiel wurde gefunden here).