These days, it seems everyone is talking about Silverlight. Many people say Silverlight will take over all development and Windows Presentation Foundation (WPF) will no longer be relevant. Although it's true that Silverlight 4 and WPF 4 have much in common, you still need to consider many differences when making a decision about which technology to choose.
In this column, I'll help you understand the differences between WPF and Silverlight so that you can make an informed decision about which platform to choose for a particular application.
Microsoft and WPF
I've talked with many Microsoft folks on both the Silverlight and WPF teams. Both teams are alive and well within Microsoft. WPF is still being targeted as the development environment to use when you're building a desktop application that needs deep integration with the operating system. Silverlight will be your best bet for targeting cross-platform applications.
As many of you already know, WPF was used to rewrite many portions of Visual Studio .NET 2010. This means that Microsoft has invested heavily in WPF and will continue to use it for tools that need rich desktop support. Microsoft also wrote Blend in WPF. One of the great things about WPF is you have full access to the .NET Framework; Silverlight works only with a limited subset of the .NET Framework. Obviously, to build products like Visual Studio and Blend you need full access to the .NET Framework.
WPF has Deep Roots in .NET
I'm sure many of you have written applications in ASP.NET or Windows Forms in the past. You probably have existing class libraries you created to do a lot of common things for either environment. WPF will allow you to reuse all of your class libraries. This should make transitioning from a Windows Forms application to WPF a little less painful than attempting to move everything to Silverlight.
In my travels to user groups and conferences, and in my consulting practice, I encounter many developers that still use data sets and data tables with ADO.NET. WPF has full support for these entities. However, Silverlight does not support the System.Data namespace; you must rewrite those portions of your application that use these classes.
Some developers were concerned with the large .NET Framework footprint required to be distributed with a desktop application developed with Windows Forms or WPF. Starting with Visual Studio 2008 SP1, Microsoft offers a .NET Framework Client Profile, a smaller subset of the Framework that reduces the footprint of your deployed application.
Getting Things Done Fast
If you're like me, you probably develop a lot of little utilities to help you in your day-to-day operations, or maybe to try out some new feature. WPF offers a much simpler development model; you only need to create a simple WPF project and run it to see it work. Using Silverlight you must create a Silverlight application and then a Web application to run that under. Of course, you can use the Silverlight out-of-the-browser (OOB) mode to do the same thing, but I still find WPF easier to use.
While this might not seem like something worth mentioning, you'll find that running a Silverlight application over and over requires the Microsoft Development Server to start up and stop each time. In addition, your browser must load the XAP file for your Silverlight application within the browser each time before the Silverlight application will appear. This can add up to a lot of time over the course of developing a simple utility application. This is where using the Silverlight OOB mode will come in handy, because you'll avoid the start and stop of the Development Server.
Simple Database Access
Many corporate developers still create small department-level applications for their companies. For many of these applications this means you only need to support one or two users and you may only be accessing a handful of tables for your application. WPF lets you directly access your SQL Server, Oracle, or JET database using methods you're already familiar with. With Silverlight, you must create a WCF service or use RIA Services to access your data. In addition, Silverlight uses an asynchronous model for accessing data. This can be a bit of a shock to those not accustomed to such a model; it requires that you learn a different way of programming.
Interaction with the Machine
Caching data on the client machine or accessing the registry or Active Directory (AD) is something many applications need to do. WPF gives you unlimited access to the file system, the registry, and AD—things to which Silverlight does not have full access. Although you can run a Silverlight application out of the browser, which means that the application can run outside of the web browser, it still only runs under elevated trust, not full trust that you can grant to a WPF application.
As far as other things that you like to do on the client machine, with WPF you can send any type of serializable object to the Clipboard, while Silverlight is limited to just sending text. You also get full drag and drop support of any object, while Silverlight only supports drag and drop for files. WPF can access all parts of the file system on a user’s machine. Silverlight is limited to only the User Profile folders such as My Document, My Pictures, and so on. So, if you really need to interact with everything on a user’s machine, WPF will be your logical choice.
The deployment story for WPF is typically much simpler than for Silverlight. If you're simply building a logical N-Tier application and you don’t have a need for any services, then you only need to distribute your WPF application and associated DLLs to your clients. IIS or any other service that has to be created on a server somewhere is not needed. This makes the initial deployment easier, and it aids in updates because you only have to update the client; you don’t have to ensure that the services are versioned at the same time.
WPF offers you full access to all WCF capabilities, including the ability to expose as a service for other WCF services and full access to the WS-* services. Silverlight may only utilize a subset of WCF and has no way of being a client service. When programming Silverlight you also have to take cross domain policies into account because, typically, you can call back only to the same website on which your Silverlight application is hosted. You can call other web services, but a cross domain policy file must reside on the other service to explicitly allow your Silverlight application to call that service.
Many more differences exist between Silverlight and WPF, but hopefully I've given you a taste for what is and what is not possible with each one. Silverlight and WPF will both play an important part in your development future. You should not avoid one or the other; simply choose the technology based on your application's needs.
I believe that WPF and Silverlight will continue to come closer and closer to feature parity. When that will happen is probably still a few years away. If WPF could speak, I'm sure it would say, in the words of Mark Twain: "The report of my death is an exaggeration."