I kind of like this approach, but does MEF allow an Export on a method? If
so then I suppose I could do something like:
class BarFactory
{
[Import]
IBlah blah;
[Export]
IBar CreateBar()
{
return new Bar(blah);
}
}
I can see how imports could be handled with David's approach though.
Thanks.
On Saturday, September 10, 2011, Michael Minutillo <
[email protected]> wrote:
> One solution would be to add the following class to Foo.dll but it means
you're controlling the creation of Bar instead of getting MEF to do it for
you
> class BarProvider
> {
> [Export(typeof(IBar))]
> IBar ExportedBar = new Bar();
> }
>
>
> Michael M. Minutillo
> Indiscriminate Information Sponge
> http://codermike.com
>
>
> On Fri, Sep 9, 2011 at 2:33 PM, Matt Siebert <[email protected]> wrote:
>>
>> Hey folks,
>> I'm beginning to use MEF in a solution that involves a mix of .NET 3.5
and 4.0 projects. I'm using MEF in the 4.0 projects and I need to register
some exports that live in the 3.5 projects. The problem is I need to do
this from one of the plugin projects.
>> To illustrate this, imagine a console application such as...
>>
>> class Program
>> {
>> static void Main(string[] args)
>> {
>> var program = new Program();
>>
>> var catalog = new DirectoryCatalog(".");
>> using (var container = new CompositionContainer(catalog))
>> {
>> var batch = new CompositionBatch();
>> batch.AddPart(program);
>> container.Compose(batch);
>>
>> program.Test();
>> }
>> }
>>
>> [Import]
>> private IFoo foo = null;
>>
>> public void Test()
>> {
>> Console.WriteLine(foo.Bar);
>> }
>> }
>>
>> IFoo is in another DLL with a concrete implementation...
>>
>> public interface IFoo
>> {
>> string Bar { get; }
>> }
>>
>> [Export(typeof(IFoo))]
>> public class Foo : IFoo
>> {
>> [Import]
>> private IBar bar;
>>
>> public string Bar
>> {
>> get { return "Beer " + bar.Foo; }
>> }
>> }
>>
>> and finally, IBar is in a .NET 3.5 DLL that isn't using MEF...
>>
>> public interface IBar
>> {
>> string Foo { get; }
>> }
>>
>> public class Bar : IBar
>> {
>> public string Foo
>> {
>> get { return "me"; }
>> }
>> }
>>
>> Is there a way to register an IBar export without the console application
referencing Bar.dll?
>> Foo.dll has a reference to Bar.dll and could register the export, but in
order to do this composition must occur first (so that the app can discover
Foo.dll) and that will fail since Foo's IBar import can't be satisfied.
>> Cheers.
>
