Interchangeability / re-usability of WPF, Silverlight and Silverlight OOB applications?

Question

For the experienced WPFers out there, how re-usable are WPF, Silverlight and Silverlight OOB applications and components? How much overlap is there?

For example, could I write one application and easily deploy it in the three aforementioned ways?

Ideally, I want to write as little code as possible and have the flexibility of deploying it in a range of scenarios, maybe enabling certain functionality depending on deployment. The WPF family of technologies seems like a good starting point to the casual observer.. but is it really?

Answer 1

The simplified version of the answer is:
1. Silverlight is roughly a subset of WPF.
2. Silverlight in browser apps and Silverlight OOB apps are running on exactly the same framework. It is just a deployment difference.
3. Some OOB apps can be installed as "trusted" apps, and have looser security restraints than in browser apps.

Porting a WPF app to Silverlight is likely going to be very difficult, as a WPF app is likely to use many features of the .net framework that are not available in the smaller subset of the framework available to Silverlight apps. This is something you probably want to avoid.

Porting a Silverlight app to WPF is likely to be significantly easier. It would still be a challenge as there are features in Silverlight not in WPF (though not nearly as many as the converse). In addition to the feature delta, the actual framework that runs the Silverlight/WPF apps are different, so during the porting you would likely run into a certain amount of behavioral differences between the two.

Silverlight and Silverlight OOB apps are running on the same framework. It is possible to have the exact same app binary run in both places. For the most part, they will be behave identically. Some differences: in-browser apps can rely on browser features such as accessing the html dom, invoking javascript, etc. An OOB app doesn't run in the browser so obviously this doesn't apply. Also, if we are dealing with a "trusted" OOB app, it can do things that are prevented for security reasons in the browser (e.g. COM interop).

If you want to create an app that runs in all three places, my advice is to start building the app as an in-browser Silverlight app that is self-contained, i.e. it does not rely on the web page that is hosting it, and includes all the necessary resources inside the xap package (rather than relying on them being next to the package on the web server). Porting such an app to a Silverlight OOB app would be a cinch - pretty much just check a box in Visual Studio and you are done. Porting it to WPF would be a significant amount of work, but it would be much better than going the other way.