Quelle est la meilleure pratique pour compiler Silverlight et WPF dans un projet?

Question

Je viens de terminer un projet Silverlight et il est temps de faire un petit nettoyage. Je voudrais prendre mes fichiers de base et les mettre dans un projet distinct auquel je ferai référence à partir de mon application principale Silverlight. Certaines de ces classes sont compatibles avec WPF et j'aimerais bien pouvoir disposer du code Silverlight / WPF dans un seul projet. Ma solution idéale serait un projet unique permettant plusieurs configurations. Alors,

Configuration: Silverlight générerait: Company.Controls.Silverlight.dll

Configuration: WPF générerait: Company.Controls.Wpf.dll

Est-il possible d’avoir la même source dans le même fichier séparé simplement via une définition?

Quelqu'un l'a-t-il déjà fait?

Modifier: j'ai créé une solution par projet, telle que MyCompany.Windows.Controls, qui contient ensuite 2 projets, MyCompany.Windows.Controls & amp; MyCompany.Windows.Controls.Silverlight. A côté de ces 2 dossiers, j'ai un " Shared " dossier qui contient les fichiers utilisés par les deux projets. Cela fonctionne bien jusqu'à présent:)

Answer 1

Je n'ai pas essayé moi-même (je cherche toujours à trouver le temps de jouer avec Silverlight), mais vous ne pourriez pas avoir une solution avec deux projets, l'un ciblant Silverlight et l'autre ciblant .NET 3.5, et ajouter le commun fichiers de classe à chaque projet sous forme de liens (cliquez avec le bouton droit sur le projet, Ajouter un élément existant ..., Ajouter en tant que lien)?

** Mise à jour: Voir la réponse de Mark ci-dessous concernant l'éditeur de liens de projet. Je l'utilise dans mon application composite multi-cibles avec la CAL PRISM 2.0 et c'est une belle chose. Je ne pense pas que cela existait dans PRISM 1.0?

Answer 2

Mise à jour: indique qu'il existe presque toujours un moyen plus simple. : -)

La première étape consiste à utiliser la compilation conditionnelle pour séparer le code spécifique à Silverlight. (Je suppose que votre cible par défaut est WPF.)

Deuxièmement, vous aurez besoin d’un script de compilation qui compilera le code pour chaque plate-forme, en définissant les définitions appropriées et les références d’assemblage.

Jetez un coup d'œil au projet Caliburn open-source . Il fait tout cela.

Voici un exemple tiré de la classe ExtensionMethods de 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);
        }

Si vous ouvrez Caliburn dans VS et le compilez, il est conforme au cadre standard. Les références concernent .NET 3.5 et WPF, pas Silverlight. C’est aussi pourquoi les directives de pré-traitement sont "! SILVERLIGHT".

Dans votre script de construction (Caliburn utilise NAnt), vous avez une cible qui définit les définitions pour chaque plate-forme. Par exemple, la cible Silverlight de Caliburn est:

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

Voici la cible qui appelle la version Silverlight actuelle:

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

Enfin, voici un exemple de "noyau" cible responsable de la production du fichier 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>

Notez la façon dont il référence les assemblys nécessaires.

Vous devrez probablement modifier votre fichier NAnt.exe.config (si vous utilisez NAnt) pour qu'il corresponde à la version correcte du framework Silverlight. Pour Silverlight RTW, la version de la structure sera 2.0.31005.0.

    

Answer 3

Vous devriez vérifier les " patterns & amp; pratiques: WPF composite et Silverlight "

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

Les versions WPF / Silvelight de la même application sont présentées dans une seule solution. Egalement un " Project Linker " qui met à jour la source de votre application WPF lorsque vous modifiez le code Silverlight (ou inversement) en utilisant la liaison. Il peut être remplacé si vous avez un code spécifique à la version.

Les exemples sont encore un peu approximatifs, mais cela peut vous donner une idée de la façon de mener votre projet.

HTH