Another day, another way... I will try to answer my question even though I have only limited knowledge about PRISM. In other words: I'm still learning.

The Custom Export Attribute taken from the Stock Trade RI is used by the AutoPopulateExportedViewsBehavior. This behavior adds a view to its region automatically by checking the Export Attribute for the region name then adds the view to the corresponding region. But all views with this Custom Attribute now have a contract name of "object" which makes it impossible for the ServiveLocator to find them. This Custom Attribute is for a scenario with fixed region/view links. A solution when working with a Custom Export Attribute is to get all exports of type "object" and the appropriate metadata:

MyView view;

var myList = container.GetExports<object, IViewRegionRegistration>();

foreach (Lazy<object, IViewRegionRegistration> lazy in myList)

{

    if (lazy.Metadata.ViewName == "MyView")

    {

        view = lazy.Value as MyView;

        region.Add(view);

        break;

    }

}

But I think when using ViewInjection and Prism Navigation it is better to just use the default [Export] attribute, then everything works smoothly.

Are you configuring the aggregate catalog in your MEF bootstrapper? If so, are you adding the assembly that contains your ViewExportAttribute and AutoPopulateExportedViewsBehavior classes? I believe this happens in the StockTraderRI's bootstrapper with this line:

this.AggregateCatalog.Catalogs.Add(new AssemblyCatalog(typeof(StockTraderRICommands).Assembly));

The StockTraderRICommands class is in the same assembly as the ViewExportAttribute and AutoPopulateExportedViewsBehavior classes.

The custom export attribute passes typeof(object) to the base constructor, which changes the contract exported so that it no longer matches the import. Change it so it calls the parameterless constructor.

As far as the activation error you'll need to look at the exception in more detail. The root cause is probably there somewhere, perhaps buried under an InnerException.

I encountered exactly the same problem and it was a hard one for a MEF/PRISM beginner. okieh describes the problem very well, I just want to post an alternative solution, coming from theStocktraderUI sample application:

The solution works (/seems to work) if you want View discovery without any form of config file, etc. where you have to register your views.

1. Modify the ViewExport custom event

[Export]

[AttributeUsage(AttributeTargets.Class, AllowMultiple = false)]

[MetadataAttribute]

public sealed class ViewExportAttribute : ExportAttribute, IViewRegionRegistration

{

    public ViewExportAttribute()

        : base(typeof(UserControl))

    { }

    public string ViewName { get { return base.ContractName; } }

    public string RegionName { get; set; }

}

The [Export] attribute is added and the base constructor is now called with UserControl instead of object. That way it can be discovered by MEF.

2. Modify AutoPopulateExportedViewsBehavior

[ImportMany(typeof(UserControl))]

public Lazy<UserControl, IViewRegionRegistration>[] RegisteredViews { get; set; }

The [ImportMany] attribute is added and the type of the Lazy initializiation is changed to UserControl. Now, all UserControls with IViewRegionRegistration-implementing MetaData-type are imported.

That's basically it. You can use the [ViewExport] as before. Note, that Views are limited to (sub)types of UserControl. I suppose this can be modified if you want to. And make sure your aggregate catalog imports the ViewExportAttribute and the AutoPopulateExportedViewsBehavior, as Nicolaus said...

This way, you don't need additional interfaces for your views and can still discover everything without hardcoded registration.

I hope it helps and let me know, if I missed any drawbacks of my solution.

http://stackoverflow.com/questions/6271167/prism-4-registerviewwithregion-custom-export-attributes