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.
>>> >
>>>
>>
>>
>
