Was ist die beste Praxis für in einem Projekt Silverlight und WPF kompiliert?

Question

Ich habe gerade ein Silverlight-Projekt abgeschlossen und es ist Zeit, ein wenig aufzuräumen zu haben. Ich möchte meine Core-Dateien nehmen und sie in ein separates Projekt gesteckt, die ich von meinem Haupt-Silverlight-Anwendung verweisen wird. Einige dieser Klassen sind kompatibel mit WPF und ich würde ganz der Lage sein, wie Silverlight / WPF-Code alle in einem Projekt zu haben. Meine ideale Lösung wäre ein einzelnes Projekt, das mehrere Konfigurationen ermöglicht. Also,

Konfiguration: Silverlight erzeugen würde: Company.Controls.Silverlight.dll

Konfiguration: WPF erzeugen würde: Company.Controls.Wpf.dll

Ist es möglich, die gleiche Quelle in der gleichen Datei nur über definiert getrennt hat?

Hat jemand dies getan vor?

Edit: Ich habe eine Lösung pro Projekt erstellt, wie MyCompany.Windows.Controls, die dann zwei Projekte enthält, MyCompany.Windows.Controls & MyCompany.Windows.Controls.Silverlight. Neben diesen zwei Ordnern habe ich einen „Shared“ -Ordner, die Dateien, die von beiden Projekten verwendet wird, enthält. Es funktioniert gut, so weit:)

Answer 1

Ich habe es selbst nicht ausprobiert (immer noch versuchen, die Zeit zu finden, mit Silverlight zu spielen), kann aber nicht Sie haben eine Lösung mit zwei Projekten, ein Targeting-Silverlight und die andere die gemeinsamen .NET 3.5, und fügen Sie Targeting Klassendateien für jedes Projekt als Verbindungen (rechts~~POS=TRUNC auf das Projekt, Vorhandenes Element hinzufügen ..., hinzufügen als Verknüpfung)?

** Update: Siehe Mark Antwort unterhalb das Projekt Linkers in Bezug auf. Ich habe das schon mit meiner Multi-targetted Composite Application mit dem PRISM 2.0 CAL und es ist eine schöne Sache. Ich glaube nicht, das in PRISM 1.0 existierte?

Answer 2

Update: geht zu zeigen, dass es fast immer ist ein einfacher Weg. : -)

Der erste Schritt ist die bedingte Kompilierung zu verwenden, um den Silverlight-spezifischen Code zu trennen. (Ich gehe davon aus, dass Ihr "default" Ziel mit wäre WPF).

Zweitens, werden Sie ein Build-Skript benötigen, die den Code für jede Plattform kompilieren, die entsprechenden definiert und Montage Referenzen zu setzen.

Werfen Sie einen Blick auf die Open-Source- Caliburn Projekt . Es tut alles.

Hier ist ein Beispiel aus Caliburn der Extension Klasse.

    public static T GetResource<T>(this FrameworkElement element, object key)
        {
            DependencyObject currentElement = element;

            while (currentElement != null)
            {
                var frameworkElement = currentElement as FrameworkElement;

                if (frameworkElement != null && frameworkElement.Resources.Contains(key))
                    return (T)frameworkElement.Resources[key];

#if !SILVERLIGHT
                currentElement = (LogicalTreeHelper.GetParent(currentElement) ??
                    VisualTreeHelper.GetParent(currentElement));
#else
                currentElement = VisualTreeHelper.GetParent(currentElement);
#endif
            }

            if (Application.Current.Resources.Contains(key))
                return (T)Application.Current.Resources[key];

            return default(T);
        }

Wenn Sie Caliburn in VS öffnen und kompilieren, entspricht es gegen den Standard-Framework. Die Referenzen sind für .NET 3.5 und WPF, Silverlight nicht. Das ist auch, warum die Vorbearbeitung Richtlinien sind „! SILVERLIGHT“.

In Ihrem Build-Skript (Caliburn nutzt NAnt), werden Sie ein Ziel haben, die definiert für jede Plattform setzt zum Beispiel Caliburn Silverlight-Ziel ist:

<target name="config-platform-silverlight20">
    <property name="nant.settings.currentframework" value="silverlight-2.0"/>
    <property name="build.platform" value="silverlight-2.0"/>
    <property name="build.defines" value="${global.build.defines},SILVERLIGHT,SILVERLIGHT_20,NO_WEB,NO_REMOTING,NO_CONVERT,NO_PARTIAL_TRUST,NO_EXCEPTION_SERIALIZATION,NO_SKIP_VISIBILITY,NO_DEBUG_SYMBOLS"/>
    <property name="current.path.bin" value="${path.bin}/silverlight-2.0/${build.config}"/>
    <property name="current.path.test" value="${path.bin}/silverlight-2.0/tests" />
    <property name="current.path.lib" value="${path.lib}/Silverlight" />
</target>

Dann ist hier das Ziel, dass die tatsächliche Silverlight Build aufrufen:

<target name="platform-silverlight20" depends="config">
    <if test="${framework::exists('silverlight-2.0')}">
        <echo message="Building Caliburn ${build.version} for Silverlight v2.0."/>
        <call target="config-platform-silverlight20"/>
        <copy todir="${current.path.bin}">
            <fileset basedir="${current.path.lib}">
                <include name="*.dll"/>
                <include name="*.xml"/>
            </fileset>
        </copy>
        <call target="core"/>
        <call target="messaging"/>
        <call target="actions"/>
        <call target="commands"/>
        <call target="package-platform"/>
    </if>
    <if test="${not(framework::exists('silverlight-2.0'))}">
        <echo message="Silverlight v2.0 is not available. Skipping platform."/>
    </if>
</target>

Schließlich, hier ist ein Beispiel für das „Kern“ Ziel, das für die Herstellung des Caliburn.Core.dll verantwortlich ist:

<target name="core" depends="config, ensure-platform-selected">
    <mkdir dir="${current.path.bin}"/>
    <csc keyfile="${path.src}/Caliburn.snk" noconfig="true" warnaserror="false" target="library" debug="${build.debug}" optimize="${build.optimize}" define="${build.defines}"
     output="${current.path.bin}/Caliburn.Core.dll"
     doc="${current.path.bin}/Caliburn.Core.xml">
        <sources basedir="${path.src}">
            <include name="${build.asminfo}"/>
            <include name="Caliburn.Core/**/*.cs"/>
        </sources>
        <references basedir="${current.path.bin}">
            <include name="mscorlib.dll"/>
            <include name="System.dll"/>
            <include name="System.Core.dll"/>
            <!--WPF-->
            <include name="PresentationCore.dll"/>
            <include name="PresentationFramework.dll"/>
            <include name="WindowsBase.dll"/>
            <!--Silverlight-->
            <include name="System.Windows.dll" />
        </references>
        <nowarn>
            <warning number="1584"/>
        </nowarn>
    </csc>
</target>

Beachten Sie die Art und Weise es Referenzierung die notwendigen Baugruppen.

Sie werden wahrscheinlich benötigen NAnt.exe.config bearbeiten (wenn Sie NAnt verwenden), um die richtige Version des Silverlight Rahmen anzupassen. Für Silverlight RTW wird die Framework-Version 2.0.31005.0 sein.

    

Answer 3

Sie sollten check out "Muster & Praktiken: Composite-WPF und Silverlight"

http://www.codeplex.com/CompositeWPF/Wiki /View.aspx?title=Home

Es hat schnelle Starts mit WPF / Silvelight Versionen des gleichen App in einer Lösung. Auch ein „Projekt Linker“, die die Quelle Ihrer WPF-Anwendung aktualisiert, wenn Sie Silverlight-Code (oder umgekehrt) mit Verknüpfung ändern. Es kann außer Kraft gesetzt werden, wenn Sie versionsspezifischen Code haben.

Die Beispiele sind immer noch ein wenig rau die Kanten herum, aber es kann Ihnen eine Vorstellung davon, wie über Ihr Projekt zu gehen.

HTH