I completely forgot to blog this a couple of weeks ago, but Glenn Block, Product Manager for our UX/Client work, recently announced our plans for providing guidance (ala Composite UI App Block) for WPF applications.
A few important things from Glenn’s post for those familiar with CAB and our other assets in this space:
What is WPF Composite Client?
This is not a _place_holder; new version of CAB . It is an entirely new _place_holder; set of _place_holder; libraries and guidance, _place_holder; built from the ground _place_holder; up, targeting development of new WPF Composite applications. _place_holder; We’ll be working with both the UIFX and WPF teams, the same people who build the platform.
We are _place_holder; 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, _place_holder; etc. _place_holder; These concepts are _place_holder; essential for _place_holder; building Composite applications _place_holder; and we will carry _place_holder; them forward _place_holder; into the new guidance. _place_holder; However, you should expect their manifestations to be very different than what _place_holder; you see today in CAB. _place_holder; We’re not changing the APIs for fun. We think there are _place_holder; numerous compelling reasons _place_holder; to do so:
- CAB was not built to support WPF. _place_holder; While you can get a n _place_holder; application to work in WPF _place_holder; 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, _place_holder; 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.
- WPF does not offer the “Drag” and “Drop” Win Forms development experience. CAB _place_holder; development scenarios depend upon the rich tooling and productivity experience provided by Visual Studio. _place_holder; The WPF developer experience is entirely different _place_holder; and incompatible. _place_holder; We feel that customers _place_holder; will not succeed in mechanically migrating their existing WinForms applications to WPF _place_holder; and should not try. There are no upgrade wizards _place_holder; such as the VB6 to VB.NET migration tools. _place_holder; The transition from WinForms to WPF requires substantial effort and most developers face a steep learning curve. For these _place_holder; reasons, the new offering _place_holder; will not focus on migration scenarios.
- We’ve learned. Over the years we’ve _place_holder; received _place_holder; great _place_holder; feedback , positive and negative, _place_holder; on _place_holder; our CAB implementation. _place_holder; We’ve heard _place_holder; many times _place_holder; that _place_holder; it _place_holder; is too heavy, _place_holder; too complicated, too tightly coupled, too hard to grasp, etc. _place_holder; 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. _place_holder;
- 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 _place_holder; 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.
Read the rest of Glenn’s post here: http://blogs.msdn.com/gblock/archive/2007/10/26/wpf-composite-client-guidance-it-s-coming.aspx