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



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 (63)

  1. The Acropolis incubation project has been a great learning experience for us and we have received a lot

  2. We just announced a new deliverable called WPF Composite Client. Due to the wonders of the blogosphere

  3. The Acropolis team just announced that the core Acropolis concepts will be rolled into future .NET Framework

  4. There is a lot of new information, all announced today, about the future of Acropolis, CAB, and WPF guidance

  5. Kathy Kam says:

    Today, our team gave an update on the "Acropolis" project in the Acropolis team blog here . In response

  6. Today, our team gave an update on the "Acropolis" project in the Acropolis team blog here

  7. Acropolis is Dead!!! Long Live Acropolis!!!

  8. Under MSDN Live så berättade jag och Robert om att Acropolis inte skulle se dagens ljus i den utformning

  9. Sam Gentile says:

    Glenn asked me to keep this quiet until today. As Glenn just announced, the patterns & practices

  10. Back in June, Microsoft announced Acropolis . Now, the Acropolis team and the Patterns & Practices

  11. Beyond | IT says:

    The Acropolis team announced today that Acropolis will not advance from CTP to a supported product. (For

  12. malovicn says:

    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…


  13. After the announcement about the death of Acropolis , Glenn just announced that the patterns & practices

  14. DarrelMiller says:

    Some comments on why we chose to move to WPF for a LOB application


  15. Acropolis Team Blog : A new phase for the Acropolis project My Technobabble WPF Composite Client, it’s

  16. If you’re been looking into the Acropolis project for building composite applications, take a look at

  17. Acropolis Out, WPF Composite Client Applications in! Back in June 2007, during Teched Orlando, Microsoft

  18. Some top news has been circulating over the past few days or so – Glenn Block has a good summary . Basically

  19. Наработки проекта будут включены в следующие версии .NET Framework и в "WPF Comp

  20. WPF Composite Client / Acropolis Future

  21. Windows Presentation Composite Client For those ISV’s who have been looking forward to a way to combine

  22. Windows Presentation Composite Client For those ISV's who have been looking forward to a way to combine

  23. Few months back I tried the new client framework Acropolis and was pretty surprised by the features it

  24. Composite Applications became defined when the Patterns & Practices group released the Composite

  25. Okay I have to disagree with LOB apps and WPF.  Yes I have a feeling Winforms apps will continue to live on just like VB 6 & COM apps before it.  Once the tool support comes (in VS 2008) I really don’t see a compelling reason to stay with Winforms.  The layout and styling are far superior… why would you want to stay with Winforms? I find the argument to be from a position of denial rather than realistic.  Yes if you are designing an App today… you should be doing Winforms… but by the time CAB gets a new release that might actually be worth it… well we maybe on the 2nd or 3rd iteration of CAB.  CAB is just too much code bloat and I don’t see how that is going to change (I guess I’ll have to wait and see for sure but).  The issues with CAB are well known and have not been addressed since 2005 (save for the smart client framework… which is essentially a guidance package).  The same bloat persists and I don’t see the move to change that (I don’t buy accropolis as an excuse to not fix the issues).  Given the arguments that have been proposed if you are building an app today… use Winforms but no CAB.  If future use WPF and maybe (just maybe) at somepoint we will see a version of CAB that doesn’t well… suck.  (I hate to be so harse as it has some great ideas… just too much bloat).

  26. 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.

  27. @Matthew

    1. 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.

    2. 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.

    3. 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.

  28. I learned today that there was a book published a few months ago on two of my favourite technologies,

  29. I learned today that there was a book published a few months ago on two of my favourite technologies

  30. Da Acropolis a WPF Composite Client

  31. Okay code bloat and CAB & misc pain points:

    1) 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.

    2)  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.

    3)  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.

  32. Alex says:


    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.

  33. Alex says:

    As a follow up, I just found the following post (dated as 2005, ouch!).


    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".

  34. Mathew Upchurch says:


    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…  

  35. 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.

  36. Time for another weekly round-up of developer news that focuses on .NET, agile and general development

  37. Time for another weekly round-up of developer news that focuses on .NET, agile and general development

  38. Glenn Block has announced that, after the announcement that Acropolis won't be out so soon, the Practices

  39. 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

  40. A TechEd US 2007 è stato annunciato Microsoft Code Name “ Acropolis ”: un set di componenti e tool pensato

  41. Acropolis was a project to make building LOB applications using Windows Forms or WPF much easier than

  42.   My blog has been quiet the past few days as I’ve been busy working on user stories for the new

  43.   My blog has been quiet the past few days as I've been busy working on user stories for the

  44. Pete Brown has a great blog post here on Silverlight 2.0 and WPF.  Pete makes some great points

  45. Yes!! as you read in the title, I’m in Redmond for first time!. I’m very excited with this travel because

  46. Rachel Roberts says:

    Having been through a CAB project, by accident, I can easily add CAB should never have been released to the developer community. I am sure MS has learnt a lot, but it has come at a high cost to projects that adopted it.

  47. Roberts says:

    Having been through a CAB project, by accident, I can easily add CAB should never have been released to the developer community. I am sure MS has learnt a lot, but it has come at a high cost to projects that adopted it.

  48. @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 😉



  49. Ranjith says:

    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

    1. Can i migrate my existing framwork based on SCSF to support WPF with less effort?

    2. 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.

    3. Your post says there will be a release of CAB with WPF support. Will this be the right option for us?

    4. 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.

  50. Ben Zamora says:

    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.

  51. Last week we launched the Codeplex site for Prism. There you will find all the information related to

  52. Last week we launched the Codeplex site for Prism. There you will find all the information related to

  53. Olá pessoal, tudo certo? Ainda sobre Fábricas de Software e Guias de Automação, vale acompanhar o que

  54. Olá pessoal, tudo certo? Ainda sobre Fábricas de Software e Guias de Automação, vale acompanhar o que

  55. For those of you who don't know about the Smart Client Software Factory and Composite Application

  56. Some time ago we announced that patterns & practices was going to be delivering a new set of guidance

  57. Some time ago we announced that patterns & practices was going to be delivering a new set of guidance

  58. Glenn Block says:

    Some time ago we announced that patterns & practices was going to be delivering a new set of guidance

  59. CloudSocket says:

    Acropolis is Dead!!! Long Live Acropolis!!!

  60. We're starting a new project and naturally we looked at leveraging the latest .NET framework features