If MEF contract type has generics, MEF integration fails

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a composable part catalog with an export like:

[Export]
class FooRepo : IRepo<IFoo>

2. Create a builder that registers the MEF catalog using the MEF integration.
3. Call Build() on it.

What is the expected output? What do you see instead?
Expected output is that objects in Autofac that import IRepo<IFoo> can do so. 

At a minimum, that such an export is ignored (just like open generics are in 
MEF) as unsupported (maybe a warning logged somewhere).

I added the second "solution" in my clone: 
http://code.google.com/r/kzunet-mef/source/browse

Original issue reported on code.google.com by kzu.net on 8 May 2011 at 3:17

[GoogleCodeExporter]

Run the attached test using MSTest from within VS (it's a VS integration test, 
requires the VSSDK to be installed too).

It fails :(

Original comment by kzu.net on 8 May 2011 at 8:17

Attachments:

• VsMefAutofac.7z

[GoogleCodeExporter]

Daniel, I didn't realise you were still tinkering with Autofac :) I moved you 
to the 'contributors' list some time ago, but if it is okay with you I'd be 
happier for you to just jump in and make these changes - my turnaround time on 
the issue tracker is currently pretty slow so it might work out better that 
way. I've tentatively moved you back to the 'committers' list anyway, let me 
know your thoughts.

Original comment by nicholas...@gmail.com on 9 May 2011 at 8:46

[GoogleCodeExporter]

I saw that coming ;).

I'll give it a try. VS MEF integration makes for a very  compelling real world 
use case :)

Original comment by dan...@cazzulino.com on 10 May 2011 at 1:55

[GoogleCodeExporter]

Original comment by travis.illig on 21 Sep 2012 at 4:32

• Added labels: Module-Integration-Mef

[GoogleCodeExporter]

Issue 384 has been merged into this issue.

Original comment by travis.illig on 2 Jan 2013 at 10:15

[GoogleCodeExporter]

The root cause of this is that MEF is string-based, not type-based, so when 
"contracts" are compared, they're compared on a string-to-string basis.

That is, if I have an export like this...

[Export]
public class Foo : IRepo<Foo> { }

...then the contract that MEF uses is a generated string based on the type, 
like...

IRepo(Foo)

Notice the angle brackets were translated to parentheses. This also affects 
nested types and other odd/special cases.

The challenge is that there's no great way to "reverse" the contracts back into 
types. Everything gets normalized into this contract lookup mechanism at 
runtime and when parts are composed, types are translated into these contract 
names, compatibility is checked, and a dictionary of 
contract-to-composition-part is used to "activate" whatever part is required.

From an Autofac integration perspective, we need to get the actual types 
backing the contract so we can register services accordingly. The mapping 
dictionary is an internal construct, so this means... reflection. :(

Original comment by travis.illig on 2 Jan 2013 at 10:41

• Changed state: Started

[GoogleCodeExporter]

This issue was closed by revision 5fc468b5d0cd.

Original comment by travis.illig on 3 Jan 2013 at 4:22

• Changed state: Fixed