patterns & practices works towards helping those developing on the Microsoft platforms more successful.  We produce books, reference implements, and libraries that help people in developing web, client, and mobile applications.  You can find out more what p&p does and how we do on our dev center.

As a p&p developer you will have the opportunity to work on a number of projects throughout the year.  Our projects run between two and six months in length and focus on the latest Microsoft (and related) technology stacks:  ASP.Net MVC, HTML5, Javascript, Azure, Windows 8, Windows Phone 7, and WPF.  You will work with other talented developers, program managers, testers, and writers in an agile process to help customers better understand how to solve specific challenges and help communicate those solutions.

You will get opportunities to meet and talk with customers most weeks, as well as presenting at our yearly p&p symposium and other conferences.  Developers also typically blog, deliver podcasts, and engage in discussions with our customers on our Codeplex forums.

If you were at p&p this year you could have worked on:

Building modern mobile web apps – Building great mobile experiences based on device capabilities and feature detection.

Wasabi and Topaz – Enterprise Library 5.0 Integration Pack for Windows Azure – Creating highly resilient and scalable Windows Azure applications with auto-scaling and transient fault handling.

Developing an Advanced Windows Phone 7.5 App that Connects to the Cloud – Building a Windows Phone 7.5 that integrates with Windows Azure-based services.

Building Testable Windows Phone Applications – How to easily build testable Windows Phone 7.5 applications.

The CQRS Journey Project – Applying the Command and Query Responsibility Segregation (CQRS) and Event Sourcing (ES) patterns for building scalable applications on Windows Azure.

Building Metro-style applications in C++/XAML. – Applying your C++ knowledge in building Windows 8 Metro-style applications with C++/XAML.

Where do I apply?

If you’re interested, you can apply through the Microsoft Careers site.  The posting is:

Sr. Software Development Engineer - 797347

This position expects the candidate to work out of the Redmond office.  When you apply be sure to let the recruiter know you’re interested in this specific position and in working for p&p.  You can email me directly as well at bob dot brumfield at micro… dot com.

This will be a multi-part series and the first installment is already up.  It sounds like he'll be adjusting the content based on people's interests so be sure to follow along and provide feedback.

More details on his blog.

If you've always wanted to know a bit more about Prism, or just wanted to brush up what's in the 4.0 release, this course will help.  The course topics include:

• Bootstrapper and Shell
• Regions
• Modules
• Views
• Navigation
• Communication

Patterns & practices works towards helping those developing on the Microsoft platforms more successful.  We produce books, reference implements, and libraries that help people in developing web, client, and mobile applications.  You can find out more what p&p does and how we do on our dev center.

As a p&p developer you will have the opportunity to work on a number of projects throughout the year.  Our projects run between two and six months in length and focus on the latest Microsoft (and related) technology stacks:  ASP.Net MVC, HTML5, Javascript, Azure, Silverlight, WPF, Windows Phone 7, and SharePoint.  You will work with other talented developers, program managers, testers, and writers in an agile process to help customers better understand how to solve specific challenges and help communicate those solutions.

You will get opportunities to meet and talk with customers most weeks, as well as presenting at our yearly p&p symposium and other conferences.  Developers also typically blog, deliver podcasts, and engage in discussions with our customers on our Codeplex forums.

If you were at p&p this year you could have worked on:

Enterprise Library Silverlight Integration Pack (in progress) – Enabling relevant portions of the Enterprise Library to the Silverlight space, including validation, logging, and exception handling.

Web Client Guidance (upcoming) – Focusing on building web applications with ASP.Net MVC 3, the Razor View Engine, HTML5, CSS3, and jQuery.

Windows Phone 7 Developer Guide – Developing Windows Phone 7 applications that interact with Azure.

Developing Applications for the Cloud – Developing applications on the Microsoft Windows Azure platform.

Prism 4 – Building guidance for developing applications on Silverlight and WPF and Windows Phone 7 using MVVM and modular design concepts.

Parallel Programming with Microsoft .NET – Approaches and patterns to introducing parallel execution into your code.

Where do I apply?

If you’re interested, you can apply through the Microsoft Careers site.  The posting is:

Software Development Engineer - 746816

This position expects the candidate to work out of the Redmond office.  When you apply be sure to let the recruiter know you’re interested in this specific position and working for p&p.  You can email me directly as well at bob dot brumfield at micro… dot com.

CompositionInitializer

The MEF CompositionInitializer is intended to provide a way to satisfy MEF imports on an object in situations where you can’t necessarily build the item in the container.  This may occur where you’re using a framework that builds the objects for you, but not in the container of your choice such as in in the application startup logic of a Silverlight application. 

You might use it like this in your Silverlight App.xaml.cs if you wanted to import  something like a logger or main view-model into your App.

private void Application_Startup(object sender, StartupEventArgs e)

{

    CompositionInitializer.SatisfyImports(this);

}

...

[Import]

public MainViewModel MainViewModel

{

    get;

    set;

}

You can read a bit more about CompositionInitializer on MSDN and on the MEF Codeplex site.

Under the covers, the CompositionInitializer is creating its own container and making it available through the CompositionInitializer static interface.  Since Prism also creates it’s own composition container, both Prism and the CompositionInitializer static interfaces need to point to the same container to be able to work together well.   You can setup this connection in Prism bootstrapper you create for your app by calling CompositionHost.Initialize.  This initializes the CompositionHost with the container that Prism uses of instead of creating a new one.  Perhaps the easiest place to do this in the CreateContainer override of your Prism application bootstrapper:

public class AppBootstrapper : MefBootstrapper

{

...

    protected override CompositionContainer CreateContainer()

    {

        var container = base.CreateContainer();

        // Initialize the CompositionHost so we can use CompositionInitializer

        CompositionHost.Initialize(container);

        return container;

    }

...

}

Sample With Composition Initializer

The attached sample application shows a Prism application using CompositionInitializer in two places: in the app startup and in a view’s constructor.  In the App, it uses the initializer to import an ILoggerFacade so it can log the start and exit of the application.  It also shows a view that, in its constructor, uses CompositionInitializer to import its view-model.

The App.xaml.cs starts the bootstrapper (which calls the CompositionHost.Initialize as shown above) then satisfies imports on itself which injects the ILoggerFacade:

private void Application_Startup(object sender, StartupEventArgs e)

{

    new AppBootstrapper().Run();

    CompositionInitializer.SatisfyImports(this);

    Logger.Log("Application starting", Category.Info, Priority.Low);

}

…

[Import]

public ILoggerFacade Logger

{

    get;

    set;

}

After the SatisfyImports call, the Logger dependency will have been resolved and the App can then use that dependency.  Similarly, the InjectedViewWithInitializer uses the CompositionInitializer.SatisfyImports to inject it’s view-model dependencies:

    public partial class InjectedViewWithInitializer : UserControl

    {

        public InjectedViewWithInitializer()

        {

            InitializeComponent();

            // Using CompositionInitializer to satisfy imports for this view.

            // Because the AppBootstrapper called CompositionHost.Initialize()

            // the container is the same as the one built up by Prism.

            CompositionInitializer.SatisfyImports(this);

        }

        [Import(typeof(TimerViewModel))]

        public object ViewModel

        {

            get { return this.DataContext; }

            set { this.DataContext = value;}

        }

    }

Prism, MEF, and Shared Services

When sharing these services across remotely downloaded modules, there is not much difference from doing this with MEF than with a container like Unity. For this sample, there is a service module that offers an implementation of a TimeService that simply returns the current time and two modules that provide views consuming the time service.  Here’s what it looks like:

Not too fancy, but it hopefully demonstrates the point.  ModuleA and ModuleB are dependent upon the TimeServiceModule.  ModuleA provides two views:  one view uses CompositionInitializer to resolve it’s view-model and one view receives it’s view-model when it’s constructed in the MEF container by the RegionManager.  ModuleB provides a view that directly imports the TimeService. 

The modules don’t directly know about each other.  The ITimeService implementation is in a shared assembly.  The Prism ModuleCatalog.xaml defines the dependencies between the modules and specifies that all modules are downloaded in the background and initialized when available:

    <Modularity:ModuleInfoGroup>

        <Modularity:ModuleInfo Ref="TimeService.xap" InitializationMode="WhenAvailable" ModuleName="TimeService"  />

        <Modularity:ModuleInfo Ref="ModuleA.xap" InitializationMode="WhenAvailable" ModuleName="ModuleA">

            <Modularity:ModuleInfo.DependsOn>

                <sys:String>TimeService</sys:String>

            </Modularity:ModuleInfo.DependsOn>

        </Modularity:ModuleInfo>

        <Modularity:ModuleInfo Ref="ModuleB.xap" InitializationMode="WhenAvailable" ModuleName="ModuleB">

            <Modularity:ModuleInfo.DependsOn>

                <sys:String>TimeService</sys:String>

            </Modularity:ModuleInfo.DependsOn>

        </Modularity:ModuleInfo>

    </Modularity:ModuleInfoGroup>

During ModuleA initialize, the InjectedViewWithInitializer is constructed and added directly to the region on the shell:

public void Initialize()

{

    logger.Log("Initializing ModuleA", Category.Info, Priority.Low);

    // We create a new instance of InjectedViewWithInitializer and add it to the region.

    // Inside InjectedViewWithInitializer, it uses CompositionInitializer.SatisfyImports(this)

    // to resolve its dependencies.

    // Because we initialize the CompositionHost in the bootstrapper with the container

    // that Prism will use, it can get all the services registered with Prism

    this.regionManager.Regions["ContentRegion"].Add(new InjectedViewWithInitializer());

    // Another approach is to use the view registry which will automatically build

    // the type up in the container:

    this.registry.RegisterViewWithRegion("ContentRegion", typeof(RegionRegisteredView));

}

Module A also shows another approach to building a view against a region, one more traditionally used in Prism .  This registers a view’s type against a region so that the view is built  when the region is shown (also known as view discovery).  Since the view is built in the MEF container during this process, any of it’s [Import] or [ImportingConstructor] dependencies are satisfied.

Module B shows another view that relies on the TimeService merely to demonstrate multiple modules dependent on the same service.  In this sample, the ITimeService interface actually lives in a separate Shared assembly while the exported implementation lives in TimeService assembly.

One thing to be wary of with MEF and using remotely downloaded modules in Prism is having more than one module reference the same assembly that include [Export] attributes.  By default, adding a reference to an assembly will set the CopyLocal property to True which means a copy of the referenced assembly is included in the modules Xap file.  When using MEF, Prism uses the DeploymentCatalog to retrieve the module Xaps.  As these Xaps are downloaded, the DeploymentCatalog will add these assemblies to the MEF container.  If more than one Xap includes the same assembly, it will be exported multiple times.  This may result in a MEF recomposition error like the one shown below if the export cannot be ‘recomposed’ (more information about MEF DeploymentCatalog and recomposition is available on the MEF Codeplex site.):

The composition remains unchanged. The changes were rejected because of the following error(s): The composition produced a single composition error. The root cause is provided below. Review the CompositionException.Errors property for more detailed information.

1) Change in exports prevented by non-recomposable import 'ModuleA.TimerViewModel..ctor (Parameter="timeService", ContractName="ServiceModule.ITimeService")' on part 'ModuleA.TimerViewModel'.

Check the InnerException property of the exception for more information. If the exception occurred while creating an object in a DI container, you can exception.GetRootException() to help locate the root cause of the problem.

You can solve this by making sure the assembly is included in only one Xap file by setting the CopyLocal property to False for all but a single Xap.

Compiling the Sample

You will need to download and reference the Prism binaries from the MSDN web site.  You may also need to set _MainApplication.Web as the startup project.

PrismMefSatisfyImports.zip

He has some early bird pricing until the end of the month.  Find out more details here: www.programprism.com.

He’s always a treat to listen and learn from, so if you’re interested in getting started with Prism or learning a bit more about it, check out this class.

This is largely the same code, with these additional items:

• Added the Quickstarts and Acceptance test projects back in.  These are the same as the ones available in version 2.1.
• A more complete test pass.
• A smoke test when targeting all projects to .Net 4.0

Additionally, we’ve posted the source to the ProjectLinker that can also work in VS2010.  We plan on shortly posting the ProjectLinker to the Visual Studio Gallery, to make it a bit easier to consume.

The changes are:

• All projects updated to Visual Studio 2010
• All test projects now target .Net 4.0
• Note: The WPF library projects still target .Net 3.5
• All Silverlight projects update to target Silverlight 4.0
• Prism is updated to use the latest Unity 2.0 binaries.
• The Reference Implementation uses the latest Unity 2.0 and Enterprise Library 5.0 binaries.
• The Silverlight Reference Implementation now uses the latest binaries from the Silverlight Toolkit (primarily for charting).

This update does not include converted Quickstarts or a VS2010 version of the ProjectLinker.

While the code is largely unchanged, we have only done light smoke testing on this after the updates so use at your own risk.  If you do encounter any problems with these updates, let us know.

Enjoy and be sure to give us feedback on the EntLib Codeplex site.