WPF Composite Client, it's coming!

Article
10/26/2007

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!

Comments

Anonymous
October 29, 2007
The Acropolis incubation project has been a great learning experience for us and we have received a lot
Anonymous
October 29, 2007
We just announced a new deliverable called WPF Composite Client. Due to the wonders of the blogosphere
Anonymous
October 29, 2007
The Acropolis team just announced that the core Acropolis concepts will be rolled into future .NET Framework
Anonymous
October 29, 2007
There is a lot of new information, all announced today, about the future of Acropolis, CAB, and WPF guidance
Anonymous
October 29, 2007
Today, our team gave an update on the "Acropolis" project in the Acropolis team blog here . In response
Anonymous
October 29, 2007
Today, our team gave an update on the "Acropolis" project in the Acropolis team blog here
Anonymous
October 29, 2007
Acropolis is Dead!!! Long Live Acropolis!!!
Anonymous
October 29, 2007
Under MSDN Live så berättade jag och Robert om att Acropolis inte skulle se dagens ljus i den utformning
Anonymous
October 29, 2007
Glenn asked me to keep this quiet until today. As Glenn just announced, the patterns & practices
Anonymous
October 29, 2007
Back in June, Microsoft announced Acropolis . Now, the Acropolis team and the Patterns & Practices
Anonymous
October 29, 2007
The Acropolis team announced today that Acropolis will not advance from CTP to a supported product. (For
Anonymous
October 29, 2007
Today, on Acropolis team blog, they announced that they are moving Acropolis to "some future release" and that the good news is that P&P team announced working on WPF composite guidance... http://blog.vuscode.com/malovicn/archive/2007/10/29/acropolis-team-blog-acropolis-on-the-bench-p-amp-p-scsf-back-on-the-field.aspx
Anonymous
October 29, 2007
After the announcement about the death of Acropolis , Glenn just announced that the patterns & practices
Anonymous
October 29, 2007
Some comments on why we chose to move to WPF for a LOB application http://www.bizcoder.com/index.php/2007/10/29/why-wpf-for-lob-applications/
Anonymous
October 29, 2007
I just exposed my ignorance on this subject in a blog post: http://neverindoubtnet.blogspot.com/2007/10/requiem-for-acropolis-fanfare-for-cab.html
Anonymous
October 29, 2007
Acropolis Team Blog : A new phase for the Acropolis project My Technobabble WPF Composite Client, it's
Anonymous
October 29, 2007
If you're been looking into the Acropolis project for building composite applications, take a look at
Anonymous
October 29, 2007
Acropolis Out, WPF Composite Client Applications in! Back in June 2007, during Teched Orlando, Microsoft
Anonymous
October 29, 2007
Some top news has been circulating over the past few days or so - Glenn Block has a good summary . Basically
Anonymous
October 29, 2007
Наработки проекта будут включены в следующие версии .NET Framework и в "WPF Comp
Anonymous
October 29, 2007
WPF Composite Client / Acropolis Future
Anonymous
October 30, 2007
Windows Presentation Composite Client For those ISV's who have been looking forward to a way to combine
Anonymous
October 30, 2007
Windows Presentation Composite Client For those ISV's who have been looking forward to a way to combine
Anonymous
October 30, 2007
Few months back I tried the new client framework Acropolis and was pretty surprised by the features it
Anonymous
October 30, 2007
Composite Applications became defined when the Patterns & Practices group released the Composite
Anonymous
October 30, 2007
A story in pictures... ( + ) = http://blogs.msdn.com/acropolis/archive/2007/10/29/An-Acropolis-Update.aspx
Anonymous
October 30, 2007
The comment has been removed
Anonymous
October 30, 2007
Sorry I wish I could edit my previous post. When I said: well we maybe on the 2nd or 3rd iteration of CAB it should be well maybe on the 2nd or 3rd iteration of WPF... that should clear it up.
Anonymous
October 30, 2007
A story in pictures... ( + ) = http://blogs.msdn.com/acropolis/archive/2007/10/29/An-Acropolis-Update
Anonymous
October 30, 2007
@Matthew

The WPF tooling support in VS2008 (Cider) is not going to give you something equal to the developer experience with WinForms. It does not replace the drag & drop / debugging experience that you are accustomed to in the IDE today. Yes the styling is richer, the animations are richer, the graphics are richer. However, the paradigm is entirely different, the ramp up is much greater and the experience is different.
Our recommendation for building composite smart client apps today is to use SCSF/CAB. CAB does have it's complexities however we've had overwhelming satisfaction and adoption from .NET customers. That being said it is not the end all. If you are not building applications that contain the patterns / scenarios CAB addresses, i.e. Modularity (multiple teams in isolation), Dependency Injection, Service Location, PubSub, Separation of concerns, etc then CAB may not be right for you.
About your issues with CAB, I'd be happy to hear where the complexity / bloat lies, and where your pain points are with using it.

Anonymous
October 31, 2007
I learned today that there was a book published a few months ago on two of my favourite technologies,
Anonymous
October 31, 2007
I learned today that there was a book published a few months ago on two of my favourite technologies
Anonymous
October 31, 2007
Da Acropolis a WPF Composite Client
Anonymous
October 31, 2007
Okay code bloat and CAB & misc pain points:

Extension points are by definition broken. Let me explain... extension points are supposed to provide an abstraction from the shell and the modules to decrease dependancy between them. Unfortunately the opposite happens. Let's say I use an Infragistic's menu in my application. Well all the adapter code really does is create extra code. I still have dependancy from shell and module as they all have to know about the menu control and we all have to be synced on the same control.
Build up and tear down. The process of starting Workitems and closing them is painfully slow (mostly due to reflection). Honestly I think the whole workitem == use case medafore needs serious thought as most people don't use it that way. I have yet to see a good implementation using nested workitems or even having multiple views for a workitem. The issue is similar with presenters... If the view - workitem - presenter is a 1 - 1 -1 relationship... why use injection? The guidance package is nice but often times it creates an overly complex code structure that the simple (and often used) parts of the application suffer. Instead of solving the 80 / 20 rule in a LOB app CAB actually works in the reverse. It is a complex structure that caters to complex screens and makes simple screens complex and bloated.
Event subscription. There are several bugs in which event subscription actually creates multiple references and ruins weak referenced objects (it basically makes you code back to com days with reference counting). okay that's enough for now... to the points you've made on cider (vs 2008)... It is like starting over with Winforms circa vs 2002. That said I still believe it offers a compelling experience well worth the learning curve. Let's face it you will have to face that learning curve at somepoint. For apps being relesed this year I still recommend Winforms... but as we get closer to vs 2008 I tend to say move towards WPF. Yes you don't get all the stuff you take for granted in Winform development today... but once you get over the curve (which really isn't that bad) I think it is a much better place to work in. Nine times out of Ten I have worked on LOB apps most of the time on GUI is spent on layout, which is not one of Winforms strong points. One of the main reason's I've seen so many companies move over to internal web sites for traditional LOB apps has been layout issues. To me WPF addresses this issue as well as opening the door to new ways to present data that have not been possible. Is it a steep learning curve... yep but much less than CAB and more documentation. One of the things I have always faulted CAB for was the fact the documentation was so poor and there really isn't much in the way of guidance. I have toyed with the idea of writing a book on CAB, but I have issues doing it because I find that the best way to use CAB is to use less of it's features rather than more. The real problem with CAB is it is a framework searching for a problem to solve. It's a mammoth solution that tries to solve a relatively small problem (having a truely plugable app) in a very complex way.

Anonymous
October 31, 2007
Glenn, I disagree with some of the reasons given by Mathew on why CAB feels bloated, but I agree that it feels bloated. In my opinion, it is not a "mammoth solution that tries to solve a relatively small problem". In my opinion, it is a "mammoth collection of solutions trying to solve a corresponding collection of big and small problems". See the difference? Anyway, I feel the "bloated" feeling is mostly due to a lack of specific guidance available for each feature. Features are rarely discussed in isolation, and most of the guidance, tutorials, etc. take you through the core collection of features, which is quite a large number. I believe this causes us developers to feel CAB is bloated beacuse feature A is always explained in conjunction with features B, C, D and E. In truth, I believe we could use it independently, but don't realise that until we are close to the top of the CAB learning curve. And with the curve been as steep as it is, that takes a while. So, in summary, I don't think CAB is bloated. I just think it gives us a bloated feeling until we reach the top of the learning curve and start to be able to understand the concepts and features separately, rather than as this complete solution. You guys did a good job at separating the multiple features of Enterprise Library. Try to break CAB into smaller pieces as well if you can.
Anonymous
October 31, 2007
As a follow up, I just found the following post (dated as 2005, ouch!). http://blogs.msdn.com/gblock/archive/2007/05/27/is-cab-complex-and-if-so-why.aspx In this post you state that we can use CAB for the SmartParts etc. without even using WorkItems. That's what I was talking about. I wouldn't know how to do that, so in the end, I would be developing my application with WorkItems. Do I recommend that people do that? No. At the end, I think we do need to learn how to use WorkItems as well. But just to apply some example of why we get this "bloated feeling".
Anonymous
November 01, 2007
@Alex No I hear where your coming from... I feel similarly. I would be interested to use SmartParts apart from Workitems as we have alot of screens that the whole Workitem - Smartpart - presenter medafore is just too much overhead. Yes we do need to know how to use WorkItems... but comeon...
Anonymous
November 01, 2007
A while ago I posted on the complexity of CAB. Contrary to popular opinion, It's not complex just for complexity sake. However it was built to support some extremely complex UIs. The canonical example that it was modeled off of was the Dell Desktop. This application was originally I think about 40 different systems. The learning curve for new employees was also signficant since each app had it's own nuances. Also the complexities of maintaing such an app were significant. The soluton was to build ann application that used an architecture similaar to CAB. This greatly reduced the maintenance and signficantly improved the usability. This is one of several types of apps that CAB was built to support. CAB can definitely be overkill if you don't have challenges it was built to address. If you aren't having many teams working on different parts of the system in isolation for example.
Anonymous
November 01, 2007
Time for another weekly round-up of developer news that focuses on .NET, agile and general development
Anonymous
November 01, 2007
Time for another weekly round-up of developer news that focuses on .NET, agile and general development
Anonymous
November 03, 2007
Glenn Block has announced that, after the announcement that Acropolis won't be out so soon, the Practices
Anonymous
November 03, 2007
O Glenn Block anunciou que, após o anûncio de que o Acropolis não vai saír tão cedo, a Equipa de Practices
Anonymous
November 04, 2007
A TechEd US 2007 è stato annunciato Microsoft Code Name “ Acropolis ”: un set di componenti e tool pensato
Anonymous
November 08, 2007
Acropolis was a project to make building LOB applications using Windows Forms or WPF much easier than
Anonymous
December 12, 2007
  My blog has been quiet the past few days as I've been busy working on user stories for the new
Anonymous
December 12, 2007
  My blog has been quiet the past few days as I've been busy working on user stories for the
Anonymous
January 15, 2008
Pete Brown has a great blog post here on Silverlight 2.0 and WPF.  Pete makes some great points
Anonymous
January 16, 2008
Yes!! as you read in the title, I'm in Redmond for first time!. I'm very excited with this travel because
Anonymous
February 12, 2008
The comment has been removed
Anonymous
February 12, 2008
The comment has been removed
Anonymous
February 12, 2008
@Rachel Thanks for the feedback. What were the specific experiences that drove you to that statement? In the new work we are doing we are adressing many of the concerns we've heard from customers. It would be great to add yours to the list ;) Regards Glenn
Anonymous
February 12, 2008
We have developed a composite User Interface(UI) framework on top of SCSF which supports WinForms(based on June 2006 SCSF). We have invested a lot of time and energy in developing this framework as we have extended it to support a lot of custom functionalities. Already a lot of apps are in production. Now we are planning to come out with a framework that supports WPF. My question is

Can i migrate my existing framwork based on SCSF to support WPF with less effort?
I saw that there is a framework that supports WinForms and WPF interop but it seems like i cannot leverage all the advantages of WPF in this case.
Your post says there will be a release of CAB with WPF support. Will this be the right option for us?
What about Acropolis? Is it similar to CAB and can i migrate my existing CAB framework to Acropolis? Please suggest what should be done in this case.

Anonymous
February 28, 2008
When you refer to Brown field senarios, I assume an existing CAB application is a good example. BTW, I can't wait for the upgraded SCSF with 2008 support.
Anonymous
March 03, 2008
Last week we launched the Codeplex site for Prism. There you will find all the information related to
Anonymous
March 03, 2008
Last week we launched the Codeplex site for Prism. There you will find all the information related to
Anonymous
March 04, 2008
Olá pessoal, tudo certo? Ainda sobre Fábricas de Software e Guias de Automação, vale acompanhar o que
Anonymous
March 04, 2008
Olá pessoal, tudo certo? Ainda sobre Fábricas de Software e Guias de Automação, vale acompanhar o que
Anonymous
March 06, 2008
For those of you who don't know about the Smart Client Software Factory and Composite Application
Anonymous
March 11, 2008
Some time ago we announced that patterns & practices was going to be delivering a new set of guidance
Anonymous
March 11, 2008
Some time ago we announced that patterns & practices was going to be delivering a new set of guidance
Anonymous
March 12, 2008
Some time ago we announced that patterns & practices was going to be delivering a new set of guidance
Anonymous
April 07, 2008
Acropolis is Dead!!! Long Live Acropolis!!!
Anonymous
August 21, 2008
We're starting a new project and naturally we looked at leveraging the latest .NET framework features

Share via