Vor ein paar Tagen habe ich gesehen, wie das CoClassAttribute auf eine Weise verwendet wurde, wie ich es mir noch nie vorgestellt hatte.

[ComImport, CoClass(typeof(Foo)), Guid("787C1303-AE31-47a2-8E89-07C7257B1C43")]
interface IFoo {
    void Bar();
}

class Foo : IFoo {
    public void Bar() {
        Console.WriteLine("Oh retado!");
    }
}

wird verwendet als:

class CoClassDemo {
    public static void Show() {
        var a = new IFoo();
        a.Bar();
    }
}

Das hätte mich nicht wundern sollen, da COM Interop seit den Anfängen von .NET Framework genau das tut. Ich habe beim Durchsuchen von COM Interop-Code in .NET Reflector einfach nicht so viel Aufmerksamkeit geschenkt.

method public hidebysig static void Show() cil managed
{
    .maxstack 1
    .locals init (
        [0] class ConsoleApplication1.IFoo a)
    L_0000: nop 
    L_0001: newobj instance void ConsoleApplication1.Foo::.ctor()
    L_0006: stloc.0 
    L_0007: ldloc.0 
    L_0008: callvirt instance void ConsoleApplication1.IFoo::Bar()
    L_000d: nop 
    L_000e: ret 
}

Was passiert ist, ist, dass ich mir aus dem Kontext von COM Interop heraus sofort vorgestellt habe, dass dies alsKompilierzeitabhängigkeitsinjektion des armen Mannes.

Alles, was Sie tun müssen, ist das herkömmliche "I" -Präfix auf dem Namen der Schnittstelle zu entfernen (wie auch COM Interop).

Dann müsste das CoClass-Attribut geändert werden, um eine Implementierung gegen eine andere auszutauschen, zu verspotten usw.

Zwei Nachteile, die ich im Vorfeld sehe, sind das Neukompilieren (was das Testen von Szenarien auf die Entwicklungszeit beschränkt) und mögliche Probleme im Zusammenhang mit zirkulären Abhängigkeiten, wenn Schnittstellen und Implementierungen für verschiedene Assemblys bereitgestellt werden.

Hat jemand mit dieser Technik gespielt? Irgendwelche anderen Nachteile? Andere Verwendungen?