WPF Composite Client, it's coming!
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!
