Hmm. It appears I have been misinformed by the documentation. Curse you, out of sync build artefacts! *shakes first as sky*
Michael M. Minutillo Indiscriminate Information Sponge http://codermike.com On Mon, Sep 12, 2011 at 12:59 PM, Matt Siebert <mlsieb...@gmail.com> wrote: > Thanks Michael. > > Your code works for me without specifying the type on the Func<IBar> > import. > > The export on CreateBar() doesn't need to specify the type either. > > > On Sat, Sep 10, 2011 at 10:34 PM, Michael Minutillo < > michael.minuti...@gmail.com> wrote: > >> Sorry, you need to specify the type when importing a Func<>, you can't >> leave it blank as I did in my example code (serves me right for not trying >> it before posting) >> >> On Sat, Sep 10, 2011 at 8:31 PM, Michael Minutillo < >> michael.minuti...@gmail.com> wrote: >> >>> You can export a Func<> and then call it. Like this: >>> >>> class BarFactory >>> { >>> [Import] >>> IBlah blah; >>> >>> [Export(typeof(Func<IBar>))] >>> >>> IBar CreateBar() >>> { >>> return new Bar(blah); >>> } >>> } >>> >>> class BarProvider >>> { >>> [Import] >>> private Func<IBar> _factory; >>> >>> [Export] >>> public IBar Bar { get { return _factory.Invoke(); } } >>> } >>> >>> Michael M. Minutillo >>> Indiscriminate Information Sponge >>> http://codermike.com >>> >>> >>> On Sat, Sep 10, 2011 at 7:38 PM, Matt Siebert <mlsieb...@gmail.com>wrote: >>> >>>> 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 < >>>> michael.minuti...@gmail.com> 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 <mlsieb...@gmail.com> >>>> 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. >>>> > >>>> >>> >>> >> >
