Merging our Silverlight and WPF UI controls

20 April 2010

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.

Nevertheless this move does have a downside. As I stated above, the Silverlight and WPF controls in DXperience v2010.1 will require .NET 4 and VS2010. In particular, you must use the new Silverlight 4 and WPF 4; the controls will not function with the previous versions of WPF and Silverlight, such as Silverlight 3. Similarly, you cannot use VS2008 or earlier, but must use VS2010. To my mind this isn’t that much of a downside: VS2010 is light years ahead of its earlier brethren in terms of user experience and its use is de rigueur if you are creating applications with either Silverlight or WPF.

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.

14 comment(s)
Mitchell Thraves

Fantastic news guys. We've been looking at developing some Silverlight apps, but wanted to use some elements of our WPF apps. With both now sharing a codebase it making it a lot easier to achieve. Great work.

20 April, 2010

What are the consequences on winform developpers?

20 April, 2010
Nate Laff

What about porting existing silverlight controls back to WPF? I desperately need the beautiful AgBook control in WPF, and quickly. Are these things that can be done now in minor releases rather than waiting on majors? I've already mentioned to Azret that I really neeeeeeed this control and he was going to talk to the team.

20 April, 2010
Peter Thorpe

I'm happy with the decision made I think most people see Silverlight as WPF lite now and they will naturally move closer in the future so there is no need for 2 different code bases. Especially when it frees time for other things.

I would be interested to know where this lies with Windows Phone development.

20 April, 2010
Hans Nieuwenhuis

Can I use DevExpress 2010.1 for WinForms development in Visual Studio 2005 and C# 2?

20 April, 2010
Karen Babloyan

No matte, just give us v2010 :)

20 April, 2010
Andrew (DevExpress)


WinForms/ASP.Net  products support .Net Framework 2 (VS2005/VS2008) in 2010.1.

21 April, 2010

It is all good and well... However my clients will not upgrade to .NET4 and I can not force them to.

SO no DXperience v2010.1 for me.

21 April, 2010
Julian Bucknall (DevExpress)

All: WinForms and ASP.NET controls are not affected by this. You'll still be able to install v2010.1 in VS2005/2008 for those platforms.

Cheers, Julian

21 April, 2010

Julian: Okay, but what about winforms programming on .NET 4 / VS2010? :)

21 April, 2010
Damian Hickey

I fully support this post.

Should help the WPF suite catch up with the Winforms suite much faster.

21 April, 2010
Michael Rutherford

Fantastic news!

23 April, 2010
Jason Thorn

Well it seems that the statements about supporting the 9.3 codebase for developers who can't migrate to the VS2010 platform are only half hearted. I had a developer of mine file a support ticket to investigate if the problems reported with support of RTF tables in the AgRichEdit were going to be addressed in the 9.3 codebase and we were told ...

"Please note that 9.3 version of the AgRichEdit control doesn't have built-in tables support. The tables support is available in the 10.1 version of the AgRichEdit control only. We have no plans to include this feature in the 9.3. version of the AgRichEdit control."

Now, I wouldn't call support of tables a "Feature" but if thats the approach that you want to use then so be it. Just remember that your customers are developers too, and they can generally smell a made up support excuse as well as anyone.

3 June, 2010
Lee Maguire

We're also stuck with .net 3.5 and WPF so can't move on to the latest and greatest 10.1 version yet. Massive companies like my client role out computing platforms very slowly... 2008 is considered bleeding edge. .Net 4 is met with the response "Why?".

I like the products... Hopefully this is not a sign of DX cutting the strings on previous versions, support, bug fixes etc. It's hard to recommend and it is already playing catchup to Infragistics (to name but one).

1 July, 2010

Please login or register to post comments.