Qual è la migliore pratica per compilare Silverlight e WPF in un progetto?

Question

Ho appena completato un progetto Silverlight ed è ora di fare un po 'di pulizia. Vorrei prendere i miei file core e inserirli in un progetto separato che farò riferimento alla mia app Silverlight principale. Alcune di queste classi sono compatibili con WPF e vorrei poter avere il codice Silverlight / WPF in un unico progetto. La mia soluzione ideale sarebbe un singolo progetto che consenta più configurazioni. Così,

Configurazione: Silverlight genererebbe: Company.Controls.Silverlight.dll

Configurazione: WPF genererebbe: Company.Controls.Wpf.dll

È possibile avere la stessa fonte nello stesso file appena separato tramite definisce?

Qualcuno l'ha già fatto prima?

Modifica: ho creato una soluzione per progetto, come MyCompany.Windows.Controls, che contiene quindi 2 progetti, MyCompany.Windows.Controls & amp; MyCompany.Windows.Controls.Silverlight. Accanto a quelle 2 cartelle ho un " Shared " cartella, che contiene i file utilizzati da entrambi i progetti. Funziona bene finora :)

Answer 1

Non l'ho provato da solo (sto ancora cercando di trovare il tempo per giocare con Silverlight), ma non potresti avere una soluzione con due progetti, uno destinato a Silverlight e l'altro destinato a .NET 3.5 e aggiungere il comune file di classe per ciascun progetto come collegamenti (fare clic con il pulsante destro del mouse sul progetto, Aggiungi elemento esistente ..., Aggiungi come collegamento)?

** Aggiornamento: vedi sotto la risposta di Mark relativa al Project Linker. Ho usato questo nella mia applicazione composita multi-targeting con la CAL PRISM 2.0 ed è una cosa bellissima. Non penso che questo esistesse in PRISM 1.0?

Answer 2

Aggiornamento: indica che esiste quasi sempre un modo più semplice. : -)

Il primo passo è utilizzare la compilazione condizionale per separare il codice specifico di Silverlight. (Suppongo che il tuo target "predefinito" sia WPF.)

In secondo luogo, avrai bisogno di uno script di compilazione che compilerà il codice per ogni piattaforma, impostando le definizioni e i riferimenti di assembly appropriati.

Dai un'occhiata al progetto Caliburn open-source . Fa tutto questo.

Ecco un esempio della classe ExtensionMethods di Caliburn.

    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);
        }

Se apri Caliburn in VS e lo compili, è conforme al framework standard. I riferimenti sono per .NET 3.5 e WPF, non Silverlight. Questo è anche il motivo per cui le direttive di pre-elaborazione sono "! SILVERLIGHT " ;.

Nel tuo script di compilazione (Caliburn usa NAnt), avrai una destinazione che imposta i definitivi per ogni piattaforma, ad esempio, la destinazione Silverlight di Caliburn è:

<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>

Quindi, ecco il bersaglio che invoca l'attuale build Silverlight:

<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>

Infine, ecco un esempio di " core " target responsabile della produzione di Caliburn.Core.dll:

<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>

Notare il modo in cui fa riferimento agli assiemi necessari.

Probabilmente dovrai modificare il tuo NAnt.exe.config (se stai usando NAnt) per abbinare la versione corretta del framework Silverlight. Per Silverlight RTW, la versione del framework sarà 2.0.31005.0.

    

Answer 3

Dovresti dare un'occhiata a " pattern & amp; pratiche: composito WPF e Silverlight "

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

Ha un avvio rapido con le versioni WPF / Silvelight della stessa app in un'unica soluzione. Anche un " Project Linker " che aggiorna l'origine dell'app WPF quando si modifica il codice Silverlight (o viceversa) utilizzando il collegamento. Può essere sovrascritto quando si dispone di un codice specifico della versione.

Gli esempi sono ancora un po 'approssimativi attorno ai bordi, ma potrebbero darti un'idea di come procedere nel tuo progetto.

HTH