WPF Composite Client, it's coming!

image

Today is a great day as we unveil our plans for a new  patterns & practices deliverable currently called " WPF Composite Client".

The Acropolis team  just announced that  the core Acropolis concepts  will be rolled into future .NET Framework releases.  While we're excited about this evolution of Acropolis technologies into the core platform over time, we're selfishly excited to  have been chosen to pave the road from here to there for customers building Composite client applications. 

 

What is WPF Composite Client?

This is not a  new version of CAB . It is an entirely new  set of  libraries and guidance,  built from the ground  up, targeting development of new WPF Composite applications.  We'll be working with both the UIFX and WPF teams, the same people who build the platform.

We are  not discarding everything that we did in the client space and starting from scratch. We've done a lot of work around patterns such as Modularity (composition), Services, Dependency injection, Event Brokering,  etc.  These concepts are  essential for  building Composite applications  and we will carry  them forward  into the new guidance.  However, you should expect their manifestations to be very different than what  you see today in CAB.  We're not changing the APIs for fun. We think there are  numerous compelling reasons  to do so:

 

1. CAB was not built to support WPF.   While you can get a n  application to work in WPF  using some flavor of CAB , you can't make use of WPF's full functionality. WPF is an inherently different paradigm than WinForms. For example,  RoutedEvents in WPF are entirely different than WinForm Events. Controls in WPF are look-less while in Win Forms controls have a specific look and feel, etc.

2. WPF does not offer the "Drag" and "Drop" Win Forms development experience. CAB  development scenarios depend upon the rich tooling and productivity experience provided by Visual Studio.  The WPF developer experience is entirely different  and incompatible.  We feel that customers  will not succeed in mechanically migrating their existing WinForms applications to WPF  and should not try. There are no upgrade wizards  such as the VB6 to VB.NET migration tools.  The transition from WinForms to WPF requires substantial effort and most developers face a steep learning curve. For these  reasons, the new offering  will not focus on migration scenarios.

3. We've learned. Over the years we've  received  great  feedback , positive and negative,  on  our CAB implementation.  We've heard  many times  that  it  is too heavy,  too complicated, too tightly coupled, too hard to grasp, etc.  Acropolis evaluators have provided new insights and suggested new approaches. We think the best way to address the concerns and tackle the new ideas -- perhaps the only way -- is with a clean break. 

4. Win Forms is not dead. I've actually had emails from customers saying that Win Forms was being retired this year . This myth must be dispelled. Win Forms  is very much alive and there are future investments in Win Forms yet to come. Win Forms is the recommended breadth solution for LOB application development for the foreseeable future.

 

What about Migration?

I am sure there many who are reading this post and thinking "I need to migrate  my existing application to WPF".

My first instinct is to ask  "Why?"  Honestly. I see so many developers moving to WPF  for no better reason than that it is the new thing.  They are unable to articulate a business need. 

Many  developers believe they can take their Win Form development skills into WPF and have a similar development experience with the added benefit of much richer animations, styling, etc.  It is not that easy in our experience. We  strongly advise that you invest a significant evaluation effort before you commit down  this path.  If you cannot make this investment, we recommend that you stick with WinForms until the  support for  WPF  development evolves. For more information about using WPF for LOB applications, see David Chappel's whitepaper found here.

 

If you have  done your due diligence and still want to migrate to WPF then there two options we can recommend :

1. Use the interop capabilities with SCSF 2007. SCSF 2007 ships with interop support that allows you to host WPF components within an existing WinForm Smart Client application. This is ideal for brown-field scenarios wherein you host rich islands of WPF content within your existing  Win Form  application. For  example, you could display a WPF Smart Part  containing a rich 3D visualization side by side with your traditional CAB Smart Parts and use EventBroker to communicate between them.

2. Use the WPFCAB layer in SCSFContrib. WPFCAB is an open-source implementation of the UI layer for CAB. Kent Boogaart along with help from Matias Woloski of Southworks have done a fabulous job of translating the work we've done for Windows directly into WPF with a pure WPF Shell, Smart Parts, Workspaces, Commands, etc. Several Enterprise customers are using WPFCAB today. Kent, Southworks and the SCSFContrib community are intent on taking WPFCAB forward and enhancing it in the future. We strongly recommend SCSFContrib to customers who are intent on migrating existing SCSF/CAB apps to WPF.

 

What about SCSF and Visual Studio 2008?

I am happy to announce that we are currently working on a release of SCSF/CAB for Visual Studio 2008. For more information about this, see this post.

 

So what's next?

We  have a plan to ensure that what we deliver is what you need. We will be sharing the design broadly so you can see the direction clearly and comment along the way.

As I mentioned above, we  have not committed to the  design of the new guidance . We know only that it will incorporate well known patterns for composite applications. Over the next few months we will engage  with several prominent external community SMEs (Subject Matter Experts) and MVPs. This will lead to a week long session in Redmond where we will determine the essential design together.  

After the  initial design is complete, we will be begin development.  We will not hibernate for a long period and deliver a monolithic release. Instead we plan to develop several small deliverables that we will ship in a piecemeal fashion. This will give customers the chance to try the guidance and give us feedback. 

If you are or will be building composite WPF applications, are a WPF expert and are interested in being part of this process, please contact me, gblock@microsoft.com

 

When

Our target is to have all of the new guidance ship before the end of 2008.

Keep watching my blog and Blaine's for more on this. There's much more to come on the new WPF Composite Client, stay tuned!