The first beta of DXperience v2010 vol.1 has just been made available to our DXperience customers, and so I’d like to take this chance to talk a little about one of the major impacts of that release: the merging of our Silverlight and WPF controls to use a common codebase that we’re calling XPF. (For a brief announcement of this, see here.)
(Incidentally, let me quickly say that if you have any version of DXperience, anything from ASP.NET to Universal, you automatically get access to our betas for the next release. Just visit Client Center and login to download the beta.)
When we started to look at the new features and functionality of both Visual Studio 2010 and .NET 4.0, we came to the conclusion that we needed to revamp our Silverlight and WPF offerings. Not only that, but since the changes in the new Microsoft releases were so major (remember: .NET 4.0 is not .NET 2.0 in disguise, like the intermediary versions were), we felt that our response had to be just as bold and authoritative, especially with regard to Silverlight and WPF.
Finally, with VS2010, Visual Studio has a form designer worthy of Silverlight and WPF. We could target both it and Microsoft Blend to produce our own control designers, much as we do with our WinForms and ASP.NET controls. Also Silverlight in v4 has the ability to create desktop applications that aren’t sandboxed into triviality. In fact, Silverlight, more than ever, resembles a WPF-lite on the desktop side, to the extent of pundits considering their eventual merging. At long last it is possible to write one set of non-trivial code and compile it both for Silverlight and for WPF without having to reinvent so many wheels on the Silverlight side (and to a much lesser extent on the WPF side).
But, there’s a catch. (Isn’t there always.) In order to take advantage of all this goodness, we needed to move to .NET 4 and VS2010. Full commitment; no holding back.
Once that decision was made, the others fell into place very quickly. We’ve felt in the past that having two ‘XAML platform’ codebases was a colossal waste of resources and effort, so the merging of them into a common codebase with the help of .NET 4 caused a huge sigh of relief. The Silverlight and WPF teams were merged, and once that was complete the code merging work was completed pretty quickly too, a couple of weeks all told. Naturally, in doing so, we took the most advanced and full featured code and controls and discarded the rest. In practice this meant that most of the common library consisted of the old WPF controls; our Silverlight controls had been struggling to keep up.
Thinking about the future, this aggressive change of direction has several consequences. Firstly, our tech writers’ job is much simplified. No longer will we have to write two sets of documentation for two sets of different controls: a common codebase means one set of documentations. Secondly and similarly, our support team’s job is improved in a similar manner and we can serve you much faster and comprehensively. Thirdly, it means that we can release controls in tandem for both platforms (although in practice for major controls, it’ll mean that a control will appear on one platform first with the other coming in short order). Fourthly, it’ll mean that enhancements to controls in XPF will be released for both platforms at the same time.
To alleviate this requirement, we’re going to continue supporting our previous Silverlight and WPF controls as part of v2009.3, much as we continue to support .NET 1/1.1 (and VS2002/2003) with v2006.3. You’ll receive regular updates to that version as we fix issues, but we will not be enhancing those controls further. We of course recommend that you upgrade to v2010.1 for your future Silverlight and WPF applications. Both the new Microsoft stack and our new XPF controls will make your XAML platform development, be it Silverlight or WPF, easier and faster.