text: If.
  Summary of the breaking changes:
  - AllowNonPublicCompositionAttribute was removed. It is no longer needed MEF will always look at publics and non-publics.
  - ComposablePartCatalog was.
  - Mutability APIs on the container have been changed to accept a batch. AddPart and RemovePart methods were removed from the container, and you know must pass a CompositionBatch. The advantage of the batch is that you can now replace a single part in the container with a new part in a single operation. You can also add or remove multiple parts in a single operation. This comes in very handy when you have parts that are recomposing.
  New features::
  - Multiple composition errors are structured in numbered groups each relating to a single root cause
  - The ‘causal chain’ (Resulting in: …) traces an issue all the way back to the root action that the application was trying to perform
  - The ‘origin path’ (Element: …) describes how each object involved in the scenario came to be in the composition in the first place
  - All of this information can be retrieved programmatically from the exception types if necessary.
  - If a transient part implemented IDisposable, it’s resources would be released only when the container was disposed. Singletons would also be disposed in a similar manner. This forces transient parts which could container scarce resources to stay alive. For example if a part contains an unmanaged resource such as a database connection, it will stay open and not get recycled. This is particularly problematic in server environments such as ASP.NET, where you have a limited number of resources shared by many active sessions. Not having the connections recycled could lead to starvation.
  - Another challenge of the previous approach was that the Part had to determine its lifetime policy. As parts are reusable across different apps, it is very likely that a part in one app is a singleton, while in another it needs to be transient. In the same app there are even cases where the same part needs to be transient in one case and singleton in another. In our previous bits, there was no way to address this.
  Hammett and team (Wes, Daniel) have been working tirelessly to come up with a solution to this one. Hammett personally was no stranger to this problem from.
  - We’ve renamed Singleton and Factory creation policy to Shared / NonShared.
  - Parts and Imports can now both declare creation policy. We’ve also added a new policy called Any, which allows a Part or an Import declare that it can work with either policy, i.e. a Part could have a policy of Any, where one importer of the part’s exports has a policy of NonShared, while another importer has a policy of Shared. The grid below indicates the behavior in different scenarios.
  An importer specifies the required policy through the use of the new RequiredCreationPolicy as can be seen below.
  [Export]
  public class Window : System.Windows.Forms.Form
  {
  [Import(RequiredCreationPolicy = CreationPolicy.NonShared)]
  public ExportCollection<IShape> Shapes { get; set; }
  …
  }
  - Parts can now be explicitly released from the container by using the Container.ReleaseExport method. This method takes the export and traverses all its references that are non-shared and disposes of them if they implement IDisposable. This prevents what we call viral disposability where every part in the chain must implement IDisposable in order for the deepest child to be disposed. This is an extremely difficult problem for you to manage, and without this feature the likelihood of memory leaks is high.);
  }
  - A Non-shared part that has a recomposable import will be held conditionally based on the lifetime of its exports. If the exports are gc’d the part will be released as well.!