"Caveats of Recomposition" instance replacement not correct?

Nov 2, 2011 at 2:39 PM

In "Caveats of Recomposition" documentation section, the following is stated:

When recomposition occurs, we will replace the instance of the collection / array with a new instance, we will not update the existing instance. In the example above, if a new IMessageSender appears, Senders will be completely replaced with a new array. This is in order to facilitate thread-safety.

I'm not seeing this behavior. I expected the object (IPlugIn) instances within the older collection to be moved into a new collection, but i'm seeing the existing collection not being replaced. To test this I just derived from List<T> and created a Guid on construction, and it remains the same after recomposition.

	public class Temp
	{
		[ImportMany(typeof(IPlugIn), AllowRecomposition = true)]
		public MyList<IPlugIn> AvailablePlugIns { get; set; }
	}

	public class MyList<T> : List<T>
	{
		public string ID = Guid.NewGuid().ToString();
	}

After initial composition, I later add an assembly catalog to the aggregate catalog, and the AvailablePlugIns collection is updated correctly (new IPlugIn implementation exist), though the AvailablePlugIns instance is exactly the same (same ID). 

Is the documentation incorrect, or am I missing something?

Nov 2, 2011 at 11:53 PM

Hi,

Thanks for pointing this out. I believe it is a documentation problem rather than unexpected behavior.

Because much of the wiki on the CodePlex site was produced during v1 development, some of it is inconsistent with the released version. We’re aware of this and trying to focus our documentation efforts on MSDN in the future.

Thanks again,

Nick

From: odanrot [email removed]
Sent: Wednesday, November 02, 2011 7:40 AM
To: Nicholas Blumhardt
Subject: "Caveats of Recomposition" instance replacement not correct? [MEF:278056]

From: odanrot

In "Caveats of Recomposition" documentation section, the following is stated:

When recomposition occurs, we will replace the instance of the collection / array with a new instance, we will not update the existing instance. In the example above, if a new IMessageSender appears, Senders will be completely replaced with a new array. This is in order to facilitate thread-safety.

I'm not seeing this behavior. I expected the object (IPlugIn) instances within the older collection to be moved into a new collection, but i'm seeing the existing collection not being replaced. To test this I just derived from List<T> and created a Guid on construction, and it remains the same after recomposition.

        public class Temp
        {
               [ImportMany(typeof(IPlugIn), AllowRecomposition = true)]
               public MyList<IPlugIn> AvailablePlugIns { get; set; }
        }
 
        public class MyList<T> : List<T>
        {
               public string ID = Guid.NewGuid().ToString();
        }

After initial composition, I later add an assembly catalog to the aggregate catalog, and the AvailablePlugIns collection is updated correctly (new IPlugIn implementation exist), though the AvailablePlugIns instance is exactly the same (same ID).

Is the documentation incorrect, or am I missing something?