We are planning an application that will be both developed in Silverlight and WPF.
I wanted to know if, since we will be implemented the interface in XAML will it be compatible in both technologies?
What kind of problems should we expect when porting from one technology to another?
I have built a dual targeted silverlight / wpf application. It is not as simple as porting one to another...
Your first steps should be to look at the documentation about where wpf and silverlight differ to understand your problem a little better XAML Processing Differences Between Silverlight and WPF. Don't stop there. Understand the design patterns that come into play based on the different application environments. Now you are starting to get an idea of what you are dealing with.
When building UIs for both wpf and silverlight, one must be very careful about the controls and the namespaces in use. Sharing UI code can be extremely tedious, it's often easier to create two separate UI layers that use shared templates where it's applicable. Much of the UI functionality you have in a rich client application is going to differ from the functionality in your silverlight application. You will probably offer richer data intense views in your wpf app as opposed to more concise views in your silverlight app. In the end, you will probably be able to achieve the same goals, but it's going to be tougher than just retarget and deploy.
If you are building an application from scratch, then I would recommend building the wpf application and silverlight application at the same time. By doing this, you are going to come across opportunities to abstract out service layers and data access strategies used within the different environments. Silverlight will probably need to access data via web services, while your wpf app might talk to a local database instance. This can be accomplished pretty easily. Use a IoC container or something to inject your proper service implementations. This area offers the opportunity for the most code reuse. You can create all of your view logic and service logic to be share between the two UIs. You can also create shared business logic and data access logic.
If you are not going to have a local datastore in you rich client app, then forget the next paragraph.
If you are planning on having a occasionally connected offline client (wpf app), you will probably have to come up with some kind a synchronization strategy and architecture. Depending on how complicated your data structures are, this can be rather difficult. Building in complex sync logic with available frameworks is a P.I.T.A. You may have to build your own, or live with the restrictions of another.
One statement of advice: start with testing and end with testing
Ultimately Silverlight was/is only a subset of the WPF entity, therefore you will tend to find some of the available elements in WPF absent when porting to Silverlight, such things include:
Triggers of WPF.And so on.
I'd conjecture that what you wind up having most issues with will be the porting of your custom controls, which, as with a lot of your other code, will be largely transferable but will have a bunch of caveats apparent between both the mark-up and code behind. You'll probably have to tweak most WPF controls to compile in Silverlight, altering TargetType values for templates, resources et cetera, and replacing one control for another (or sometimes having to create your own in order to achieve a goal, an example of this is the UniformGrid which is missing in Silverlight)).
I would post links but the other guys seem to have exposed everything you'll need to know from about the webs. Have fun.
