Silverlight and WPF compatibility

Question

We are planning an application to be developed in Silverlight and WPF.

I wanted to know whether, since we will implement the interface in XAML, will it be compatible in both technologies?

What problems should we expect when moving from one technology to another?

Answer 1

I created a dual silverlight / wpf target application. It is not as simple as transferring one into another ...

Your first steps should be to look at the documentation on where wpf and silverlight differ to understand your problem a little better. XAML Handling the Differences between Silverlight and WPF . Do not stop. Understand design patterns that come into play based on different application environments. Now you begin to understand what you are dealing with.

When creating user interfaces for both wpf and silverlight, you must be very careful about the controls and namespaces used. Sharing user interface code can be very tedious, it is often easier to create two separate user interface layers that use common templates where applicable. Most of the user interface features that you have in a rich client application will differ from the functionality of the Silverlight application. You are likely to offer richer data in your wpf application, rather than more concise representations in your silverlight application. In the end, you can probably achieve the same goals, but it will be more difficult than just redirecting and deploying.

If you are building an application from scratch, I would recommend creating a wpf application and a silverlight application at the same time. By doing this, you will come across the possibilities of abstracting service levels and data access strategies used in different environments. Silverlight may need to access data through web services, while your wpf application can talk to an instance of the local database. This can be done quite easily. Use an IoC container or something to implement your proper service implementations. This area provides an opportunity for most code reuse. You can create all your presentation logic and service logic to share two user interfaces. You can also create common logic and data access logic.

If you do not have a local data store in your rich client application, forget the following paragraph.

If you plan to have a randomly connected standalone client (wpf application), you probably have to come up with some kind of synchronization strategy and architecture. Depending on the complexity of your data structures, this can be quite complicated. Building complex synchronization logic with accessible structures is PITA. You may need to build your own or live with the constraints of another.

One tip: start with testing and end testing

Answer 2

Ultimately, Silverlight was / is only a subset of the WPF object, so you will usually find some of the available elements in WPF that are not present when migrating to Silverlight, such things include:

• Lack of specific binding support in Silverlight.
• More subtle ways to configure dependency properties available in WPF that are not in Silverlight.
• Storyboards run in code using Silverlight, not Triggers WPF.
• WPF and Silverlight use different core libraries, which may mean that libraries cannot be shared between WPF / Silverlight applications.
• Silverlight has fewer built-in controls, not WPF.

And so on.

I would suggest that what you faced most of the problems would be porting your user controls, which, like many other codes, will be largely portable, but will have a bunch of caveats that appear between both the label and the code. You will probably have to configure most WPF controls to compile in Silverlight by changing the TargetType values ​​for templates, resources, etc. And replacing one control with another (or sometimes creating your own to achieve the goal, an example is UniformGrid , which is missing in Silverlight)).

I would post links, but other guys seem to have exposed everything you need to know about websites. Enjoy.