WPF vs Silverlight [duplicate]

Question

That's an extremely broad question. My company recently wrote a whitepaper outlining the differences between the two technologies, and it's around 70 pages. Unfortunately, it's not published yet, or I'd give you the link.

EDIT: As promised, here's the link to the whitepaper on Codeplex:

http://wpfslguidance.codeplex.com/

However, I'll try to summarize.

1. WPF is a thick Windows client platform that has access to the full .Net Framework. Silverlight is a browser-based technology that has access to a subset of the .Net Framework (called the CoreCLR). So, you'll notice differences using seemingly every day methods and objects within the framework. For instance, the Split() method on the String class has 3 overrides in Silverlight, but 6 in the .Net Framework. You'll see differences like this a lot.

2. Within WPF, all visually rendering elements derive from the Visual base class. Within Silverlight, they do not; instead, they derive from Control. Both technologies, however, eventual derive from the DependencyObject class up the hierarchy.

3. WPF, currently, ships or has available more user controls than Silverlight; though this difference is being mitigated through the Silverlight Toolkit and the upcoming release of Silverlight 3.

4. WPF supports 3 types of routed events (direct, bubbling, and tunneling). Silverlight supports direct and bubbling only.

5. There's quite a few data-binding differences that will be somewhat mitigated with the next version of Silverlight. Currently, Silverlight doesn't support the binding mode, OneWayToSource, or Explict UpdateSourceTriggers. In addition, Silverlight defaults to OneWay databinding if none is set, while WPF uses the default mode specified by the dependency property.

6. Silveright doesn't support MultiBinding.

7. Silverlight supports the XmlDataProvider but not the ObjectDataProvider. WPF supports both.

8. Silverlight can only make asynchronous network calls. WPF has access to the full .Net networking stack and can make any type of call. Also, currently, Silverlight supports SOAP, but can not handle SOAP fault exceptions natively (this may change in Silverlight 3).

9. There are huge differences in Cryptography (Silverlight has 20 classes in the namespace, while WPF has access to 107). Basically, Silverlight supports only 4 hashing algorithms and the AES encryption protocol.

10. Silverlight doesn't yet support: Commanding, Validation, Printing, XPS Documents, Speech, 3D, Freezable objects, or InterOp with the Windows Desktop; all of which are available in WPF.

11. Silverlight supports browser interop, more media streaming options including timeline markers, and Deep Zoom. WPF doesn't support these features yet.

This is by no means complete as I was trying to reduce a 70-page document into bullet points.

Finally, even with all these differences, Microsoft is trying to close the gap between the two technologies. The Silverlight Toolkit and the WPF Toolkit both address some of the shortcomings of each technology. Silverlight 3 will be adding many features not currently available (such as element-to-element data binding). However, due to the differences in the core libraries, there will always be some Framework differences.

WPF is a Windows desktop technology for developing Windows application in the .Net framework.

Silverlight is a web technology, that is fully supported by a browser plugin on both Windows and MAC (in a similar fashion to Flash). There is also a plugin for running Silverlight on Linux (Moonlight).

While there are similarities between the functionality provided by both WPF and Silverlight (in terms of user interface components and support for XAML) Silverlight is a much small framework, containing a subset of WPF functionality. Newer versions of Silverlight actually contain some functionality not found in WPF, so it is no longer a true subset.

Things that WPF has that Silverlight doesn't: Full 3d engine based on DirectX, Windows integration such as Windows 7 taskbar thumbnails and system registry availability as well as access to the full .NET Framework including Oracle database support. Also, SL runs in a secure sandbox that prevents access to things such as the entire file system where WPF apps can run full trust with complete system access.

As mentioned above, SL pioneered some technologies such as the VisualStateManager which are making their was secondarily into WPF through the Microsoft supported WPF toolkit.

If you're looking to gauge which technology is right for your project here's a simple way to look at it: If you're writing an app that's meant to run while disconnected from the web, or if you're writing an app that needs access to Windows specific features like the ones listed above then WPF is the way to go. For platform-agnostic, web enabled apps Silverlight is an appropriate choice. Hth.

You could say that it is [VERY] roughly analogous to the difference between Flex and Adobe Air, but that is somewhat misleading.

WPF refers to the set of technologies (exposed via APIs) that .NET Framework 3.0 and above users have access to in order to draw to the screen.

Many of the WPF APIs are available for Silverlight apps.

There are, of course many other APIs besides WPF that are available under Silverlight since SL apps will need to do a lot more than just draw on the screen.