Project linker -- share a set of code (PRISM) with Silverlight and WPF)

Project linker-sharing single code base between Silverlight and desktop applications

Project linker -- allow Silverlight and WPF to share a setCode

Original article:

Http://www.global-webnet.net/blogengine/post/2009/01/10/Project-Linker-sharing-single-code-base-between-Silverlight-and-Desktop-applications.aspx

The project linker permits you to easily share code and write reusable components for both the Silverlight and desktop application platforms. the benefit is that you can maintain a single codebase (and libraries) that will work on both platforms.

Project linker allows you to share code and reuse components in Silverlight and WPF. The advantage is that you can maintain a set of codes (and libraries) that can be used on both platforms ).

I wocould recommend downloading the compositewpf/prism application and reviewing the help information provided on the project linker. InComposite Application Guidance for WPF and Silverlight. CHM,If you'll search for "project linker", you will find a number of referenced links for more detailed information. An Excerpt from the "Multi-targeting technical concept" link follows:

I recommend you download compositewpf/prism and review (review ?) Help information provided by projectlinker. In 《Composite Application Guidance for WPF and Silverlight. CHMSearch for "project linker", and you will find reference links for more detailed help information. The following is an excerpt from "Multi-targeting technical concept"

Silverlight and WPF are not Binary compatible so code and components have to be recompiled for each target environment. the approach the Composite Application Guidance for WPF and Silverlight is taking is to provide guidance on structuring application and module code into multiple linked projects. each project manages all of the references, resources, and code specific to the WPF or Silverlight target environment. code that is shared is linked between two projects so that it is automatically compiled into each target. unit Tests can similarly be shared between the two environments, so that they can be written once and run against the target code in either of the two target environments. the Composite Application Guidance for WPF and Silverlight between des tooling to help create and maintain these links.

SilverlightAndWPFIt is not Binary compatible, so code and components must be re-compiled in each target environment.PrismProvides how to applyProgramAnd module code to build multiple connection programs. All references, resources, and special settings of each project are managed.WPFAndSilverlightCode of the target environment. The shared code is linked, so it will be automatically compiled into each target environment. Unit Tests can also be shared by two environments, so they can be written at a time to test the target code of the two target environments.PrismIncludes tools for creating and maintaining these links.

Non-UI code and components are probably going to be the easiest to share, so adhering to separated UI patterns are essential in making sure that the UI and non-UI pieces of the application or modules are cleanly separated.

Non-user interface code and components may be the most easily shared, so it is essential to adhere to the separation interface mode, so as to ensure that the interface and non-Interface part are completely separated.

The project linker essential tially allows you to link two project so that whatever you do in the source project automatically happens in the target project.

Projectlinker allows you to link two projects so that any work you do in the source project will automatically exist in the target project.

The documentation will recommend that you use the least common denominator as your source, I. E ., since Silverlight is a subset of WPF desktop if we code in Silverlight it will be supported on the desktop side. I follow their recommendation and use Silverlight as the source.

We recommend that you use the most common help document as your connection source target. For example, Silverlight is a subset of WPF, so the code you write under Silverlight can be supported by WPF. I accept their suggestions and use Silverlight as the link source target.

The first thing I'll do is create a desktop class library project and a corresponding Silverlight class library project-the only difference between the two project names will be a suffix. desktop and. silverlight.

First, I create a WPF class library and the corresponding Silverlight class library (the only difference is that their suffixes are. desktop and. Silverlight)

Once my projects are completed I'll then go to the projects properties and remove the Suffix from the default namespace-since we're re sharing code on both sides they both have to have the same namespace; this is the only change we have to make to the project.

Once the project is complete, I will delete the extension of the default namespace from the project properties. The shared code must have the same namespace, which is the only place to change.

Now whenever I add a folder or class to the source (Silverlight) project it will automatically be made to the desktop side.

Now, no matter whether I add a directory or a class to the Source Target Project (Silverlight), it will be automatically added to the WPF (the target project of the link.

Typically when you add a class it will automatically add default namespaces. you'll want to remove these and only use the actual namespaces required because by default the Silverlight namespaces are not supported on the desktop side.

Typically, when you add a class, the default namespace is automatically added. You need to delete them and use the actual namespace, because the default Silverlight namespace is not supported by WPF.

Recommendation: After adding classes-compile and compile often. anytime you add a reference to the Silverlight side be sure to add the same reference to the desktop side-if the namespaces are different then use the # If Silverlight # else # endif conditional statements as applicable (I show an example in the webcast ).

Suggestion: After adding a class, compile it frequently. At any time, after you add a reference to Silverlight, confirm that the same reference is added to WPF. If your namespace is different, use the # If Silverlight # else # endif condition declaration in a timely manner. (I showed an example in webcast)