¿Cuál es la mejor práctica para compilar Silverlight y WPF en un proyecto?

Question

Acabo de completar un proyecto de Silverlight y es hora de limpiar un poco. Me gustaría tomar mis archivos principales y colocarlos en un proyecto separado al que haré referencia desde mi aplicación principal de Silverlight. Algunas de estas clases son compatibles con WPF y me gustaría poder tener el código Silverlight / WPF en un solo proyecto. Mi solución ideal sería un solo proyecto que permita múltiples configuraciones. Entonces,

Configuración: Silverlight generaría: Company.Controls.Silverlight.dll

Configuración: WPF generaría: Company.Controls.Wpf.dll

¿Es posible tener la misma fuente en el mismo archivo recién separado a través de define?

¿Alguien ha hecho esto antes?

Editar: He creado una solución por proyecto, como MyCompany.Windows.Controls, que luego contiene 2 proyectos, MyCompany.Windows.Controls & amp; MyCompany.Windows.Controls.Silverlight. Junto a esas 2 carpetas tengo un "Compartido" carpeta, que contiene los archivos utilizados por ambos proyectos. Funciona bien hasta ahora :)

Answer 1

No lo he intentado yo mismo (todavía estoy tratando de encontrar el tiempo para jugar con Silverlight), pero ¿no podría tener una solución con dos proyectos, uno dirigido a Silverlight y el otro dirigido a .NET 3.5, y agregar el común? archivos de clase para cada proyecto como Enlaces (haga clic con el botón derecho en el proyecto, Agregar elemento existente ..., Agregar como enlace)?

** Actualización: vea la respuesta de Mark a continuación con respecto al enlazador de proyectos. He estado usando esto en mi aplicación compuesta de múltiples objetivos con la CAL de PRISM 2.0 y es una cosa hermosa. No creo que esto haya existido en PRISM 1.0?

Answer 2

Actualización: muestra que casi siempre hay una forma más fácil. :-)

El primer paso es usar la compilación condicional para segregar el código específico de Silverlight. (Supongo que tu " valor predeterminado " target con ser WPF.)

En segundo lugar, necesitará un script de compilación que compile el código para cada plataforma, estableciendo las definiciones adecuadas y las referencias de ensamblaje.

Eche un vistazo a la fuente abierta proyecto Caliburn . Hace todo esto.

Aquí hay un ejemplo de la clase 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 abre Caliburn en VS y lo compila, cumple con el marco estándar. Las referencias son para .NET 3.5 y WPF, no para Silverlight. Es también por eso que las directivas de preprocesamiento son "! SILVERLIGHT " ;.

En su script de compilación (Caliburn usa NAnt), tendrá un objetivo que establece las definiciones para cada plataforma, por ejemplo, el objetivo Silverlight de Caliburn es:

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

Entonces aquí está el objetivo que invoca la compilación real de 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>

Finalmente, aquí hay un ejemplo del " núcleo " objetivo que es responsable de producir el 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>

Observe la forma en que hace referencia a los ensamblajes necesarios.

Probablemente deba editar su NAnt.exe.config (si está usando NAnt) para que coincida con la versión correcta del marco Silverlight. Para Silverlight RTW, la versión del marco será 2.0.31005.0.

    

Answer 3

Debes revisar " patrones & amp; prácticas: Compuesto WPF y Silverlight "

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

Tiene un inicio rápido con las versiones WPF / Silvelight de la misma aplicación en una solución. También un " Project Linker " que actualiza la fuente de su aplicación WPF cuando cambia el código de Silverlight (o viceversa) utilizando la vinculación. Se puede anular cuando tenga un código específico de la versión.

Los ejemplos siguen siendo un poco toscos, pero pueden darte una idea de cómo llevar a cabo tu proyecto.

HTH