AggregateExportProvider

Jun 27, 2011 at 9:57 AM

Is there any technical reason that build-in AggregateExportProvider has read-only behavior?

We can see in the FWK several implementations of the catalogs that are providing quite flexible way of declaring parts. In the export providers case functionality looks very limited though - by default you can have predefined list of providers without possibility to add/remove them on the fly (which can be very helpful when building modular system that takes in care isolation aspects).

Thanks,
Bartek

Aug 1, 2011 at 9:43 PM

You might be conflating ExportProviders with catalogs - they are very different beasts with very different contracts. Perhaps AggregateCatalog is what you are lookinng for?

Aug 14, 2011 at 5:55 PM

Imagine scenario:

You have plugin A and plugin B (lets assume that both are developed by separate teams). Each plugin is composed from several components (parts) available inside the plugin (so composition of each plugin is encapsulated). For instance we have:

  • Plugin A:
public class A1
{
    [Import]
    public A2 Imported { get; set; }
}

[Export]
public class A2
{
}
  • Plugin B:
public class B1
{
    [Import]
    public B2 Imported { get; set; }
}

[Export]
public class B2
{
}

Now we would like to reach goals:

  1. B2 is not visible in plugin A and A2 is not visible in plugin B
  2. Components in B can be composed from all available exports in B
  3. Similar for A
  4. Both A and B can control what exports are visible outside the plugin

I could reach 1-3 with having 2 separate composition containers - one for each plugin. Then whenever component being composed has specified import - import will be satisfied by available in the container scope parts.

The thing is that 4th goal is dificoult to reach in this case. I could imagine API like:

[ExportScope(ExportVisibility.Application)]
public class C
{
}

public enum ExportVisibility
{
    Plugin = 0,
    Application
}

that would allow me to controll if my exported part is for plugin-internal composition purpose or for application global-composition. So in our case i.e. if plugin B would define class C - then this part can be used by compoenents from both: A and B.

Any ideas?