Acropolis is no more

Question

According to the post below, Acropolis is dead even before seeing its official release. For all the supports given to the framework so far this news is quite sudden. My question is how hard it is going to be to migrate Acropolis-based work to whatever-alternative in the future? In other words, how similar is Acropolis and its future replacement?

 

http://blogs.msdn.com/johnmullinax/archive/2007/10/29/acropolis-is-dead-long-live-acropolis.aspx

The Acropolis team announced today that Acropolis will not advance from CTP to a supported release.  (For more on Acropolis, see this post.)  But, they also announced that they want to help customers who'd like to take Acropolis into production be successful until an alternative is available. 

And perhaps the most important part of the announcement is that an alternative is, indeed, in the works.  This will be delivered by the Patterns and Practices team.  Glenn Block has a rundown on the thinking here.  It seems that many of the composite app learnings around modularity, services, event brokering, etc., will be preserved.  And yet, the go-forward approach is apparently new enough to warrant a new name. 

Answer 1

Hi Long,

 

Please note that Acropolis is a Technology Preview only, and should not be used in live production. Because of that, I do not understand why you will need to migrate any "Acropolis"-based work. That said, if you do have sample code that needs to be migrated, I suggest you email Glenn Block from the Patterns and Practices team about the migration guidance.

 

Thanks,
Kathy Kam

Program Manager

Microsoft

Answer 2

Hi Kathy, thank you for the reply.

As an early adopter of .Net 3.5 and VS2008, I looked around for a WPF MVC framework. Just few months ago, Acropolis seemed to be a good bet for long running projects; superseding the CAB. So I used Acropolis for some of the work. With the latest announcement that the spotlight is on WPF CAB, likely I need to rollback some of Acropolis based work.

Answer 3

The question I have (to Microsoft) as a contract developer trying to be a good steward with my clients resources and manpower is what direction to recommend when we take on a new WinForm project.   CAB and SCSF were dead as long as Acropolis was on the horizon; now Acropolis is dead and no commitment is being made to CAB or SCSF.  

Although the steep learning curve to obtain a working knowledge of CAB was well worth the investment to me; the return on investment may not be there for the junior developers or future developers that have to maintain an application based on CAB - particularly when it is dead again because the next Microsoft supported CTP hits the horizon.

 

I'm a Microsoft Crony and have had long debates on prior contracts with VB/Java/GOF folks (event pattern rules!) and find myself at a loss because I'm standing at the cross-roads not knowing which direction to take.   I'm looking for the Microsoft sign but it is no-where to be found.....

 

In the absence of direction the safe road seems to build a framework that can be easily maintained by the team; it's real easy to drop a form, menu and wrap an application around MVP/MVC framework without all the overhead of CAB/SCSF. 

 

 

 

Answer 4

@Bill,

 

We actually have committed to CAB/SCSF:

 

1. We are revving SCSF/CAB for Visual Studio 2008 / .NET 3.5.

2. We have worked with the community as part of the SCSFContrib project which is providing further enhancements and extensions to CAB. Part of SCSFContrib includes WPFCAB which is a WPF port of CAB, but there are other pure winform CAB enhancements planned as well.

 

Both were announced in my post. We are also not ruling out the possiblity of further enhancements to SCSF. One area we are looking at for example is ADO.NET Synch framework.

 

Regards

Glenn

Answer 5

 

"We actually have committed to CAB/SCSF"

 

This is encouraging but confidence in it's future was seriously shaken when the Acropolis CTP was released and the official word was that there would be no new releases to CAB/SCSF with talk of migration paths to Acropolis being made.  It seemed odd that it was so quickly put to pasture for a CTP even while the team seemed to constantly remind us it was only a CTP (so as to not get to embedded in it)....

 

Had Acropolis survived, CAB/SCSF would have had no future - it was far to powerful, easy to use and integrated into Visual Studio; my concern is this will not change when the next "Acropolis" emerges.   As a contractor I can justify CAB/SCSF's learning curve for a new .NET staff (because of best patterns and practices) but would require assurances, as I trust other developers would, before I could recommend starting a new project using CAB/SCSF; in light of recent events I'm left with no choice but to recommend against its use.

 

"We are also not ruling out the possiblity of further enhancements to SCSF"

 

What I believe we as a development community require, as we turn to Microsoft for the direction to take, is a commitment to "a direction" so that we can safely invest our time and clients resources in it .   The statement "not ruling out the possibility" lacks commitment and suggest to me that SCSF does not have a future...

 

I've been a Microsoft Crony since the early 80s and have learned that it doesn't pay to stray from the "Microsoft Supported" yellow brick road; life seems to get easier and easier as you stay on it (Visual Studio rules!) so I'm just doing a wait-and-see for the next "commitment" that I can commit to.

 

Answer 6

Hi Bill

 

In patterns & practices our goal is to help customers solve challenges with the platform. As the platform evolves and new solutions emmerge for solving those same challenges, we help customers move from our guidance to that new platform. This is our commitment. We also will continue to assess the problem space and look for other challenges. Had Acropolis survived, we would not have killed CAB, however we would have focused our efforts on getting customers from CAB to Acropolis. We would have also looked at guidance on building solutions using Acropolis and what challenges were there as well. As the direction has changed and the platform answer is several years out, it makes perfect sense for us to refocus our efforts back on CAB and on the new challenges with WPF.

 

I understand your concern about assurances. The one assurance we can give you beyond the shadow of a doubt is that you have the code. Regardless of what direction we go with the guidance in the future, the code is yours to maintain and extend. We've designed it specifically for these two reasons. We don't consider our deliverables like SCSF/CAB, etc products. We consider them guidance in the form of code. 80% solutions. For some customers they are 110%, and for others they are 80%. For this reason customers have the code so they can tailor it to meet their needs. Historically in p&p, we do not pull our guidance from the shelf. We may not do any future releases for a host of reasons, but the code in it's current form is still available for download on CodePlex. Additionally our sustained engineering team continues to provide support. For example our SE team still helps customers with UIP and the App Updater block which we shipped many years ago.

 

As far as the statement, it is an honest statement. SCSF is mature. We know this by many succesful implementations that our customers are building. WPF however has not such answer. WPF is a new platform that customers are desparately needing guidance for, particularly around building Composite Apps. For this reason our focus now is on building a new set of Composite WPF guidance to address those needs. Yes there are certainy things we could do to improve SCSF/CAB, but with limited resources, we can't do everything. BTW, the fact that we announced that we are revving SCSF for Visual Studio 2008 is a proof that we are committed. And the other statement still stands, we are considering possible future revs. For example we are looking at ADO.NET Synch Services and the offline story as one example.

 

As to the future platform answer, again I'll reiterate, it's several years out. We are working actively with the UIFX team to insure that we are going in the same direction. And as always we will be committed to help customers get from here to there when the timing is right.

 

Thanks

Glenn

 

 

Answer 7

Glenn Block [MSFT] wrote:

1. We are revving SCSF/CAB for Visual Studio 2008 / .NET 3.5. 2. We have worked with the community as part of the SCSFContrib project which is providing further enhancements and extensions to CAB. Part of SCSFContrib includes WPFCAB which is a WPF port of CAB, but there are other pure winform CAB enhancements planned as well. Both were announced in my post. ...snip...

My apologies if I've missed it, but I don't see where the new rev of SCSF/CAB is mentioned in that post. Certainly I'd read that post before and hadn't realised you had a new rev of SCSF planned.

James

Answer 8

Hi James.

 

I think your right. We announced it to the Acropolis advisory board, but somehow it slipped out of my post. Apologies on that. I've just done a new post to correct it.