Welcome to Pete Brown's 10rem.net

First time here? If you are a developer or are interested in Microsoft tools and technology, please consider subscribing to the latest posts.

You may also be interested in my blog archives, the articles section, or some of my lab projects such as the C64 emulator written in Silverlight.

(hide this)

The Future of Client App Dev : WPF and Silverlight Convergence

Pete Brown - 01 December 2009

Silverlight has come an amazing distance since the initial 1.0 release and 1.1 alpha (controls? who needs controls?) just over two years ago. It’s hard to believe that we’re on Silverlight 4 in such a short time. It’s even harder to believe that each of those releases has been robust and packed full of new and useful features, driven by community feedback.

With all the attention given to Silverlight, it’s reasonable to wonder what is happening with WPF. WPF, being the more mature technology, tends to have quieter releases with less fanfare. That doesn’t mean the feature set isn’t impressive, though. 3.5SP1 was a great release, and just take a look at what we shipped with WPF 4 beta 2:

  • DataGrid, Calendar, DatePicker
  • Visual State Manager (pioneered by the Blend folks and tried out first in Silverlight)
  • Touch input in the core base classes
  • Touch Manipulation input in UIElement-derived controls (scale, rotate, etc.)
  • Layout Rounding
  • Cached Composition
  • Pixel Shader 3 Support (PS3 supports some pretty intense effects. I hope to see it supported by Silverlight as well at some point)
  • InputBinding and KeyBinding
  • Binding Run.Text
  • Binding Dynamic Objects
  • Easing Functions
  • Xbap access to HTML and scripting, as well as Xbap full-trust elevation prompting
  • Windows 7 Integration with the TaskBar using System.Windows.Shell
  • A completely new text rendering stack giving us pixel-perfect clear type text as well as better support for animated text and control over snapping
  • A completely new Xaml parser
  • A much tighter and smaller client profile install (a .NET 4 feature)

Two of the flagship design and development products at Microsoft have taken advantage of WPF, and there have a pretty heave dependence on the technology:

  • Expression Blend : written from the ground up in WPF
  • Visual Studio 2010 : the user interface was completely removed and replaced with a great WPF version

At the PDC, we also saw other WPF-based applications such as Fishbowl and Microsoft Live Labs Pivot (which uses seadragon/deep-zoom technology). I’ve also seen a number of other applications, written by partners, that do some great things only possible with WPF. I’ll have Channel 9 videos up for those soon.

WPF 4 is the best and easiest way to write full Windows 7 applications in .NET. If you want to write managed code and target Windows 7, this is the technology you’ll want to consider first.

So, as you can see, WPF development is alive and well both internally at Microsoft with the partner community. It may not get the level of attention that something new and fast-moving like Silverlight gets, but it is there, and it is strong.

My Role, and my Preferences

In my role as the Developer Community Program Manager for Windows Client, I tend to focus on WPF, as it is the biggest group in my area. However, my role is not limited to that: C++/native, WPF, windows forms, some Silverlight, Windows 7, 8 and more (when I joined, no one was talking about the current version of Windows, they were already moving ahead on the next version) sprinkled with a little surface and maybe even some mobile, all fall under my umbrella. Jaime Rodriguez is my counterpart on the Evangelism side, and is responsible for some amazing WPF and Windows 7 content.

When it comes down to it, I love both Silverlight and WPF. I have no skin in the game regarding which one you choose, as long as you are choosing the one that will meet your feature and usability requirements while giving you the productivity you need. For example, writing a bunch of COM wrappers to access things Silverlight doesn’t natively support, and then having to deploy those wrappers as MSIs alongside Silverlight, would make me question if you had picked the right technology. Similarly, if you’re considering Xbap, you may want to look into Silverlight and see if does what you need.

What the Future Holds – Convergence of WPF and Silverlight

I recently spoke with Ian Ellison-Taylor at Microsoft. Ian is a General Manager at Microsoft, reporting directly to Scott Guthrie. Among other things, his group handles both Silverlight and WPF (and RIA services and a lot of other stuff). I figured if I wanted the skinny on the future, he’d be the guy to talk to. So, he and I talked about the convergence of Silverlight and WPF, and later exchanged some email on the topic.

In the future, it is very likely that both Silverlight and WPF will be a single technology with a single codebase. After all, Silverlight was originally known as WPF/E (E as in Everywhere), and in an amazing 180 degree reversal of our usual approach, we took an ugly codename and created a great product name (Silverlight) from it.

What does that mean, from a practical standpoint?

To developers, it doesn’t really mean much at this point. Your investments in WPF development for Windows and Silverlight for cross-platform applications are both safe. Microsoft is committed both to creating a great cross-platform experience, as well as ensuring that there’s a developer platform that can take full advantage of everything Windows has to offer.

Build for the requirements you have today and understand that there will be a path to the future regardless of whether you picked WPF or Silverlight.

When will this happen?

That’s hard to say. Work in this area is very early, so it’ll be a bit before the public notices anything come out of this. We’ve already seen code shared between the two platforms (VSM, and DataGrid for example), as well as ideas. The two platforms have really helped each other grow. However, Silverlight doesn’t currently support many of the things to build a large application like Visual Studio, and WPF doesn’t run on a cross-platform CLR, so the under-the-covers delta between the two is still pretty big. Microsoft isn’t going to drop real features we’re using today.

What will the converged technology be called?

It may be called Silverlight, or it may be called Windows Presentation Foundation / Everywhere Cross-Platform and Windows Editions. It’s hard to say. We’re funny about names :)

So, what should I build my new application in today?

At Microsoft, we don’t really like to tell people “If you are building an X, use technology Y” Invariably, we’d miss some scenario or the advice would be treated as rules rather than guidance. I’m not going to break that trend here. Instead, look at the feature set you have to implement in your application. Consider what types of services you may need to integrate with, what level of access you require to the local machine, whether you require cross-platform support etc. If you create a matrix of those features, it will help point you to the right technology.

Silverlight is on the right of the graph as the best way to target cross-platform RIA. WPF on the left, as the best way to write managed code applications for Windows 7.

Remember that with Silverlight 4 you can now automate anything already on the machine that has an IDispatch interfaces (think Office automation) and that with WPF 4 you now have a smaller and tighter .NET install, that will work side-by-side with your previous .NET installs, making it much easier to consider deploying.

Also consider that with Silverlight 4 and WPF 4, you can now share binary DLLs between the two technologies, making it much easier to share functionality, and deliver optimized versions of your application (a WPF version with more client features and a Silverlight version targeting cross-platform, for example). The skills and tools are the same.


WPF and Silverlight are both technologies with very rich capabilities and a strong community. Pick the one that meets the requirements you have for your project today, and understand that regardless of which one you pick, you’ll have a path to the future on the Microsoft platform.

posted by Pete Brown on Tuesday, December 1, 2009
filed under:            

33 comments for “The Future of Client App Dev : WPF and Silverlight Convergence”

  1. Keith Eldersays:

    I SWEAR I wrote my blog article before you did. Thank you for further confirmation on what I've been saying. Here's what I had to say on this after PDC:


  2. Tomsays:
    "Your investments in WPF development for Windows and Silverlight for cross-platform applications are both safe."

    "Microsoft isn’t going to drop real features we’re using today."

    Those are some BOLD claims right there! Do you really believe that? I've learned from painful experience that nothing from Microsoft is safe from destruction. It doesn't seem to matter how widespread its use is, how old or new it is, how brilliant or flawed it is, or if there's even any viable alternative available at the time of its death. Sometimes there are clear and/or justifiable reasons. Usually there are not.

    Microsoft has killed off so many of the wonderful things they've given me that I sometimes wonder if I would've been better served in the long run by using a third party or even writing the code myself. (In that subset of cases where not using the Microsoft offering was conceivable.)

    But, life goes on. I've been watching and working with both WPF and Silverlight for years, hoping they would turn into viable platforms for certain applications I need to recreate using up-to-date technologies. Their recent progress is encouraging and I've been looking at their convergence with great interest. Thank you for writing about it!

    I hope we'll continue to see more teams within Microsoft leading by example in adopting these technologies. Soon I'll be taking the plunge for real, with a lot at stake, and I wish I could be as confident as you in what Microsoft has in store for us all.
  3. Pete Brownsays:

    I've been really impressed by the folks in the WPF and Silverlight teams. The people I've worked with really want to do the right thing for the community of developers using these technologies.

    Sure, things get deprecated (like bitmap effects, for example), but I'm not expecting to see a wholesale dump of either of these technologies without a clear and reasonable path to the converged technology.

  4. Jose Fajardosays:
    Great post, but honestly what frustrates me is the lack of communication from the WPF team or WPF evangelists on what they are doing with the new sl3/4 features and if/when they will make it into WPF.

    Honestly just a roadmap of new SL3/4 features and when/if they will make it into WPF. The gap's just seems to be growing and it's left for dev's to create this discrepency list (where in fact it should be something that the MS teams should be devising, distributing and touting)

  5. Rick Barrazasays:
    Thanks Pete! However, I think many of us are already assuming the convergence of SL and WPF will happen some way or another. What I'm REALLY interested in, though, are the inroads between WPF/SL and XNA. Where Gaming goes, Design follows, and Business RIA follows after that. Currently, having such a walled garden around both, needing to pick early if you go WPF or go XNA, and XNA's tendency to terrify traditional RIA or even itneractive designers, needs to be addressed to keep pushing the upper edge of amazing experiences. Does XNA even fall in your camp? If not, I would suggest starting there as trying to figure out what the REALLY hard challenges will be in 18 months as far as bleeding edge MSFT experiences go.

    My $.02

  6. samsays:
    The meteoric rise to power of silverlight makes me pause and think about the bastard child which is MCML. It still ships as the platform of choice for Media Center apps, in fact silverlight is no longer properly supported for Media Center apps. Having said that, it received little to no attention in the last few years and development on it is a dark art. Yesterday I read on Charlie Owens blog that he is jumping ship to the silverlight team.

    So I wonder, is MCML officially an abandoned technology? I would love to hear an official announcement of its death, and a new technology to replace the failed experiment. Do you have plans to ship a replacement silverlight based 10 foot experience toolkit?
  7. hempsays:
    Tom, in my experience when Microsoft dumps something it's usually a supporting technology or library, not an entire platform.

    For instance, the recently (for all practical purposes) dropped Linq to SQL in favor of Entity Framework, dropped WF in favor of a not-backward-compatible revamp, etc. Those have been painful for a lot of people, for sure, but they weren't platforms - just supporting technologies. Silverlight and WPF are platforms (akin to MFC, for instance, which is *still* getting updates!)

    So, I have confidence that while MS will assuredly tick some people off down the road by dropping certain technologies (I'm looking at you, "RIA Services"), I don't have any concern that your investment in their vector-based UI platforms will continue to be useful for many years.
  8. Rene Schultesays:
    Great post Pete! And good that you highlighted the important WPF 4 features, like shader model 3 support. :) It would be awesome if the shaders are executed by the GPU like in WPF 4. My head explodes if I imagine all the cool stuff I could do then. :) And while the teams is implementing that they could also add a more advanced GPU 3D API. :)
  9. Richardsays:
    So other than building slick (non-standard) interfaces, why can't I continue using WinForms for client development? With WinForms, I only need Visual Studio and some third-party controls. With WPF, I need Visual Studio, Expression Blend, and third-party controls. Sorry, I'm not trolling, but I honestly do *not* see how WPF is better at building client apps.
  10. Pete Brownsays:

    WPF is generally a superset of Silverlight, with multiple ways of accomplishing tasks. Silverlight tends to have only one way for each task. An example is network access. With WPF, you get sync and async calls. Silverlight only does async calls.

    In my previous job as a consultant, I recommended to my clients that if they were targeting both, they try and stay within the Silverlight supported approachs, and frequently cross-compile.

    So the difficulty REALLY depends on how you built the app.

    That said, the skills, technology, etc. are the same, so it's not like moving from a winforms project to a web app. The transition is smoother and easier on the team.

  11. Pete Brownsays:

    If you want to build apps in WPF that are standard Windows-style applications, you don't really need Blend at all, and you don't need any more team resources than you would with a windows forms apps (eg, if you got away without a designer before, you still can). The Visual Studio 2010 design surface does a great job for those types of apps. If you want to build up more of an "experience" then yes, you'll need Blend.

    IMHO, Windows forms is still a viable way to build applications. However, the community, patterns, etc. are starting to move to xaml-based UI, so you'll see more new stuff coming out in that space.

    WPF has lots of features you may find useful:
    - Real UI scaling
    - Excellent property/data binding (don't underestimate this. it completely changes how you build applications)
    - Better support for custom styling (this *always* came up in any significant winforms projects I was on, and I had to spend a lot of time overriding paint methods, and still had some third-party controls that didn't want to play nice)
    - Community-driven support for newer patterns such as ViewModel
    - Support for architectures like the Prism WPF/Silverlight composite app architecture, which is generally more approachable than the older windows forms equivalents
    - Ability to target both web and desktop by using xbaps or by using your same WPF skills with Silverlight
    - No need to keep buying additional third-party controls *just* to get some added UI-tweaking (WPF controls are lookless, you can tweak all you want)
    - Easier Windows 7 integration (taskbar, for example)

    So, that's my personal opinion on the matter. You can still build Windows forms apps, but I personally believe the future is in xaml-based presentations.

    If you want to ease into it, you can host windows forms controls in WPF and vice versa, so that's a reasonable way to get your feet wet.

  12. Richardsays:
    @Pete: Thanks for the response: you made some good points, especially about the control tweaking and UI scaling, both of which I've been bitten by.

    Guess I'll buckle down and build some WPF and Silverlight chops, and I guess part of my fondness for WinForms is that it feels an awful lot like what I started with: C -> C++ -> MFC, ATL, WTL -> Delphi.
  13. Pete Brownsays:

    I hear you. I did the C++/Delphi/VB3-4-5-6/PowerBuilder/xBase etc. thing long before I got into .NET. The good and the bad of this industry is it forces you to stay on top if you want to continue.

    be sure to check out www.windowsclient.net as well as www.silverlight.net for tutorials and things to help you get started.

  14. Steven ELliott Jrsays:
    <p>I have used WinForms for a very long time, well, as long as .NET has been out anyway. WinForm is a very comfortable technology that is established but its not without its warts. The company where I work is an all .NET shop and we've been converting a legacy AS/400 system to .NET - we are using WPF for the entire application at the moment and I find it to be extremely flexible and powerful. </p><p>I personally feel that Microsoft has revolutionized the way user interfaces are developed. The hardest thing for me when I got started was the lack of databinding functionality out of the box. I got lazy and spoiled with the drag 'n drop method of binding and had to almost relearn how to do it by hand. Now with the Entity Framework and Linq its become very easy and extremely powerful. I feel like WPF has almost rejuvenated me a little bit. I actually have a great time writing apps now whereas before it was starting to get a little stale. </p><p>The interesting thing though that I found was that you can bind to anything in WPF, properties, controls, whatever. Its very cool and somewhat insane but all in all a good time! I think people are eating WPF up and I feel youre going to see some amazing interfaces come along. </p><p>I've never done anything in Silverlight but I intend to get started. We're at the point now where we need to create some outward facing web apps and I'd like to see how Silverlight can help us out. </p><p>Thanks! </p><p>Steve</p>
  15. Manuel Pimentasays:
    Hey Pete, great article! But unlike some of the previous comments, I think the convergence between SL and WPF is not that clear... I have always heard MS guys saying that Silverlight is basically a subset of WPF. Well that is simply just not true.
    An example: I have been working with webcam capture and streaming. I saw a recent SL demo about just that, and the new libs they use for that effect. How exactly that is not supported in WPF is beyond me... I mean, SL always had an issue with accessing machine resources, while WPF allows almost full access; why then would not the CaptureSource feature would not be available in WPF?
    Maybe I'm not seeing the big picture but it does seem a bit inconsistent...

  16. Pete Brownsays:

    You're right in that SL is not exactly a subset of WPF at this point. There are some things SL has that WPF does not. That has been true in the past as well, and those changes (like Visual State Manager and Easing Functions, for example) did make it into later WPF revisions.

    That doesn't mean they won't converge, it just means there's a little game of leapfrog happening along the way :)

  17. Philip the Ducksays:
    <p>@Steven: "I personally feel that Microsoft has revolutionized the way user interfaces are developed." </p><p>I absolutely love the way XAML comes full-circle (conceptually) back to the old "resource file" model (an RC file compiled to RES and linked into the EXE) first used in Windows 1.x, which provided a scalable UI model for dialogs ("dialog units" rather than pixels) and separated the UI ("view") from the code ("controller"). This resource model was introduced way back in the Win16/DOS 3.1 days of yore (1985-ish) but it's still used today in Win32/64 C++ native application development. </p><p>Sadly, VB and later WinForms completely bypassed the resource file model, resulting in hard-coded, non-scalable non-customisable UIs, so it warmed the cockles to see the concept brought back via XAML in WPF back in 2001 and now in Silverlight. </p><p>Of course XAML is a modern XML format and beyond comparison to the old text-based RC file format in terms of funtionality, but the few of us old DOS/Win16 farts still around, who cut our teath on the 1st Edition of Petzold's Programming Windows, smile at the similarity. RC resource files are dead - long live XAML resource files! </p>
  18. Jasonsays:
    Great post. I've been moaning about the disparities between the two because I ran into this problem multiple times with different clients where they wanted to port a WPF app to Silverlight or to be able to use one codebase for both. It was virtually very difficult to do and we decided to just stick to one.

    Although I'd really want this convergence to happen, I'm wondering if this is possible practically. After all, Silverlight is a browser plugin, and the team has been trying hard to cherry pick the features to keep the download size low. It almost seems that you'd need a new project template and practices to make this happen. For example, the BCL for WPF + Silverlight would be in a set of assemblies that are supported by the Common WPF / Silverlight project template. And then, either the WPF project or the Silverlight project can reference that common project in order to build things on top of it.

    Currently, System.Serialization, for example, is not supported by Silverlight but it is by WPF. And it is very possible for a WPF developer to use that assembly in view models or any class that is related to the WPF technology. It has been a true challenge to clearly lift out these code to make it work in Silverlight. That's just one example but there are a lot of cases like this.

    Anyways, I really hope Microsoft has a good strategy on the convergence and I'll be looking forward to it!
  19. Sarkawt Basosays:
    Let me say something more important for me to continue using these two technologies or two in one technology (WPF & Silvrlight), this technology is in danger to be escaped by many programers who saw for first sight that it may be the dreem which eventually come true due to the wonderful GUI that can be designed by it, but the problem was arised when most of us began to use it and we discoverd huge memory leaks with this technology we made contacts with Microsoft for issuing this as a bug in technology design and they promised to solve it in the next version which was WPF 3 then we waited ver 3.5 without fixing then ver 3.5 sp1 also the bug was still there currently worked on ver 4 not beta also the bug is there I'm using windows xp sp3, .netframework 4, blend 4 . So do you want from me to believe that this technique will be alive in the future no sir execuse me I cannot imagine a technique with contiued memory (blood) leak will live to the future. What is your steps to persuade us stay on this technology and save it from the actual death.
    looking forward to hear from you soon!!!!!
  20. John O'Halloransays:
    What saddens me is that C# and XAML are high level abstractions, yet Silverlight/WPF creates a low level divide.
    Regardless of how we got here, the CLR should mean 'Common'. We don't have two different java's for inside and outside.the browser...
  21. Petesays:

    Last time I checked, there *were* different versions of Java for targeting different machine capability levels. There are super light versions for regular cell phones, a version that runs on android, and different ones for desktop and server.

    Ideally, everything will be compatible and the same, it's just *really* hard to do. Plus, if you do do it, you end up with compromises or lowest-common-denominator issues.
  22. Sarkawt Basosays:
    Hello sir,
    Im waiting your answer, please.
    just wanna know how could manage to avoid memory leak in WPF.
    I have a xaml code the lead to that leak, if you want I can share it here for a solution.

  23. Sarkawt Basosays:
    Hello sir,
    Im waiting your answer, please.
    just wanna know how could manage to avoid memory leak in WPF.
    I have a xaml code the lead to that leak, if you want I can share it here for a solution.

  24. Sarkawt Basosays:
    Hello sir,
    Im waiting your answer, please.
    just wanna know how could manage to avoid memory leak in WPF.
    I have a xaml code the lead to that leak, if you want I can share it here for a solution.

  25. Petesays:

    Badgering me is not the best way to get help, especially on a holiday. I typically don't do 1:1 support.

    I'm not aware of any "major memory leaks" in WPF. I tried to parse your original message, but it was difficult; from that, I assume english is not your native language.

    So, if you have a small repro project that shows the leak, and a connect Bug ID (I assume when you reported it, you did so on connect), please email me at pete.brown -at- microsoft DOT com.


Comment on this Post

Remember me

4 trackbacks for “The Future of Client App Dev : WPF and Silverlight Convergence”

  1. Mike Taulty's Blogsays:
    Great post from Pete over here about Silverlight/WPF convergence; “The Future of Client App Dev: WPF
  2. Rob Relyea - XAMLifiedsays:
    Now that the PDC is over, I’m staying very busy helping to move XAML in .NET 4 and Silverlight 4 forward