This project has moved and is read-only. For the latest updates, please go here.

Release date?

Nov 20, 2008 at 7:22 PM
The team asked me to find out - we'll settle for rumors (we know we're asking alot) :O   We have quite the delimna, a golden rule forged in the fires of past experiences such as the demise of Acropolis - "no CTP or Beta allowed".  

With over 20 projects scheduled (potentially the tip of the iceberg) today's scrum meeting revolved around managing the employee object; our current project will be fed by COINS, but we have other projects that will be fed by ADS and yet others by an EDMS system.  Some applications will require information from multiple sources (to be complete).   The discussion - how do we have a single service to obtain employee information from a company that spans cities using different systems.   I unveiled MEF and proposed a system where each source implements an interface to EXPORT.   The service will IMPORT any available sources and use the authoritative source as applicable/configured.  As we move forward with projects we simply have to  implement the interface for the applicable system and drop it in the folder.

They loved it but we're bumping against the golden rule.   I did share something with the team that Glenn Block told me back in the SCSF days - "you have the source".   This carried some weight but the team is still somewhat apprehensive.

Nov 20, 2008 at 9:35 PM
>> The team asked me to find out - we'll settle for rumors

it's been announced that MEF will eventually be part of the standard framework.  I take that to mean that the first official release will probably be with .NET v4.0 (or whatever Framework version that's released contemporaneously with VS2010).
Nov 21, 2008 at 3:17 AM
Thanks for the comment Bill... I totally get why your team has the rule it does have...  I was going to say exactly what Glenn told you ... you have the source code the MEF, so you can stay on it as long as you'd like.     In addition, I will add, take a look at how much usage there is if MEF in VS10... we are already betting big on MEF. 

James is right -- we plan to ship MEF as a key part of .NET Framework 4.   In addition we are making plans to make sure that MEF can be used on .NET Framework 3.5 as well as we know not everyone can upgrade right away... would that be helpful?
Nov 21, 2008 at 6:06 PM
Edited Nov 21, 2008 at 11:50 PM
Thanks for your reply. Please forgive the rant. As a steward of the company's resources, we made the the decision to prohibit the use of technologies and features that are not active, released products. This decision comes from a history of working with the Microsoft suite of technologies and how Microsoft, in the past, has [seemingly arbitrarily] terminated a project or unilaterally modified it's feature set between CTP and RC as well as between RC and Release. At times this has been for the better, and at times it has been for the worse. Actually it is more times for the better, but some examples of this are [as Bill indicated] the mysterious demise of the Acropolis project, the "silent" deprecation of SQL Server Notification Services in SQL 2008, VS2010's lack of support for SQL2005, et al. Bill and I and the rest of the team have discussed this "golden rule" at length and what it means for us, as a team as well as in the larger context of the company. We aim to stay at the "leading" edge, not the "bleeding" edge. We aim to do the right thing and to do it the first time. Needless to say, the pace of innovation [discussed in a great thread on Rocky Lhotka's CSLA Blog] doesn't make this an easy or trustworthy proposition.

I understand that in order for innovation to occur, features must change, new approaches need to be tried, etc.; however, it seems that the seemingly constant rate of change in the development sphere is leading us to refactor the design as soon as it is released...or in a worst case scenario, while it's still in development or best case scenario within a year after release. I have to say that, from the business point of view this seems like a lot of churn just to "stay current". We follow P&P, we use IoC [Unity], we're Agile, we're using TFS for Automated Daily Builds, Automated Unit Tests, TDD, we're doing CI, we avoid technical we mature our successes increase as does our value to the organization. On the other side of the coin, we may be <grimace>successful</grimace> but if we have to "fix" our product as soon as it's released, the confidence of the stakeholders is diminished. In order to limit adding any more "re-work" to the product backlog, we choose to limit the foundation to include only "commercially supported" products.

With the advent of Web 2.0 and team blogs as well as the strategic shift within Microsoft regarding communication of project information [earlier and better] the visibility of these types of changes seem to be coming earlier and more clearly. Because I realize that Microsoft must be facing some of these same challenges with MEF as it relates to VS2010 and I'm left to assume that in this case "they" do not want to be facing any significant volume of re-work that wold result from a significant feature set change in the MEF product. In this case, we will likely bend the rule.  We appreciate the hard work and dedication that goes into putting together projects/products like MEF and we REALLY appreciate the stuff that comes out of P&P. Understand that the criticism is operational in nature, and is not a reflection on the great "stuff" that Microsoft does. In truth, Composite WPF, Unity and MEF looks like the "Holy Grail" because it provides a true facility for loose coupling, dynamic dependency injection, and interface abstraction [Silverlight vs. WPF]...and as such we certainly don't want to "look a gift horse in the mouth".

It does help to know that Microsoft is putting a lot of stock in MEF [via it's dependency in VS2010], and it somewhat helps to know that there will be a solution made available for .NET 3.5 [although no indication of a relative timeframe for the .NET 3.5 piece leaves me a little uneasy and as such we're going to make the assumption that our solution will ultimately depend on .NET 4.0 and in the meantime will depend on the binaries from this project]. BTW- I love the Framework Design book...great work!