Importing the same type twice in constructor #348
Comments
|
From [email protected] on January 22, 2012 21:19:48 Thank you for the report and repro, I'll try to take a look at this ASAP. Status: Accepted |
|
From travis.illig on September 21, 2012 09:33:45 Labels: Module-Integration-Mef |
|
From travis.illig on July 15, 2013 09:54:38 Verified this is still an issue in the 3.0 code. Doing the same thing in just Autofac works; it's definitely something in the MEF integration code. Status: Started |
|
From travis.illig on July 15, 2013 10:52:41 The stack trace for the resolution exception: The inner exception stack trace actually points to where the MEF failure is occurring: at System.ComponentModel.Composition.ReflectionModel.ReflectionComposablePart.EnsureGettable() |
|
From travis.illig on July 17, 2013 08:53:44 OK, I think I figured this out, but I'll need another set of eyes on it once I push the fix to make sure I didn't fix it in a way that will cause more issues. The problem lies in the way exports and imports need to be set on things getting resolved [indirectly] through MEF. A type registration gets converted to a 'ComposablePart' in a catalog. When you want an object based on a ComposablePart, you resolve the ComposablePart and then get its value. Dependencies are in the form of 'Exports' that get 'Imported' by the ComposablePart. Autofac basically has a lot of lambdas registered to automatically do Autofac resolution and populate the set of required import items on a ComposablePart so when you ask the part for its value, MEF wires things up and it all works. The problem up being that if you ask for the same ComposablePart twice, the FIRST time you ask for it all the exports get wired up properly and it works; the SECOND time, it somehow skips the wireup of the exports and everything fails. That was happening through an OnActivating event, but OnActivating didn't seem to want to fire for the particular unique ComposablePart more than once per resolution. Which makes sense, as technically a single instance (during the resolution process) is only getting activated the one time. Unfortunately, we're actually returning different ComposablePart instances each time - they just happen to boil down to the same internal dependency instance. SOOOOO I fixed it by setting the required imports as part of the actual activation lambda when exports get queried. That way it'll always happen. What I'm afraid of is the possibility that during an individual resolution operation something may inadvertently get double-activated or something like that. All the unit tests pass, things seem to just work, but... it'd just be nice to see if someone else can look at it and make sure I didn't do something dumb. I'll push the fix shortly. |
|
From travis.illig on July 17, 2013 08:57:26 This issue was closed by revision b1084276c9e8 . Status: Fixed |
|
From travis.illig on July 17, 2013 08:57:52 OK, pushed. Includes an update to the version info for Autofac.Integration.Mef so it can be released as needed. |
From [email protected] on November 11, 2011 04:54:01
What steps will reproduce the problem? 1.Register a class (A) that inject a MEF exported class (B) twice in constructor.
2.Make sure that the MEF exported class (B) import at least one other class (C) in constructor. It can be Autofac or MEF exported. Doesn't seem to matter.
3.Try resolve class A.
What is the expected output?
The type should be resolved successfully.
What do you see instead?
I get an exception along the lines of:
{"GetExportedValue cannot be called before prerequisite import 'AutofacMef.MefClass..ctor (Parameter="dependency", ContractName="AutofacMef.StandardDependency")' has been set."} What version of Autofac are you using? On what version of .NET/Silverlight? Autofac(.Mef) 2.5.2.830
.NET 4 Please provide any additional information below. I've attached a solution which shows the error.
Attachment: AutofacMef.zip
Original issue: http://code.google.com/p/autofac/issues/detail?id=348
The text was updated successfully, but these errors were encountered: