Strange recomposition behavior.

Mar 12, 2012 at 5:23 AM
Edited Mar 12, 2012 at 5:24 AM


I noticed that during recomposition through the adding of a new catalog or a directory catalog refresh, the parts of an object recomposes multiple times even though it is already composed and it belongs to the parts belong to the same assembly. Is there a reason why it is doing that?

I have a sample below


Mar 13, 2012 at 4:23 PM

Hi, thanks for getting in touch.

I don't believe MEF makes any guarantees about how parts are recomposed. I suspect MEF setting a property multiple times is an implementation detail not previously paid any attention. You should be able to use IPartImportsSatisfiedNotification in order to determine when recomposition is complete.


Mar 14, 2012 at 5:56 AM
Edited Mar 14, 2012 at 5:57 AM

Hello again,

It would seem very weird that IPartImportsSatisfiedNotification gets called multiple times as well.

In fact, it gets called as many times as the number of recomposed parts there are in the object getting recomposed.

Just to explain this behavior clearly:

  1. I have an object with 10 recomposable parts.
  2. My main catalog tied to the container is an aggregate catalog.
  3. I add a new catalog into the main catalog containing 4 new parts.
  4. the object sets the 4 new parts 4 times, at the end of each cycle, it fires IPartImportsSatisfiedNotification. Which means IPartImportsSatisfiedNotification gets fired 4 times too.
  5. If any of the recomposable part has a creation policy of non shared, it will re-create a new instance of the part during each cycle.

From this, there are a few things that brings up my concern:

  1. It would seem really inefficient that it is recomposing so many times, even though each time it does the exact same thing.
  2. It would be even more inefficient if a non shared part is used. It would cause the part to be created then "disposed" instantly. Wouldn't this be bad if I was not using lazy imports and the constructor of the part takes a long time to execute?