Wes' Puzzling Blog

... trying to solve the puzzles of .NET

  • MEF Preview 9 released

    MEF preview 9 has been released on codeplex http://mef.codeplex.com/releases/view/40606.

    The only changes are some bug fixes for the .Net version and a couple additions to the SL version.

    • We brought back PackageCatalog but redesigned it under the name DeploymentCatalog and put it in System.ComponentModel.Composition.Initilization.dll
    • We renamed PartCreator to ExportFactory and put it in System.ComponentModel.Composition.Initilization.dll
    • Renamed type PartInitializer to CompositionInitializer
    • Renamed method CompositionHost.InitializeContainer to CompositionHost.Initialize

    This drop contains a MEF.sln which loads in VS2008 and builds MEF against .Net 3.5 and MEFSL.sln which loads in VS2008 and builds MEF againts SL3. The API's are pretty much what we are shipping in .Net 4.0 and SL4 SDK respectively. However if you need a .Net 4 version of MEF we suggest that you install the RC version of .Net 4 and if you need an SL4 version of MEF you install the Silverlight 4 beta SDK.

    As aways if you have issues or questions related to MEF feel free to post them in our dicsussion forums at http://mef.codeplex.com/Thread/List.aspx.

    For some more detailed explanations of the changes in this preview have a look at Mike Taulty's post http://mtaulty.com/CommunityServer/blogs/mike_taultys_blog/archive/2010/02/17/new-mef-drop-preview-9-on-codeplex.aspx.

  • Should MEF support non-shared components?

    Hamilton has posted about the question of whether or not MEF should support non-shared as well as shared components (non-shared==factory and shared==singleton in our current public bits). In an ideal world we would love to support both but currently every solution we've come up with to support non-shared components has issues. We could pick a solution that we feel properly balances the advantages and disadvantages but that would require us to foresee exactly how the world is going to use MEF. While we believe we could pick a reasonable balance there is fear that we would pick the wrong balance for the majority of our future users. Therefore one approach to combat this is to not support non-shared components, at least in V1, and see what usage patterns reveal themselves in the wild and target that balance in V2.

    Do you feel that it would be a mistake for the MEF team to only support shared/singleton components in V1? Keep in mind that there are patterns, as Hamilton pointed out, to still support non-shared/factory if you needed that support in V1.

  • Job openings on the .NET Framework Core Team

    We have been incubating ideas about building a simple extensibility framework for some time. Now, as plans for the next version of the .NET Framework crystallize a bit more, we decided to productize the project. As a result, we have opened a job position (and most probably will be opening more) on the .NET Framework team. If you are interested, please see details here and send me an email at “kcwalina at microsoft.com.”

    So, what is this extensibility framework? Initially, it will be a low level core .NET Framework feature to make it easy for applications to expose extensibility points and consume extensions. Think about what for example FxCop has to do define rule contracts and load rule implemented by the community. These are the basics, and we can talk about the broader and longer term vision when you come to Redmond for an interview :-)

    This is a technical Program Manager position in Redmond, WA, and it’s basically exactly the job I did when I joined Microsoft. Besides working on the Framework features, all Program Managers on the core team have opportunities to work on API design and architecture projects.

    [Job Openings on the .NET Framework Core Team]

  • 2008 Scripting Games

    It’s the third annual Scripting Games, the biggest scripting competition of the year! As a matter of fact, it’s most likely the biggest scripting competition ever. (The fact that it may be the only scripting competition is beside the point.)

  • All Outlook object model calls run on the main thread

    While writing an Outlook addin, lots of people feel that they should try to help with Outlook performance by running their addin code on a background thread. While this can help in some scenarios it can actually make things worse in others, particularly if the addin is interacting primarily with the Outlook Object Model (OOM). The OOM is run in a single threaded apartment COM server, therefore every COM call is executed on the main thread of outlook.exe.