Lambda Expressions sind die Grundlage von Expression Trees. Ein sicherer Umgang mit Lambda Expressions ist Grundvoraussetzung für das Verständnis von Epression Trees. Deshalb folgt im 1. Teil eine kurze, aber (hoffentlich) vollständige Erläuterung zu Lambda Expressions. Dieser Post ist quasi auch die Essenz aller Beiträge, die ich zu diesem Thema bisher gelesen habe.

Grundsätzlich unterscheidet man zwei Arten von Lambda Expressions. Die Statement Lambdas (Anweisungs Lambdas) und die Expression Lambdas (Ausdrucks Lambdas).

Statement Lambdas (Anweisungs Lambdas)

Statement Lambdas kommen immer dort zum Einsatz, wo auch Delegates verwendet werden. Sie sind vergleichbar mit anonymen Methoden, besitzen aber eine kürzere Schreibweise. Hier ein einfaches Beispiel, bei der folgender Delegate vorausgesetzt wird:

public delegate void PrintString(int x, string y);

Die Umsetzung als anonyme Methode sieht wie folgt aus:

PrintString myDelegate = delegate(int x, string y)
        {
            string s = "Message(" + x + "): " + y;
            Console.WriteLine(s);
        };
myDelegate(100, "Exception");

Das gleiche Beispiel als Statement Lambda:

PrintString myDelegate = (int x, string y) =>
        {
            string s = "Message(" + x + "): " + y;
            Console.WriteLine(s);
        };
myDelegate(100, "Exception");

Das Schlüsselwort delegate entfällt. Stattdessen wird hinter den Eingangsparametern der Operator => angegeben (gesprochen: ‘geht nach’ bzw. ‘goes to’). Danach folgt der Anweisungsblock, in der die eigentliche Logik implementiert wird.

Der Operator => ist rechtsassoziativ und hat die gleiche Rangfolge wie die Zuweisung (=). Dank Type Inference (Typrückschluss) können die Typangaben bei den Eingangsparametern entfallen:

PrintString myDelegate = (x, y) =>
        {
            string s = "Message(" + x + "): " + y;
            Console.WriteLine(s);
        };
myDelegate(100, "Exception"); 

Wird nur ein Parameter übergeben, so kann auf die runde Klammer um die Eingangsparameter verzichtet werden:

public delegate void PrintString(int x);
PrintString myDelegate = x =>
        {
            string s = "Message(" + x + ")";
            Console.WriteLine(s);
        }; 

Bei einer leeren Parameterliste werden jedoch die runden Klammern wieder angegeben:

public delegate void PrintString();
PrintString myDelegate = () =>
        {
            string s = "Message";
            Console.WriteLine(s);
        }; 

Die Schreibweise der Statement Lambdas ist etwas kompakter als die der anonymen Methoden.

Expression Lambdas (Ausdrucks Lambdas)

Ein Expression Lambda ist eine besondere Form der Statement Lambdas. Ein Expression Lambda enthält nur eine Anweisung und liefert immer einen Wert zurück.

public delegate bool IsStringTooLong(int x, string y);

IsStringTooLong myDelegate = (x, y) => { return y.Length > x; };
bool ret = myDelegate(10, "Message"); 

Die gleiche Funktionalität kann durch ein Expression Lambda deutlich einfacher dargestellt werden:

IsStringTooLong myDelegate = (x, y) => y.Length > x;
bool ret = myDelegate(10, "Message"); 

Es besteht auch die Möglichkeit statt der Anweisung einen Methodenaufruf anzugeben:

IsStringTooLong myDelegate = (x, y) => SomeFunction(x, y);
bool ret = myDelegate(10, "Message");

static public bool SomeFunction(int x, string y)
{
    return y.Length > x;
} 

Expression Lambdas können auch dann angegeben werden, wenn bei einer Methode als Parametertyp Expression<Func> erwartet wird. Ein gutes Beispiel ist das Interface IQueryable.

List < string > list = new List < string >() { "Johann", "Otto", "Karl" };
IQueryable query = list.AsQueryable();
string a = list.First(x => { return x.EndsWith("o"); });
string b = query.First(x => { return x.EndsWith("o"); });  // Fehler!!! 

Die Methode First() der Klasse List<string> erwartet als Parameter ein Delegate vom Typ Func<string, bool>. Das Interface IQueryable hingegen, erwartet bei der Methode First() den Datentyp Expression<Func<string, bool>>. Aus diesem Grund kann das obige Beispiel nicht compiliert werden.

Wird als Parameter ein Expression Lambda angegeben (also ohne Klammern und ohne return), so lässt sich das Programm übersetzen.

string c = query.First(x => x.EndsWith("s") );

Lambda Expressions lassen sich in zwei Arten aufteilen. Zum einen die Lamda Statements, die Delegates und anonyme Methoden erzeugen und zum anderen die Expression Lambdas, die Instanzen von Expression<> zurückliefern. Expression Lambdas und die Klasse System.Linq.Expressions.Expression finden Anwendung bei den Expression Trees. Dazu später mehr.

Prädikat

Liefert ein Lambda Expression einen boolschen Wert zurück, so spricht man auch von einem Prädikat. Die Variable temperatur ist bei dem folgenden Beispiel vom Typ Integer.

(temperatur) => temperatur > 21;

Projektion

Unterscheidet sich der Datentyp des Rückgabewerts von dem Datentyp des Parameters, so wird dieses als Projektion bezeichnet. Bei dem folgenden Beispiel ist ex vom Datentyp Exception.

(ex) => ex.Message;

Delegates Action<>(), Func<>() und Predicate<>()

In den bisherigen Beispielen wurde immer ein eigener Delegate definiert. Das .NET Framework definiert einige hilfreiche Delegates. Hier die drei wichtigsten Varianten, die ich immer wieder gerne einsetze:

delegate void Action();
delegate void Action < T1 >(T1 parameter1);
delegate void Action < T1, T2 >(T1 parameter1, T2 parameter2);
delegate void Action < T1, T2, T3 >(T1 parameter1, T2 parameter2, T3 parameter3);
... 

delegate TResult Func < TResult >();
delegate TResult Func < T1, TResult >(T1 parameter1);
delegate TResult Func < T1, T2, TResult >(T1 parameter1, T2 parameter2);
delegate TResult Func < T1, T2, T3, TResult >(T1 parameter1, T2 parameter2, T3 parameter3);
... 

delegate bool Predicate < T1 >(T1 parameter1);

Der entscheidende Unterschied bei diesen drei Varianten ist der Rückgabewert. Action<>() gibt immer void zurück, Predicate<>() immer bool und der Rückgabewert bei Func<>() kann frei angegeben werden. Für die Delegates Action<>() und Func<>() gibt es jeweils Überladungen für bis zu 16 Parametern.

Beispiel für eigene Implementierung

Das folgende Beispiel fügt der Klasse List die Erweiterungsmethode MyWhere<T> hinzu. Die neue Methode soll sich in etwa so verhalten, wie die sicher schon bekannte Methode Where<T>.

class Program
{
    static void Main(string[] args)
    {
        new Program().Run();
    }
    void Run()
    {
        List < int > list = new List < int >() { 3, 1, 9, 4, 8, 1, 0, 6, 9 };
        IEnumerable < int > myFilteredList = list.MyWhere < int >(x => x < 5);
        foreach (var x in myFilteredList)
            Console.WriteLine(x);
    }
}

public static class ExMethods
{
    public static List < T > MyWhere < T >(this List < T > source, Predicate< T > predicate)
    {
        List < T > list = new List < T >();
        foreach (T item in source)
            if (predicate(item))
                list.Add(item);
        return list;
    }
} 

In der Erweiterungsmethode wird für jedes Element der Delegate predicate aufgerufen. Über diesen Delegate wird der Teil der Lambda Expression ausgeführt, die sich rechts vom Lambda Operator befinden. In diesem Beispiel: x < 5. Ist die Bedingung erfüllt, so liefert der Delegate True zurück. Dadurch wird in der Erweiterungsmethode das entsprechende Element in eine neue Liste eingefügt, die am Ende der Methode zurückgegeben wird.

Insbesondere LINQ macht von Erweiterungsmethoden und Lambda Expressions reichlich Gebrauch. Die Lesbarkeit der einzelnen Abfragen wird dadurch deutlich erhöht.

Type Inference (Typrückschluss)

Bei der Angabe einer Lambda Expression können oftmals die Typangaben bei den Eingangsparametern und bei den Rückgabeparametern (falls vorhanden) entfallen. Der Compiler ermittelt an Hand der Signatur des Delegate die notwendigen Informationen. Dabei sind einige Punkte zu beachten:

Alle Typangaben bei den Eingangsparametern müssen entweder komplett implizit oder explizit angegeben werden:

PrintString myDelegate = (int x, string y) => { ... };  // ok
PrintString myDelegate = (x, y) => { ... };             // ok
PrintString myDelegate = (x, string y) => { ... };      // Fehler

- Wird bei den Eingangsparametern kein Datentyp angegeben, so muss dieser implizit in den entsprechenden Datentyp konvertierbar sein.

- Der Rückgabewert (falls vorhanden) muss ebenfalls implizit in den Rückgabewert des Delegates konvertierbar sein.

- Anzahl und Reihenfolge der Eingangsparameter muss mit der Deklaration des Delegates übereinstimmen. Ausnahmen sind optionale und benannte Parameter.

Optionale und benannte Parameter

- Bei dem Aufruf des Delegate können die Eingangsparameter per Name angegeben werden. Dadurch ist die Reihenfolge frei wählbar:

myDelegate(x: 400, y: "Exception");
myDelegate(y: "Exception", x: 500); 

- Optionale Parameter sind ebenfalls nutzbar. Die Angabe des Standardwerts erfolgt bei der Deklaration des Delegate:

public delegate void PrintString(int x = 0, string y = "default");
PrintString myDelegate = (x, y) => { ... }; 
myDelegate();
myDelegate(200, "Exception");
myDelegate(300);

Weitere Infos zu optionalen und benannten Parametern sind im folgenden Post von mir zu finden: Benannte und optionale Parameter

Closures

Eine gern benutzte Beschreibung von Closure ist:

“Eine Closure verwendet beim Aufruf einen Teil ihres Gültigkeitsbereichs, auch wenn dieser Gültigkeitsbereich außerhalb der Funktion schon nicht mehr existiert.”

Alles klar? Ich glaube ein einfaches Beispiel ist hilfreicher:

static void Main(string[] args)
{
    var calculate = GetCalculation();
    var result = calculate(13);
}
public static Func < int, int > GetCalculation()
{
    var value = 99;
    return x =>
            {
                value++;
                return x * value;
            };
} 

Über die Methode GetCalculation() wird ein Delegate in Form eines Lambda Statements zurückgegeben. Die Variable value wird als lokale Variable von GetCalculation() mit in den Delegate gegeben. Anschließend wird die Methode verlassen. Man sollte jetzt annehmen, dass die Variable value nicht mehr gültig ist und ihren Wert verliert.

Beim Aufruf der anonymen Methode wird zuerst der Inhalt von value um eins erhöht und dann mit x, in diesem Fall13, multipliziert. Als Ergebnis wird 1300 zurückgegeben. Wie kann das sein?

Beim Verlassen der Methode GetCalculation() wird der Speicherplatz von value nicht wie üblich abgeräumt, weil ja in der anonymen Methode auf ihn verwiesen wird. Der Kontext, in dem value erzeugt wurde, existiert nicht mehr, trotzdem ist die Variable nach wie vor erhalten und steht auch ohne ihren Kontext zur Verfügung. Die Variable value ist an die anonyme Methode gebunden.

Im 2. Teil geht es dann um die Grundlagen von Expression Trees.

Das Managed Extensibility Framework (MEF) nutzt ein attributbasiertes Programmiermodell, um die einzelnen Exports an die Imports zu binden. Manchmal kann es aber von Vorteil sein, wenn über eine Konfigurationsdatei die Auswahl der Parts vorgegeben wird. Hierzu bietet sich die App.config an. In einem älteren Post wurde das Erstellen von benutzerdefinierten Konfigurationsabschnitten in der App.config schon vorgestellt. Der Focus soll mehr auf das Erstellen eines ExportProviders gelegt werden, der die Parts in eine eigene AppDomain lädt und dort mit eingeschränkten Rechten zur Ausführung bringt. Grundlagen zur Erstellung eigener ExportProvider findet ihr hier.

Die zu ladenen Parts sind in der App.config aufgelistet:

<configuration>
  <configSections>
    <section name="AddInSection" type="Sample01.AddInConfigurationSection, CarHost"/>
  </configSections>
  <AddInSection>
    <AddIns>
      <AddIn id="1" contract="CarContract.ICarContract"
                    assemblyName="BMW"
                    typeName="Sample01.BMW"/>
      <AddIn id="2" contract="CarContract.ICarContract"
                    assemblyName="Mercedes"
                    typeName="Sample01.Mercedes"/>
    </AddIns>
  </AddInSection>
</configuration>

Beide Parts sind identisch aufgebaut und befinden sich jeweils in separaten Assemblies. Wie auch zu erkennen ist, besitzen die Klassen BMW und Mercedes nicht das Attribut Export. Schließlich soll die App.config vorgeben, welche Assemblies zu laden sind, nicht das attributbasierte Programmiermodell von MEF. Da die Assemblies in einer eigenen AppDomain ausgeführt werden sollen und an die Methode Parameter übergeben werden, müssen die Klassen von MarshallByRefObject abgeleitet werden.

namespace Sample01
{
    public class BMW : MarshalByRefObject, ICarContract
    {
        public void WriteString(string name)
        {
            try
            {
                Console.WriteLine("BMW: WriteString()");
                File.WriteAllText(@"C:\Test.txt", name);
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.Message);
            }
        }
    }
}

namespace Sample01
{
    public class Mercedes : MarshalByRefObject, ICarContract
    {
        public void WriteString(string name)
        {
            try
            {
                Console.WriteLine("Mercedes: WriteString()");
                File.WriteAllText(@"C:\Test.txt", name);
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.Message);
            }
        }
    }
}

Die Methode WriteString() soll schreibend auf eine Datei zugreifen. Im Falle einer Exception wird die Fehlermeldung auf die Konsole ausgegeben.

Die Schnittstelle ICarContract liegt ebenfalls in einer separaten Assembly und beinhaltet die gemeinsam genutzte Methode.

namespace CarContract
{
    public interface ICarContract
    {
        void WriteString(string name);
    }
}

Die Hauptanwendung ist eher unspektakulär. Es wird eine Instanz des eigenen ExportProviders angelegt. Dieser wird an den Container übergeben. Die Methode ComposeParts() triggert das Laden und Binden der einzelnen Komponenten an. In der Foreach-Schleife wird zum Schluss von jedem Part die enthaltene Methode WriteString() aufgerufen.

namespace Sample01
{     
    public class Program
    {
        [ImportMany(typeof(ICarContract))]
        private IEnumerable< Lazy< ICarContract > > CarParts { get; set; }
      
        static void Main(string[] args)
        {
            new Program().Run();
        }

        void Run()
        {
            CompositionContainer container = null;

            var provider = new ConfigExportProvider();
            container = new CompositionContainer(provider);
            container.ComposeParts(this);

            foreach (Lazy< ICarContract > carPart in CarParts)
                carPart.Value.WriteString("Test");

            container.Dispose();
        }
    }
}

Spannend ist die Implementierung des ExportProviders. Im Konstruktor wird der Inhalt der App.config durchlaufen und für jeden Eintrag eine Instanz der Klasse Export angelegt.

Wichtig ist die Methode CreatePart() die im Konstruktor übergeben wird (Zeile 23). Diese erzeugt die einzelnen Parts. Ausgeführt wird CreatePart() sobald MEF die einzelnen Parts benötigt. Da die Imports über die Klasse Lazy<T> gespeichert werden, geschieht dieses bei dem ersten Zugriff auf das Objekt, also bei Aufruf der Methode WriteString().

Zuvor ruft MEF noch die Methode GetExportsCore() auf. Dort wird die Liste der Exports zurückgegeben, die zu dem Import passen.

namespace Sample01
{
    public class ConfigExportProvider : ExportProvider
    {
        private List< Export > Exports { get; set; }

        public ConfigExportProvider()
        {
            this.Exports = new List< Export >();
            
            AddInConfigurationSection myConfigurationSection =
              (AddInConfigurationSection)ConfigurationManager.GetSection("AddInSection");
            foreach (AddInSectionValue sectionValue in myConfigurationSection.SectionValues)
            {
                var metadata = new Dictionary< string, object >();
                metadata.Add(
                        CompositionConstants.ExportTypeIdentityMetadataName,
                        sectionValue.Contract);
                var exportDefinition = new ExportDefinition(sectionValue.Contract, metadata);
                string assemblyName = sectionValue.AssemblyName;
                string typeName = sectionValue.TypeName;
                var export = new Export(exportDefinition,
                                         () => CreatePart(assemblyName, typeName));
                this.Exports.Add(export);
            }           
        }

        public object CreatePart(string assemblyName, string typeName)
        {
            var info = new AppDomainSetup { 
                   ApplicationBase = AppDomain.CurrentDomain.SetupInformation.ApplicationBase };
            var grantSet = new PermissionSet(PermissionState.None);
            grantSet.AddPermission(new SecurityPermission(SecurityPermissionFlag.Execution));
            // soll der Dateizugriff erlaubt sein, so muss die folgende Zeile eingefügt werden
            // grantSet.AddPermission(new FileIOPermission(PermissionState.Unrestricted));
            var appDomain = AppDomain.CreateDomain("AddIn AppDomain",
                                                    AppDomain.CurrentDomain.Evidence,
                                                    info,
                                                    grantSet);
            var instance = appDomain.CreateInstanceAndUnwrap(assemblyName, typeName); 
            return instance;
        }

        protected override IEnumerable< Export > GetExportsCore(
                                        ImportDefinition definition,
                                        AtomicComposition atomicComposition)
        {          
            return this.Exports.Where(x => definition.IsConstraintSatisfiedBy(x.Definition));
        }
    }
}

In der Methode CreatePart() wird eine separate AppDomain mit stark eingeschränkten Rechten angelegt. In dieser wird die Assembly geladen. Die Rechte sind soweit eingeschränkt, dass Dateizugriffe nicht erlaubt sind.

Wird das Programm ausgeführt, so endet der Versuch, in eine Datei zu schreiben, in einer SecurityException.

Beispiel (Visual Studio 2010)

Metadaten werden mit Hilfe des Attributes ExportMetadata bekannt gegeben. Dazu wird jedes Element der Metadaten durch ein Name-Werte-Paar beschrieben. Der Name ist immer vom Typ String, während der Wert vom Typ Object ist. Wie der Zugriff auf Metadaten i.d.R. erfolgt, wird im Artikel MEF Teil 2 – Metadaten und Erstellungsrichtlinien beschrieben.

Im Folgenden Beispiel sind die Parts wie folgt implementiert:

[ExportMetadata("Name", "Mercedes")]
[ExportMetadata("Price", (uint)48000)]
[Export(typeof(ICarContract))]
public class Mercedes : ICarContract
{
    private static int counter;
    public Mercedes()
    {
        Console.WriteLine("constructor Mercedes: {0}", ++counter);
    }
    public string GetName()
    {
        return "Mercedes";
    }
}

Die Schnittstelle ICarContract dient ebenfalls zur Definition des Contracts:

public interface ICarContract
{
    string GetName();
}

Das Auslesen der Metadaten kann jetzt recht einfach über den Container erfolgen.

class Program
{
    [ImportMany(typeof(ICarContract))]
    private List< ICarContract > CarParts = new List< ICarContract >();

    static void Main(string[] args)
    {
        new Program().Run();
    }

    void Run()
    {
        var catalog = new AssemblyCatalog(System.Reflection.Assembly.GetExecutingAssembly()); 
        var container = new CompositionContainer(catalog); 
        container.ComposeParts(this);

        foreach (ComposablePartDefinition partDefinition in container.Catalog.Parts)
        {
            foreach (ExportDefinition exportDefinition in partDefinition.ExportDefinitions)
            {
                Console.WriteLine("Metadaten:");
                IDictionary< String, Object > metadata = exportDefinition.Metadata;
                Console.WriteLine("Name: {0}", metadata["Name"].ToString());
                Console.WriteLine("Price: {0}\n", metadata["Price"].ToString());
            }
        }
        container.Dispose();
    }
}

Wer sich über die Bedeutung der einzelnen Klassen noch nicht ganz im Klaren ist, wird vielleicht hier fündig: MEF Teil 8 – Eigenen ExportProvider erstellen.

Das obige Beispiel hat nur einen großen Haken. Mir ist es nicht gelungen, die Metadaten den einzelnen Objekten aus der Liste CarParts zuzuordnen. Was nützen die Metadaten, wenn diese dem Export nicht zugeordnet werden können?

Um dieses Problem zu lösen, musste ich das Programm so abändern, dass das Erzeugen der einzelnen Car-Objekte nicht von MEF ausgeführt wird, sondern ‘von Hand’.

class Program
{
    // [ImportMany(typeof(ICarContract))]
    private List< ICarContract > CarParts = new List< ICarContract >();

    static void Main(string[] args)
    {
        new Program().Run();
    }

    void Run()
    {
        var catalog = new AssemblyCatalog(System.Reflection.Assembly.GetExecutingAssembly()); 
        var container = new CompositionContainer(catalog); 
        // container.ComposeParts(this);

        foreach (ComposablePartDefinition partDefinition in container.Catalog.Parts)
        {
            ComposablePart part = partDefinition.CreatePart();               
            foreach (ExportDefinition exportDefinition in partDefinition.ExportDefinitions)
            {
                Console.WriteLine("Create new instance");
                ICarContract car = (ICarContract)part.GetExportedValue(exportDefinition);
                Console.WriteLine("Metadaten:");
                IDictionary< String, Object > metadata = exportDefinition.Metadata;
                Console.WriteLine("Name: {0}", metadata["Name"].ToString());
                Console.WriteLine("Price: {0}\n", metadata["Price"].ToString());
                CarParts.Add(car);
            }
        }

        Console.WriteLine("\nCarParts:");
        foreach (ICarContract carParts in CarParts)
            Console.WriteLine(carParts.GetName());

        container.Dispose();
    }
}

Da die Objekte selber erzeugt werden, kann auf das Attribut Import in Zeile 3 verzichtet werden. Ebenfalls nicht mehr notwendig ist der Aufruf der Methode ComposeParts() in Zeile 15. Der Aufruf würde so oder so nichts bewirken, da es im Programm keinen passenden Import mehr gibt. Ohne Import gibt es nichts zu composen.

Das Erzeugen der Car-Objekte erfolgt mit Hilfe der Methode GetExportValue() der Klasse ComposablePart. In Zeile 19 wird das notwendige Objekt erzeugt und in Zeile 23 das gewünschte Car-Objekt instanziiert. Die dann folgenden Metadaten gehören somit zwangsläufig zu dem zuvor erzeugten Objekt. Damit unsere Liste CarParts nicht leer bleibt, wird in Zeile 28 das Objekt der Liste hinzugefügt.

Auch wenn das manuelle Anlegen der Objekte einen der größten Vorteile von MEF untergräbt, so ergeben sich doch einige neue Möglichkeiten. Die Metadaten könnten z.B. direkt ausgewertet werden, um so die erzeugten Objekte unterschiedlichen Listen zuzuordnen.

if ((uint)metadata["Price"] > 50000)
    ExpensiveCarParts.Add(car);
else
    CarParts.Add(car);

Fazit:

So richtig kommt bei diesem Ansatz keine Freude auf. Die Nachteile überwiegen klar die Vorteile. Das Angenehme bei MEF ist eben das automatische Composen, also das Zuordnen der Exports zu den Imports. Auch ist der typsichere Zugriff auf die Metadaten nicht mehr möglich. Sollen die Exports an Hand der Metadaten gefiltert oder sortiert werden, so bietet  Lazy<T, TMetadata> deutlich mehr Komfort. Ein Beispiel mit LINQ ist in MEF Teil 2 – Metadaten und Erstellungsrichtlinien zu finden.

Beispiel (Visual Studio 2010)

Optionale und benannte Parameter werden sehr häufig zusammen erwähnt, sind aber zwei verschiedene Leistungsmerkmale. Optionale Parameter sind, wie der Name schon sagt, optional. Diese können bei einem Methodenaufruf weggelassen werden. Durch benannte Parameter ist die Reihenfolge der Parameter bei einem Methodenaufruf beliebig.

Beide Techniken lassen sich auf Methoden, Konstruktoren und Indexer anwenden.

Optionale Parameter

Um dem Nutzer einer Klasse den maximalen Komfort zu bieten, werden Methoden mit vielen Parametern sehr häufig überladen. Somit steht die gleiche Methode in unterschiedlichen Varianten zur Verfügung. Ein recht gutes Beispiel ist die statische Methode Show() der Klasse MessageBox:

public class MessageBox
{
    public static DialogResult Show(string text);
    public static DialogResult Show(string text, string caption);
    public static DialogResult Show(string text, string caption, MessageBoxButtons buttons);
    public static DialogResult Show(string text, string caption, MessageBoxButtons buttons, MessageBoxIcon icon);
    public static DialogResult Show(string text, string caption, MessageBoxButtons buttons, MessageBoxIcon icon, MessageBoxDefaultButton defaultButton);
    public static DialogResult Show(string text, string caption, MessageBoxButtons buttons, MessageBoxIcon icon, MessageBoxDefaultButton defaultButton, MessageBoxOptions options);
    public static DialogResult Show(string text, string caption, MessageBoxButtons buttons, MessageBoxIcon icon, MessageBoxDefaultButton defaultButton, MessageBoxOptions options, bool displayHelpButton);
    public static DialogResult Show(string text, string caption, MessageBoxButtons buttons, MessageBoxIcon icon, MessageBoxDefaultButton defaultButton, MessageBoxOptions options, string helpFilePath);
    public static DialogResult Show(string text, string caption, MessageBoxButtons buttons, MessageBoxIcon icon, MessageBoxDefaultButton defaultButton, MessageBoxOptions options, string helpFilePath, HelpNavigator navigator);
    public static DialogResult Show(string text, string caption, MessageBoxButtons buttons, MessageBoxIcon icon, MessageBoxDefaultButton defaultButton, MessageBoxOptions options, string helpFilePath, string keyword);
    public static DialogResult Show(string text, string caption, MessageBoxButtons buttons, MessageBoxIcon icon, MessageBoxDefaultButton defaultButton, MessageBoxOptions options, string helpFilePath, HelpNavigator navigator, object param);

    public static DialogResult Show(IWin32Window owner, string text);
    public static DialogResult Show(IWin32Window owner, string text, string caption);
    public static DialogResult Show(IWin32Window owner, string text, string caption, MessageBoxButtons buttons);
    public static DialogResult Show(IWin32Window owner, string text, string caption, MessageBoxButtons buttons, MessageBoxIcon icon);
    public static DialogResult Show(IWin32Window owner, string text, string caption, MessageBoxButtons buttons, MessageBoxIcon icon, MessageBoxDefaultButton defaultButton);
    public static DialogResult Show(IWin32Window owner, string text, string caption, MessageBoxButtons buttons, MessageBoxIcon icon, MessageBoxDefaultButton defaultButton, MessageBoxOptions options);
    public static DialogResult Show(IWin32Window owner, string text, string caption, MessageBoxButtons buttons, MessageBoxIcon icon, MessageBoxDefaultButton defaultButton, MessageBoxOptions options, string helpFilePath);
    public static DialogResult Show(IWin32Window owner, string text, string caption, MessageBoxButtons buttons, MessageBoxIcon icon, MessageBoxDefaultButton defaultButton, MessageBoxOptions options, string helpFilePath, HelpNavigator navigator);
    public static DialogResult Show(IWin32Window owner, string text, string caption, MessageBoxButtons buttons, MessageBoxIcon icon, MessageBoxDefaultButton defaultButton, MessageBoxOptions options, string helpFilePath, string keyword);
    public static DialogResult Show(IWin32Window owner, string text, string caption, MessageBoxButtons buttons, MessageBoxIcon icon, MessageBoxDefaultButton defaultButton, MessageBoxOptions options, string helpFilePath, HelpNavigator navigator, object param);
}

Seit C# 4.0 kann bei der Definition einer Methode angegeben werden, ob ein Parameter beim Aufruf erforderlich ist oder nicht. Hierzu wird hinter den gewünschten Parametern ein Standardwert angegeben. Der Standardwert muss immer eine Konstante sein. Wird bei dem Methodenaufruf kein Wert an den Parameter übergeben, so wird der Standardwert verwendet. Optionale Parameter müssen immer am Ende der Parameterliste, nach allen obligatorischen Parametern, stehen.

public void TestMethod(int x, int y = 123, int z = 456)
{
    Console.WriteLine("x: {0}  y: {1}  z: {2}", x, y, z);
}

Die Methode lässt sich auf verschiedene Arten aufrufen. Allerdings dürfen optionale Parametern bei dem Aufruf nicht ‘übersprungen’ werden.

TestMethod(1);
TestMethod(1, 2);
TestMethod(1, 2, 3);
TestMethod(1, , 3);  // Fehler

Es ist möglich, Methoden zu überladen, die optionale Parameter besitzen.

public void TestMethod(int x, int y = 123, int z = 456)
{
    Console.WriteLine("x: {0}  y: {1}  z: {2}", x, y, z);
}
public void TestMethod(int x)
{
    Console.WriteLine("x: {0}", x);
}

TestMethod(1);

Die Verwendung von TestMethod(1) hat zur Folge, dass die Methode TestMethod(int x) aufgerufen wird. Es wird also die Methode bevorzugt, die keine optionalen Parameter hat.

Da der Standardwert immer eine Konstante sein muss, gibt der Compiler bei folgendem Beispiel einen Fehler aus:

// nicht erlaubt
public void TestMethod(int x, int y = 123, Foo z = new Foo())
{
    Console.WriteLine("x: {0}  y: {1}  z: {2}", x, y, z);
}

Anders sieht das bei Enums und Strukturen aus. Da dieses Wertetypen sind, kann der new-Operator benutzt werden. allerdings nur in Verbindung mit dem Standardkonstruktor.

public void TestMethod(int x, int y = 123, StructFoo z = new StructFoo())
{
    Console.WriteLine("x: {0}  y: {1}  z: {2}", x, y, z);
}

Das Schlüsselwort default(T) kann ebenfalls benutzt werden:

public void TestMethod(int x, int y = 123, Foo z = default(Foo))
{
    Console.WriteLine("x: {0}  y: {1}  z: {2}", x, y, z);
}

Die Variable z erhält den Wert null, wenn beim Aufruf kein Wert angegeben wurde.

IntelliSense zeigt optionale Parameter in eckigen Klammern an:

Die Attribute Optional und DefaultParameterValue

Das Attribute Optional kann ebenfalls benutzt werden, um einen Parameter als optional zu kennzeichnen. Wird bei dem Aufruf der Methode dem Parameter kein Wert zugewiesen, so wird der Standardwert des jeweiligen Datentyps benutzt.

public void TestMethod(int x, [Optional]int y, [Optional]int z)
{
    Console.WriteLine("x: {0}  y: {1}  z: {2}", x, y, z);
}

Ergänzt werden kann das Attribut Optional durch das Attribut DefaultParameterValue.

public void TestMethod(int x, [Optional, DefaultParameterValue(123)]int y,
                              [Optional, DefaultParameterValue(456)]int z)
{
    Console.WriteLine("x: {0}  y: {1}  z: {2}", x, y, z);
}

Somit ist die Kombination aus beiden Attributen gleichzusetzen mit den obigen Beispielen. Es gelten auch die gleichen Randbedingungen.

Gefahrenquelle

Besondere Vorsicht ist geboten, wenn die Methode und der Aufrufer der Methode in unterschiedlichen Projekten abgelegt sind. Das folgende Beispiel enthält zwei Klassen in getrennten Assemblies.

class Program
{
    static void Main(string[] args)
    {
        new Program().Run();
    }
    public void Run()
    {
        ExternalClass externalClass = new ExternalClass();
        externalClass.TestMethod(1);
        externalClass.TestMethod(1, 2);
        externalClass.TestMethod(1, 2, 3);
    }
}

class ExternalClass
{
    public void TestMethod(int x, int y = 123, int z = 456)
    {
        Console.WriteLine("x: {0}  y: {1}  z: {2}", x, y, z);
    }
}

Was zu beachten ist, wird deutlich bei der Analyse des IL-Codes vom Aufrufer. Der Compiler kopiert die Werte in die Methodenaufrufe.

Das kann sehr unangenehm werden, wenn bei der Methode TestMethod() die Standardwerte geändert werden, der Aufrufer aber nicht neu compiliert wird. Die Methode wird weiterhin mit den alten Standardwerten aufgerufen.

Meiner Meinung nach sollten optionale Parameter (mit Standardwert) nur innerhalb einer Assembly angewendet werden. Gegen das Attribut Optional (ohne Standardwert) ist nichts einzuwenden, da das oben gezeigte Problem nicht auftreten kann.

Benannte Parameter

Benannte Parameter können bei jedem Methodenaufruf verwendet werden. Hierbei wird vor dem Wert auch der Name des Parameters angegeben. Dadurch können die Parameter in beliebiger Reihenfolge angegeben werden. Als Beispiel soll folgende Methode dienen:

public void TestMethod(int xPosition, int yPosition, int size)
{
    Console.WriteLine("x: {0}  y: {1}  z: {2}", xPosition, yPosition, size);
}

Folgende Aufrufe sind u.a. möglich:

TestMethod(1, 2, 3);
TestMethod(xPosition: 1, yPosition: 2, size: 3);
TestMethod(size: 3, yPosition: 2, xPosition: 1);

Der Compiler sorgt dafür, dass die Methode immer vollständig mit allen Parametern aufgerufen wird.

Benannte Parameter müssen immer am Ende des Methodenaufrufs stehen.

TestMethod(1, yPosition: 2, size: 3);
TestMethod(yPosition: 2, xPosition: 1, 3);  // Fehler
TestMethod(xPosition: 1, 3, size: 3);       // Fehler

Neben der Tatsache, dass die Reihenfolge geändert werden kann, erhöht sich auch die Lesbarkeit des Quellcodes. Allerdings nur dann, wenn die Parameter einer Methode auch aussagekräftige Namen haben.

TestMethod(1, 2, 3);

TestMethod(xPosition: 1, yPosition: 2, size: 3);  // lesbarer

Gefahrenquelle

Die Auswertung der Parameter geschieht in der gleichen Reihenfolge, in der sie auch genannt werden.

int position = 1;
TestMethod(yPosition: position++, xPosition: position, size: 3);

Der Aufruf liefert für xPosition den Wert 2 und für yPosition den Wert 1.

Der IL-Code zeigt sehr deutlich, wie die Parameter in der Reihenfolge, in der sie genannt werden, auch ausgewertet werden.

Liegen Methode und Aufrufer in unterschiedlichen Assemblies, so kann durchaus der Name eines Parameters geändert werden, ohne dass der Aufrufer neu compiliert werden muss. Das liegt ganz einfach daran, dass der Name der Variablen im IL-Code nicht mehr auftaucht. Probleme treten erst dann auf, wenn der Aufrufer neu compiliert wird.

Wie Lazy<T> und Lazy<T, TMetadata> in Zusammenhang mit MEF eingesetzt werden, habe ich schon ausreichend in MEF Teil 1 – Grundlagen, Imports und Exports und MEF Teil 2 – Metadaten und Erstellungsrichtlinien beschrieben. Wer wissen will, wie die Klasse Lazy<T> ohne MEF sinnvoll benutzt werden kann, dem sei der Blog von Hendrik Lösch empfohlen. Hilfreich ist auch der Artikel Lazy Initialization aus dem MSDN. Doch wie kann die Klasse Lazy<T, TMetadata> ohne MEF verwendet werden?

Während Lazy<T> direkt in mscorlib.dll enthalten ist, wurde Lazy<T, TMetadata> in System.ComponentModel.Composition.dll ‘versteckt’. Dementsprechend muss die Referenz auf die DLL dem Projekt hinzugefügt werden.

Im Klassendiagramm ist zu erkennen, dass die Klasse Lazy<T, TMetadata> von Lazy<T> abgeleitet wurde. Neben der Eigenschaft Metadata gibt es noch zusätzliche Konstruktoren, mit denen die Metadaten initialisiert werden.

Beispiel

Als Beispiel soll ein Logger dienen, der den Text in verschiedenen Formaten ausgeben kann. Hierzu werden zwei Klassen angelegt, die beide die gleiche Schnittstelle implementieren. Beide Klassen geben über die Methode WriteMessage() einen Text in unterschiedlichen Formaten aus.

public interface ILoggerClass
{
    void WriteMessage(string message);
}

public class LongFormatLogger : ILoggerClass
{
    public LongFormatLogger()
    {
        Console.WriteLine("LongFormatLogger constructor");
    }
    public void WriteMessage(string message)
    {
        Console.WriteLine("Message (" +
                          DateTime.Now.ToLongDateString() +
                          "): " +
                          message);
    }
}

public class ShortFormatLogger : ILoggerClass
{
    public ShortFormatLogger()
    {
        Console.WriteLine("ShortFormatLogger constructor");
    }
    public void WriteMessage(string message)
    {
        Console.WriteLine("Message (" +
                          DateTime.Now.ToShortDateString() +
                          "): " +
                          message);
    }
}

So weit so gut. Jetzt benötigen wir noch die Klasse für die Metadaten.

public class LoggerMetadata
{
    public string Destination { get; private set; }
    public LoggerMetadata(string destination)
    {
        this.Destination = destination;
    }
}

Die Metadaten sollen dazu dienen, Filterkriterien zu definieren, die entscheiden, welche Instanzen zur Ausgabe herangezogen werden. Sicherlich könnte man diese Angaben auch direkt in den Logger legen. Dieses würde aber bedeuten, dass jeder Logger instanziiert werden muss, um auf diese Eigenschaften zugreifen zu können. Durch die Verwendung der Klasse Lazy<T, TMetadatea> ist der Zugriff auf die Metadaten möglich, ohne dass Instanzen der Logger existieren müssen.

private List< Lazy< ILoggerClass, LoggerMetadata > > LazyLoggerClasses { get; set; }

Da mehrere Varianten des Loggers zur Verfügung gestellt werden, sind diese in einer Eigenschaft vom Typ List<T> abgelegt. Die Loggerklasse und die Metadaten werden von Lazy<T, TMetadata> gekapselt.

private void CreateLogger()
{
    LazyLoggerClasses = new List< Lazy< ILoggerClass, LoggerMetadata > >();

    LazyLoggerClasses.Add(new Lazy< ILoggerClass,
                          LoggerMetadata >(() => { return new ShortFormatLogger(); },
                                           new LoggerMetadata("Trace")));

    LazyLoggerClasses.Add(new Lazy< ILoggerClass,
                          LoggerMetadata >(() => { return new ShortFormatLogger(); },
                                           new LoggerMetadata("Debug")));

    LazyLoggerClasses.Add(new Lazy< ILoggerClass,
                          LoggerMetadata >(() => { return new LongFormatLogger(); },
                                           new LoggerMetadata("Debugger")));
}

Im Konstruktor von Lazy<T, TMetadata> wird ein Delegate vom Typ Func<ILoggerClass> erwartet. Dieser Delegate gibt die gewünschte Instanz des Loggers zurück. Der zweite Parameter enthält das Objekt mit den Metadaten. Per Konstruktor wird der Klasse für die Metadaten ein String übergeben, der über die Eigenschaft Destination abgefragt werden kann.

Die Methode Write() nutzt diese Eigenschaft, um nur auf die gewünschten Logger zuzugreifen. Hierzu wird mit Hilfe eines Lambda-Ausdrucks und der Methode FindAll() eine Liste zurückgegeben, in der alle Elemente enthalten sind, die den Filterkriterien entsprechen. Die foreach-Schleife greift über die Eigenschaft Value der Klasse Lazy<T, TMetadaten> auf den Logger zu.

private void Write(string destination, string message)
{
    var outputs = LazyLoggerClasses.FindAll(a => a.Metadata.Destination.Contains(destination));
    foreach (var lazyDataClass in outputs)
        lazyDataClass.Value.WriteMessage(message);
}

Der Hauptteil des Beispiels ruft zuerst die Methode für das Erzeugen der Logger-Objekte auf. Anschließend werden (als Test) die Metadaten angezeigt und zum Schluss die Meldungen ausgegeben.

void Run()
{
    Console.WriteLine("-- Create some logger objects with metadata --");
    this.CreateLogger();

    Console.WriteLine("-- Read the metadata --");
    foreach (var lazyDataClass in LazyLoggerClasses)
        Console.WriteLine(lazyDataClass.Metadata.Destination);

    Console.WriteLine("-- Invoke the method of LoggerClass --");
    Write("Debug", "message for debug");
    Write("Trace", "message for trace");
    Write("Release", "message for release");
}

In der Ausgabe ist gut zu erkennen, dass erst dann der Konstruktor aufgerufen wird, wenn das erste Mal auf die Methode WriteMessage() zugegriffen wird. Der Zugriff auf die Metadaten erzeugt noch kein Objekt des Loggers.

Der Aufruf Write(”Debug”, “message for debug”) gibt zwei Meldungen aus, da als Filter der String Debug angegeben wurde und zwei Logger in den Metadaten (die Eigenschaft Destination) ebenfalls den String Debug bzw. Debugger enthalten.

Write(”Trace”, “message for trace”) gibt nur eine Meldung aus, da der String Trace nur auf einen Logger zutrifft.

Durch Write(”Release”, “message for release”) wird keine Meldung ausgegeben, da Release auf keinen der Logger zutrifft.

Beispiel 1 (Visual Studio 2010)

Auch wenn dieses ein eher ‘sinnfreies’ Beispiel ist, zeigt es doch, dass im Zusammenhang mit Lazy-Loading die Klasse Lazy<T, TMetadaten> sinnvoll eingesetzt werden kann.

Die Verwendung von MEF ist mehr als einfach. Klassen, Methoden oder Eigenschaften werden mit den Attributen Export und Import dekoriert. Container und Kataloge sorgen dafür, dass die Exports zu den passenden Imports finden. Manchmal ist es aber nötig, diesen Prozess selber zu kontrollieren. Eine davon ist die Verwendung der Klasse CompositionBatch.

Die Klasse CompositionBatch

Die Klasse kann man sich als Liste von ComposableParts vorstellen.

Mit den Methoden AddPart() und RemovePart() können Objekte vom Typ ComposablePart hinzugefügt oder gelöscht werden. Es gibt von der Methode AddPart() auch eine Variante, die als Parameter ein Object erwartet. Auf diese Weise lassen sich beliebige Objekte hinzufügen.

class Program
{
    [ImportMany]
    private ICarContract[] CarParts { get; set; }

    static void Main(string[] args)
    {
        new Program().Run();
    }

    void Run()
    {
        var container = new CompositionContainer();
        var batch = new CompositionBatch();
        ComposablePart partHost = batch.AddPart(this);
        ComposablePart partBMW = batch.AddPart(new BMW());
        ComposablePart partMercedes = batch.AddPart(new Mercedes());
        container.Compose(batch);

        foreach (ICarContract carPart in CarParts)
            Console.WriteLine(carPart.GetName());

        container.Dispose();
    }
}

public interface ICarContract
{
    string GetName();
}

[Export(typeof(ICarContract))]
public class Mercedes : ICarContract
{
    public string GetName()
    {
        return "Mercedes";
    }
}

public class BMW : ICarContract
{
    public string GetName()
    {
        return "BMW";
    }
}

Mit der Methode AddPart() wird je eine Instanz von BMW und Mercedes der Klasse CompositionBatch hinzugefügt. Außerdem muss eine Instanz der Klasse Program übergeben werden, da dort der Import definiert ist. Da die Klasse BMW nicht mit dem Attribut Export dekoriert wurde, kann es nicht mit der Eigenschaft CarParts verlinkt werden. Wird das Programm ausgeführt, so ist nur das Objekt der Klasse Mercedes in dem Array CarParts enthalten.

Beispiel 1 (Visual Studio 2010)

Mit der Klasse CompositionBatch hat man unter Kontrolle, welche ComposableParts genutzt werden und welche eben nicht. Allerdings müssen alle Objekte mit dem Attribute Export dekoriert werden. Noch flexibler ist der Einsatz eines eigenen Export-Providers. Das später folgende Beispiel zeigt, wie auch Klassen berücksichtigt werden können, die nicht mit dem Attribut Export dekoriert wurden. Doch zuvor müssen zum Verständnis einige Klassen genauer betrachtet werden.

Aufbau von MEF

Das Managed Extensibility Framework kann in drei Ebenen aufgeteilt werden. Zum einem gibt es die Klassen, mit der das attributbasierte Programmiermodell umgesetzt wird. Eine weitere Ebene definiert die Container. Die Primitives sind die wichtigsten internen Systemklassen.

Der Container-Layer hat keine Abhängigkeiten zum attributbasierten Programmiermodell, sondern nur zu den Primitives, die direkt vom Container benutzt werden. Dadurch kann das attributbasierte Programmiermodell ausgetauscht werden, ohne dass der Container neu implementiert werden muss.

Die Klasse ComposablePart

Zentraler Bestandteil von MEF ist die Klasse ComposablePart. Über Exports stellen ComposableParts ihre Funktionalitäten anderen Systemen zur Verfügung. Sollen Funktionalitäten anderer Systeme verwendet werden, so geschieht dieses über Imports. Über die Auflistungen ExportDefinitions und ImportDefinitions verwaltet die Klasse ihre Imports und Exports.

Die Klasse ComposablePartDefinition

Vereinfacht gesagt beschreibt die Klasse ComposablePartDefinition ein ComposablePart. ComposablePartDefinition stellt die ImportDefinition und ExportDefinition zur Verfügung. Diese sind notwendig, um mit der Methode CreatePart() ComposableParts zu erzeugen.

Somit kann die Klasse ComposablePartDefinition als Erzeugerklasse (Factory class) für ComposableParts gesehen werden. Die Eigenschaften ExportDefinitions, ImportDefinitions und Metadata werden beim Anlegen über die Methode CreatePart() an das ComposablePart übergeben.

Die Klasse ImportDefinition

Die Klasse findet Verwendung bei ComposablePart. Die Klasse ComposablePart enthält die Eigenschaft ImportDefinitions die eine Auflistung von ImportDefinition darstellt.

Vereinfacht ausgedrückt definiert die Klasse ImportDefinition einen ‘Filter’ der entscheidet, welche Exports welchem Import zugeordnet werden.

Für jedes Attribut Import wird eine Instanz von ImportDefinition angelegt.

Drei Eigenschaften sind bei dieser Klasse besonders wichtig.

Die Klasse ContractBasedImportDefinition

Die Klasse ContractBasedImportDefinition wird von ImportDefinition abgeleitet. Da bei der Eigenschaft Constraint kein Lambda-Ausdruck verwendet wird, ist die Handhabung in einigen Fällen einfacher.

Die Klasse ExportDefinition

Wie weiter oben zu sehen ist, wird die Klasse ExportDefinition bei der Eigenschaft Constraint der Klasse ImportDefinition benutzt. Während die Klasse ImportDefinition definiert, welcher Export bei einem Import benötigt wird, definiert die Klasse ExportDefinition den Export an sich.

Ebenfalls findet die Klasse Verwendung bei ComposablePart. Die Klasse ComposablePart enthält die Eigenschaft ExportDefinitions, die eine Auflistung von ExportDefinition darstellt.

Ähnlich der Klasse ImportDefinition wird für jedes Attribut Export eine Instanz von ExportDefinition angelegt.

Die Klasse ExportDefinition besteht im Wesentlichen aus den Eigenschaften ContractName und Metadata. ContractName beinhaltet den Namen des Schnittstellenvertrages. Der Vertragsname eines Exports muss mit dem eines Imports übereinstimmen. Die Eigenschaft Metadata beinhaltet ein Dictionary mit zusätzlichen Informationen, die andere Anwendungen auswerten können.

Die Klasse Export

Die Klasse Export repräsentiert einen Export. Wird das attributbasierte Programmiermodell verwendet, so ist dieses ein Objekt, das mit dem Attribut Export dekoriert wurde.

Klassenübersicht

Im Folgenden sind nochmals alle besprochenen Klassen gegenübergestellt.

Die Klasse ExportProvider

Ausgangspunkt für einen eigenen Export-Provider ist die abstrakte Klasse ExportProvider. Von dieser Klasse muss der eigene Export-Provider abgeleitet werden. MEF liefert schon einige Klasse mit, die von ExportProvider abgeleitet sind. Die bekannteste Klasse ist CompositionContainer.

Eine der wichtigsten Methoden ist GetExportsCore():

protected abstract IEnumerable< Export > GetExportsCore(ImportDefinition definition,
                                                        AtomicComposition atomicComposition)

Die Methode erwartet u.a. die Definition des Imports, abgebildet durch die Klasse ImportDefinition. In erster Linie ist damit der Vertragsname vom Import gemeint. Zurückgeliefert wird eine Auflistung der Exports, die den gewünschten Kriterien entsprechen.

Des weiteren gibt es in der Klasse ExportProvider eine große Anzahl von Methoden, die mit GetExport…() beginnen. Diese Methoden brauchen bei einem eigenen Export-Provider nicht implementiert werden. Sie dienen nur dazu, den Aufruf der Methode GetExportsCore() auf verschiedene Art und Weise zu kapseln.

Export-Provider an den Container übergeben

Ein oder mehrere Export-Provider werden über den Konstruktor an den Container übergeben. Es stehen zwei Varianten zur Verfügung:

public CompositionContainer(params ExportProvider[] providers)

public CompositionContainer(ComposablePartCatalog catalog,
                            params ExportProvider[] providers)

Ähnlich wie bei Katalogen, gibt es auch bei den Export-Providern eine Aggregate-Klasse, AggregateExportProvider. Diese enthält eine Liste von Objekten, die von ExportProvider abgeleitet sind. Jeder Export-Provider wird dieser Liste hinzugefügt. Kataloge werden über die Klasse CatalogExportProvider der Aggregate-Klasse hinzugefügt. Die Klasse CatalogExportProvider hat die Eigenschaft Catalog und kann Objekte vom Typ ComposeablePartCatalog (wie z. B. also AssemblyCatalog, DirectoryCatalog, TypeCatalog, ..) aufnehmen. Somit sieht der Container nur Export-Provider. Entweder eigene Export-Provider oder Kataloge, die mit Hilfe der Klasse CatalogExportProvider in einen Export-Provider verpackt wurden.

Beispiel

Das folgende Beispiel ähnelt sehr dem ersten Beispiel. Allerdings wird dem Container eine Instanz der Klasse AssemblyCatalog übergeben. Über diesen Katalog sollen die Klassen gefunden werden, die mit dem Attribut Export dekoriert wurden. Bei diesem Beispiel ist es die Klasse Mercedes. Das zweite Objekt, das an den Container übergeben wird, ist der Export-Provider MyExportProvider. Die Klasse ist von ExportProvider abgeleitet und erwartet im Konstruktor den Vertragsname und den Typ des Objektes, das der Container berücksichtigen soll (die Klasse BMW). Der Vertragsname muss natürlich der gleiche sein wie beim Import. Der Typ des Objektes wird hier als Fully Qualified Name angegeben.

public class Program
{
    [ImportMany]
    private ICarContract[] CarParts { get; set; }

    static void Main(string[] args)
    {
        new Program().Run();
    }

    void Run()
    {
        CompositionContainer container = null;

        try
        {
            var catalog = new AssemblyCatalog(Assembly.GetExecutingAssembly());
            var provider = new MyExportProvider(typeof(ICarContract).FullName,
                                                typeof(BMW).FullName);
            container = new CompositionContainer(catalog, provider);
            container.ComposeParts(this);

            foreach (ICarContract carPart in CarParts)
                Console.WriteLine(carPart.GetName());
        }
        catch (Exception ex)
        {
            Debug.WriteLine(ex.Message);
        }
        container.Dispose();
    }
}

public interface ICarContract
{
    string GetName();
}

[Export(typeof(ICarContract))]
public class Mercedes : ICarContract
{
    public string GetName()
    {
        return "Mercedes";
    }
}

public class BMW : ICarContract
{
    public string GetName()
    {
        return "BMW";
    }
}

Im Konstruktor der Klasse MyExportProvider wird ein Objekt der Klasse Export angelegt. Wichtig sind hierbei die Metadaten. Über die Metadaten wird der zugrunde liegende Datentyp übergeben (Sample02.ICarContract). Bei diesem Beispiel ist das gleichzeitig auch der Vertragsname. Im Debugger sieht das Objekt export wie folgt aus: 

Durch den Aufruf von ComposeParts() im Hauptprogramm, wird im Export-Provider die Methode GetExportsCore() aufgerufen. Hier wird entschieden, welche Exports zu dem Import passen. Erzeugt wird das Objekt in der Methode CreatePart(). Diese wird über den Delegate funcCreatePart für jedes Objekt vom Typ Export, das im Konstruktor erzeugt wurde, einmal aufgerufen. In diesem Beispiel wird einfach in der aktuellen Assembly nach dem gewünschten Typ gesucht und eine Instanz erzeugt.

public class MyExportProvider : ExportProvider
{
    private List< Export > Exports { get; set; }
    private string TypeName { get; set; }

    public MyExportProvider(string contractName, string typeName)
    {
        Func< object > funcCreatePart = new Func< object >(CreatePart);
        this.TypeName = typeName;

        this.Exports = new List< Export >();
        var metadata = new Dictionary< string, object >();
        metadata.Add(CompositionConstants.ExportTypeIdentityMetadataName,
                     contractName);

        var exportDefinition = new ExportDefinition(contractName, metadata);
        var export = new Export(exportDefinition, funcCreatePart);
        this.Exports.Add(export);
    }

    public object CreatePart()
    {
        Type partType = Assembly.GetExecutingAssembly().GetType(this.TypeName);
        object instance = Activator.CreateInstance(partType);
        return instance;
    }

    protected override IEnumerable< Export > GetExportsCore(ImportDefinition definition,
                                                            AtomicComposition atomicComposition)
    {
        return this.Exports.Where(x => definition.IsConstraintSatisfiedBy(x.Definition));
    }
}

Wie im ersten Beispiel wird auch hier die Klasse BMW nicht mit dem Attribut Export dekoriert. Trotzdem wird auch diese Klasse von MEF berücksichtigt. Möglich macht das der eigene Export-Provider, der unabhängig von den Attributen die gewünschte Instanz erzeugt.

Beispiel 2 (Visual Studio 2010)

Wer an weiteren Informationen zu MEF interessiert ist, dem sei die MEF CodePlex Seite sehr empfohlen. Insbesondere der Bereich Architecture Overview und der Artikel Hosting the .NET Composition Primitives. Hilfreich ist auch der Artikel von Klaus Aschenbrenner aus der Zeitschrift dotnetpro Ausgabe 07/2009.

(Angaben ohne Gewähr)

Schwerpunkte des Vortrags zum “Managed Extensibility Framework” sind:

• Grundlagen und Prinzip
• Metadaten
• Lifecycle
• Creation Policy
• Composition und Recomposition
• Vererbung
• Debuggen

Gerne nehme ich weitere Einladungen an. Über Xing könnt ihr Kontakt zu mir aufnehmen.

Ziel einer Class Factory ist es, Objekte zu erzeugen. Unterklassen entscheiden aber, welche Klasse genau instanziiert wird. Dazu liefert die Class Factory die passende Klasse in Abhängigkeiten von Informationen, die vom Client bereitgestellt werden oder erst zur Laufzeit ermittelt wurden.

Als Grundlage für die Beispiele soll ein Textlogger dienen, der über verschiedene Formatter den Ausgabetext unterschiedlich formatieren kann. In beiden Beispielen stellt die Klasse ConsoleLogger die Methode Log() bereit. Innerhalb der Klasse ConsoleLogger werden auf unterschiedliche Art und Weise Instanzen der Klasse FormatterBase (bzw. Ableitungen davon) erzeugt. Eine Ableitung (FormatterTimeStamp) ergänzt die Meldung mit der aktuellen Uhrzeit. Eine weitere Ableitung, die Klasse FormatterDateTimeStamp, gibt neben der Uhrzeit auch das aktuelle Datum aus.

Die Hauptanwendung, der Textlogger und der Formatter sollen über das Managed Extensibility Framework gebunden werden. Die eigentliche Implementierung des Formatters soll durch eine Class Factory flexibel erzeugt werden.

Beispiel 1

Der Host ist bei diesem Beispiel recht einfach aufgebaut. Eine Eigenschaft vom Typ ConsoleLogger importiert über das Managed Extensibility Framework die passende Instanz. Über die Methode Log() werden die Meldungen ausgegeben.

using System.ComponentModel.Composition;
using System.ComponentModel.Composition.Hosting;
using Logger;

namespace Host
{
    class Program
    {
        [Import]
        public ConsoleLogger Logger { get; set; }

        static void Main(string[] args)
        {
            new Program().Run();
        }

        void Run()
        {
            var catalog = new DirectoryCatalog(".");
            var container = new CompositionContainer(catalog);
            container.ComposeParts(this);
            Logger.Log("Message A");
            Logger.Log("Message B");
            Logger.Log("Message C");
        }
    }
}

Die Klasse ConsoleLogger enthält die Methode Log() und die Eigenschaft FormatterFunc. FormatterFunc ist ein Delegate vom Typ Func<FormatterBase>, liefert also immer ein Objekt vom Typ FormatterBase zurück.

using System;
using System.ComponentModel.Composition;
using Formatter;

namespace Logger
{
    [Export]
    public class ConsoleLogger
    {
        [Import]
        private Func< FormatterBase > FormatterFunc { get; set; }

        public void Log(string message)
        {
            string formattedString = FormatterFunc().Format(message);
            Console.WriteLine(formattedString);
        }
    }
}

Exportiert wird die Methode aus der eigentlichen Class Factory. Die Methode GetTextFormatter() wurde hier mit dem Attribute Export versehen. Da diese kompatibel zu der Eigenschaft FormatterFunc ist, werden beide durch das Managed Extensibility Framework miteinander gebunden.

public class FormatterFactory
{
    private static bool toogle;

    [Export]
    public FormatterBase GetTextFormatter()
    {
        // an dieser Stelle wird entschieden, welcher
        // Formatter zurückgeliefert werden soll.
        toogle = !toogle;
        if (toogle)
            return new FormatterTimeStamp();
        else
            return new FormatterDateTimeStamp();
    }
}}

Die Methode GetTextFormatter() erzeugt beim Aufruf das gewünschte Objekt. Zu Testzwecken liefert diese Methode einfach abwechselnd zwei verschiedene Objekte zurück. Die Entscheidung, welches Objekt erzeugt wird, würde bei einer realen Applikation z.B. durch einen Parameter oder durch eine Konfigurationsdatei erfolgen.

Zum Schluss noch die Implementierung der einzelnen Formatter.

public class FormatterBase
{
   public virtual string Format(string message)
   {
       return message;
   }
}

public class FormatterTimeStamp : FormatterBase
{
   public override string Format(string message)
   {
       return string.Format("{0} - {1}",
                            DateTime.Now.ToShortTimeString(),
                            message);
   }
}

public class FormatterDateTimeStamp : FormatterBase
{
    public override string Format(string message)
    {
       return string.Format("{0} {1} - {2}",
                            DateTime.Now.ToShortDateString(),
                            DateTime.Now.ToShortTimeString(),
                            message);
    }
}

Wird das Programm gestartet, so erhält man folgende Ausgabe:

Beispiel 1 (Visual Studio 2010)

Beispiel 2

Das zweite Beispiel ist dem ersten sehr ähnlich. Der entscheidende Unterschied ist der Aufruf der Methode Log(). Der Typ des Formatters wird in diesem Fall mit angegeben.

using Formatter;
using Logger;

namespace Host
{
    class Program
    {
        [Import]
        public ConsoleLogger Logger { get; set; }

        static void Main(string[] args)
        {
            new Program().Run();
        }

        void Run()
        {
            var catalog = new DirectoryCatalog(".");
            var container = new CompositionContainer(catalog);
            container.ComposeParts(this);
            Logger.Log("Message", typeof(FormatterTimeStamp));
            Logger.Log("Message", typeof(FormatterDateTimeStamp));
        }
    }
}

Die Klasse ConsoleLogger enthält wiederum die Methode Log() und die Eigenschaft FormatterFunc. FormatterFunc ist aber diesmal ein Delegate vom Typ Func<Type, FormatterBase>. FormatterFunc erwartet einen Parameter vom Typ Type und liefert ein Objekt vom Typ FormatterBase zurück.

Auch die Methode Log() enthält zusätzlich einen Parameter vom Typ Type. In der Methode Log() wird über den Delegate FormatterFunc der gewünschte Formatter angefordert. Welche Methode über den Delegate genau aufgerufen wird, hängt davon ab, welche Methode das Managed Extensibility Framework an den Delegate gebunden hat. In diesem Beispiel ist es die Methode GetTextFormatter() aus der Klasse FormatterFactory. 

using System;
using System.ComponentModel.Composition;
using Formatter;

namespace Logger
{
    [Export]
    public class ConsoleLogger
    {
        private FormatterBase formatterBase;

        [Import]        
        private Func< Type, FormatterBase > FormatterFunc { get; set; }

        public void Log(string message, Type formatterType)
        {
            FormatterBase formatterBase = FormatterFunc(formatterType);
            string formattedString = formatterBase.Format(message);
            Console.WriteLine(formattedString);
        }
    }
}

Die Klasse FormatterFactory exportiert die passende Methode, die zu dem Delegate FormatterFunc der Klasse ConsoleLogger kompatibel ist. Innerhalb GetTextFormatter() wird von dem gewünschten Typ ein Objekt erzeugt und an die Methode Log() zurückgegeben. Hat die Methode Log() ein Formatter-Objekt erhalten, wird von diesem die Methode Format() aufgerufen und der formatierte Text ausgegeben.

public class FormatterFactory
{
   [Export]
    public FormatterBase GetTextFormatter(Type controlType)
    {
        ConstructorInfo ci = controlType.GetConstructor(new Type[] { });
        FormatterBase formatterBase = (FormatterBase)ci.Invoke(new object[] { });
        return formatterBase;
    }
}

Die Ausgabe des Beispiels:

Beispiel 2 (Visual Studio 2010)

Die beiden Beispiele zeigen recht gut, wie eine Anwendung aus eigenständigen Modulen bestehen kann, ohne dass der Programmieraufwand extrem ansteigt. Der Einsatz einer Class Factory hilft, die Flexibilität zu erhöhen.

Die genannten Abhängigkeiten entstehen z. B. durch den Verweis eines Objekt auf
ein anderes Objekt. Ohne die Anwendung von Constructor-Injection ist jedes Objekt selbst für die Erzeugung und Verwaltung seiner Abhängigkeiten zuständig.

Das Attribut ImportingConstructor

MEF benutzt zum Instanziieren von Komponenten immer den Standardkonstruktor. Soll ein anderer Konstruktor verwendet werden, so muss dieser mit dem Attribut ImportingConstructor dekoriert werden. Es darf nur ein Konstruktor das Attribut ImportingConstructor besitzen. Besitzen mehrere Konstruktoren das Attribut, kommt es zu einem Laufzeitfehler. Ebenfalls tritt ein Laufzeitfehler auf, wenn es keinen Standardkonstruktor gibt und kein Konstruktor mit dem Attribut ImportingConstructor dekoriert wurde. Interessant ist hier, dass die Konstruktoren ohne Probleme als private deklariert werden können. Alle Parameter des Konstruktors werden automatisch als Importe deklariert. Somit muss es in dem Host nur noch einen passenden Export geben.

Man kann (und man sollte auch) hier mit Vertragsnamen arbeiten. Spätestens wenn mehrere Parameter vom gleichen Typ vorhanden sind, ist dieses notwendig. Im Konstruktor wird hierzu das Attribut Import explizit vor jedem Parameter angegeben. Das Attribut Export im Host muss natürlich den gleichen Vertragsnamen erhalten.

Dekoration des Konstruktors mit dem Attribut ImportingConstructor bei einem Export.

[ImportingConstructor]
private Foo([Import("ConstructorParameter")]int parameter)
{
    Console.WriteLine(String.Format("Parameter: {0}.", parameter));
}

Definition einer Eigenschaft innerhalb eines Imports. Die Eigenschaft wird beim Instanziieren des Exports an den Parameter des Konstruktors übergeben.

[Export("ConstructorParameter")]
private int Parameter { get; set; }

Beispiel

Das folgende Beispiel ist ein einfacher Logger, der Meldungen auf die Konsole ausgibt. Der Logger ist in der Klasse ConsoleLogger implementiert. Die Ausgabe kann individuell formatiert werden. Hierzu dient die Klasse FormatterBase, von der es zwei Ableitungen gibt. Jede dieser Ableitungen (FormatterTimeStamp und FormatterDateTimeStamp) formatieren die Ausgabe unterschiedlich. Die Klasse ConsoleLogger erwartet in seinem Konstruktor ein Objekt der Klasse FormatterBase (oder eine Ableitung davon). Über dieses Objekt, das in den Konstruktor injiziert wird, wird der Text ausgegeben.

Die Klasse FormatterBase mit den beiden Ableitungen FormatterTimeStamp und FormatterDateTimeStamp.

using System;

namespace Formatter
{
    public class FormatterBase
    {
        public virtual string Format(string message)
        {
            return message;
        }
    }

    public class FormatterTimeStamp : FormatterBase
    {
        public override string Format(string message)
        {
            return string.Format("{0} - {1}",
                                 DateTime.Now.ToShortTimeString(),
                                 message);
        }
    }

    public class FormatterDateTimeStamp : FormatterBase
    {
        public override string Format(string message)
        {
            return string.Format("{0} {1} - {2}",
                                  DateTime.Now.ToShortDateString(),
                                  DateTime.Now.ToShortTimeString(),
                                  message);
        }
    }
}

Der Logger besitzt einen Konstruktor, der als Parameter ein Objekt vom Typ FormatterBase erwartet. Über dieses Objekt wird der Text formatiert und ausgegeben. Das Attribut ImportingConstructor gibt vor, welchen Konstruktor das Managed Extensibility Framework beim Instanziieren der Klasse benutzen soll. Der Parameter vom Konstruktor wurde hier explizit als Import deklariert.

using System;
using System.ComponentModel.Composition;
using Formatter;

namespace Logger
{
    [Export]
    public class ConsoleLogger
    {
        private FormatterBase formatter;

        [ImportingConstructor]
        public ConsoleLogger([Import(typeof(FormatterBase))]FormatterBase formatter)
        {
            this.formatter = formatter;
        }

        public void Log(string message)
        {
            string formattedString = this.formatter.Format(message);
            Console.WriteLine(formattedString);
        }
    }
}

Die Hauptanwendung hat eine Eigenschaft mit dem Namen Logger, in der der Logger enthalten ist. Diese Eigenschaft besitzt das Attribut Import. Eine weitere Eigenschaft, ist der Parameter für den Konstruktor. Diese Eigenschaft muss vom gleichen Typ sein und außerdem den gleichen Vertragsnamen besitzen wie der Parameter vom Konstruktor.

using System.ComponentModel.Composition;
using System.ComponentModel.Composition.Hosting;
using Formatter;
using Logger;

namespace Host
{
    class Program
    {
        [Import]
        public ConsoleLogger Logger { get; set; }

        [Export(typeof(FormatterBase))]
        private FormatterBase Formatter { get; set; }

        static void Main(string[] args)
        {
            new Program().Run();
        }
        void Run()
        {
            var catalog = new DirectoryCatalog(".");
            var container = new CompositionContainer(catalog);

            this.Formatter = new FormatterTimeStamp();
            //this.Formatter = new FormatterDateTimeStamp();

            container.ComposeParts(this);

            Logger.Log("Message");
        }
    }
}

Vor Aufruf der Methode ComposeParts() wird die Eigenschaft Formatter mit dem gewünschten Objekt des Formatters gesetzt. MEF übergibt diese Eigenschaft an den Konstruktor der Klasse ConsoleLogger. Auf diese Weise kann per Constructor-Injection festgelegt werden, wie die Ausgabe des Loggers formatiert wird.

Das Beispiel wurde so erstellt, dass Hauptanwendung, Logger und Formatter in unterschiedlichen Assemblies liegen. So kann z.B. die DLL für den Formatter ausgetauscht werden, ohne dass die Hauptanwendung angefasst werden muss.

Beispiel 1 (Visual Studio 2010)

Composition

Composable Parts sind Objekte (Klassen, Schnittstellen, Methoden oder Eigenschaften), die mit dem Attribut Import, ImportMany oder Export dekoriert werden. Composable Parts, die als Export definiert wurden, werden vom Managed Extensibility Framework geladen und instanziiert. Die Composable Parts, die als Import deklariert wurden, sind Variablen, an welche die Exports gebunden werden. Im einfachsten Fall wird ein Import an ein Export gebunden. Das ist allerdings nur möglich, wenn beide Parts zueinander kompatibel sind.

Das Managed Extensibility Framework unterstützt die Instanziierung und das Binden mit den sogenannten Katalogen und Containern. Kataloge kontrollieren das Laden der Composable Parts, während Container die Instanzen der Exports erzeugen und diese mit den Imports binden.

Die Klasse ComposablePartCatalog

Von der Klasse ComposablePartCatalog gibt es verschiedene Ableitungen. Die verschiedenen Ableitungen sind notwendig, da es mehrere Möglichkeiten gibt, Composable Parts zu laden. Zu finden sind die Klassen in dem Namespace System.ComponentModel.Composition.Hosting. Composable Parts können sich in der gleichen Assembly befinden oder auf mehreren Assemblies verteilt sein. Des weiteren muss unterschieden werden, ob die Assemblies statisch oder dynamisch geladen werden.

Die Klasse CompositionContainer

Über die Klasse CompositionContainer wird das Laden und Binden der Composable Parts gestartet. Hierzu wird dem Konstruktor der Klasse CompositionContainer als Parameter der Katalog übergeben. Die Methode ComposeParts() startet den Composing Prozess. Als Parameter muss der Methode ComposeParts() die Referenz auf das Objekt übergeben werden, das die Imports enthält. Alternativ kann aber auch die Methode Compose() aufgerufen werden, die eine Instanz der Klasse CompositionBatch erwartet.

Die Klasse CompositionBatch

Der Methode Compose() der Klasse CompositionContainer kann als Parameter eine Instanz der Klasse CompositionBatch übergeben werden. CompositionBatch verwaltet eine Liste von Composable Parts, die beim Composing Prozess berücksichtigt werden sollen.

Beispiel

Das folgende Beispiel zeigt die Benutzung aller genannten Klassen.

using System;
using System.Collections.Generic;
using System.ComponentModel.Composition;
using System.ComponentModel.Composition.Hosting;
using System.Reflection;
using CarContract;

namespace CarHost
{
    class Program
    {
        [ImportMany(typeof(ICarContract), AllowRecomposition=true)]
        private IEnumerable<ICarContract> CarParts { get; set; }

        static void Main(string[] args)
        {
            new Program().Run();
        }
        void Run()
        {
            var catalog = new AggregateCatalog();

            // Parameterliste mit Klassen, die berücksichtigt werden sollen
            var typeCatalog = new TypeCatalog(typeof(CarMercedes.Mercedes),
                                                     typeof(CarAudi.Audi));
            catalog.Catalogs.Add(typeCatalog);
           
            // Assembly wird über den FullName dynamisch geladen und
            // dem Katalog hinzugefügt
            var assemblyCatalog = new AssemblyCatalog(
                                             Assembly.Load(
                                                      "Opel,
                                                       Version=1.0.0.0,
                                                       Culture=neutral,
                                                       PublicKeyToken=null"));
            catalog.Catalogs.Add(assemblyCatalog);
            
            // Assemblies aus dem Verzeichnis '.\AddIn' werden berücksichtigt
            var directoryCatalog = new DirectoryCatalog(@".\AddIn");
            catalog.Catalogs.Add(directoryCatalog);

            // Container mit dem entsprechenden Katalog anlegen
            var container = new CompositionContainer(catalog);

            // Composition über die Klasse CompositionBatch starten
            var batch = new CompositionBatch();
            batch.AddPart(this);
            container.Compose(batch);

            // Composition ohne CompositionBatch starten
            //container.ComposeParts(this);
            // eine Parameterliste von Objekten kann auch angegeben werden
            //container.ComposeParts(this, obj1, obj2);

            // Anzeige aller Composable Parts
            foreach (ICarContract car in CarParts)
                Console.WriteLine(car.GetName());

            container.Dispose();
        }
    }
}

Die Ausgabe des Beispielprogramms sieht wie folgt aus:

Beispiel 1 (Visual Studio 2010)

Recomposition

Mit Recomposition bezeichnet man die Möglichkeit, weitere Composable Parts zur Laufzeit nachzuladen. Vorstellbar wäre z.B. eine Anwendung, die von einer externen Quelle zusätzliche Komponenten nachlädt.

MEF ist so ausgelegt, dass ein Recomposition nicht möglich ist. Soll Recomposition unterstützt werden, so muss bei dem Attribut Import oder ImportMany die Eigenschaft AllowRecomposition auf TRUE gesetzt werden.

[ImportMany(typeof(ICarContract), AllowRecomposition=true)]

Recomposition kann nur über die Kataloge DirectoryCatalog und AggregateCatalog genutzt werden. Die Klasse DirectoryCatalog bietet hierzu speziell die Methode Refresh() an. Diese lädt alle Composable Parts erneut aus dem Verzeichnis des Katalogs.

Mit AggregateCatalog kann die Liste der Kataloge komplett neu aufgebaut werden. Somit lässt sich die Zusammenstellung der Composable Parts zur Laufzeit neu zusammensetzen. Hierzu ein kleines Beispiel.

using System;
using System.Collections.Generic;
using System.ComponentModel.Composition;
using System.ComponentModel.Composition.Hosting;
using CarContract;

namespace CarHost
{
    class Program
    {
        [ImportMany(typeof(ICarContract), AllowRecomposition=true)]
        private IEnumerable< ICarContract > CarParts { get; set; }

        static void Main(string[] args)
        {
            new Program().Run();
        }
        void Run()
        {
            var aggregateCatalog = new AggregateCatalog();

            aggregateCatalog.Catalogs.Add(new DirectoryCatalog(@".\AddIn01"));
            var container = new CompositionContainer(aggregateCatalog);
            container.ComposeParts(this);

            foreach (ICarContract car in CarParts)
                Console.WriteLine(car.GetName());
                
            Console.WriteLine("\n...weitere Parts laden...\n");

            aggregateCatalog.Catalogs.Add(new DirectoryCatalog(@".\AddIn02"));
            container.ComposeParts(this);

            foreach (ICarContract car in CarParts)
                Console.WriteLine(car.GetName());

            container.Dispose();
        }
    }
}

Am Anfang wird ein Objekt der Klasse AggregateCatalog angelegt. Dieser Katalog verwaltet eine Liste mit weiteren Katalogen. In diesem Beispiel enthält die Liste ein DirectoryCatalog mit dem Unterverzeichnis AddIn01. Die Zeilen 26 und 27 rufen von allen gefundenen Composable Parts die Methode GetName() auf. Ab Zeile 31 wird die Liste um einen weiteren Katalog ergänzt. Dieses zweite Objekt der Klasse DirectoryCatalog verweist auf das Verzeichnis AddIn02.

Auf diese Weise lässt sich die Liste der zu berücksichtigen Kataloge beliebig anpassen. Neben dem Hinzufügen ist es auch möglich, Kataloge mit den Methoden Clear() und Remove() zu entfernen. In diesem Fall werden die Composable Parts von MEF zerstört.

Beispiel 2 (Visual Studio 2010)

Wird das Anpassen der Liste mit den Katalogen asynchron durchgeführt, so muss darauf geachtet werden, dass die Composable Parts thread-safe sind. Der Konstruktor der Composable Parts wird immer im Kontext des Threads ausgeführt, aus dem die Methode ComposeParts() der Klasse CompositionContainer aufgerufen wird.