Hace un par de días, vi el CoClassAttribute utilizado de una manera que no había imaginado antes.

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

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

siendo utilizado como:

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

Eso no debería haberme sorprendido ya que COM Interop hace exactamente eso desde los primeros días de .NET Framework. Simplemente no he prestado tanta atención al investigar el código de interoperabilidad COM en .NET Reflector.

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 
}

Lo que sucedió es que fuera del contexto de la interoperabilidad COM, inmediatamente imaginé que esto se usaría como uninyección de dependencia de tiempo de compilación del pobre hombre.

Todo lo que hay que hacer es deshacerse del prefijo convencional "I" en el nombre de la interfaz (al igual que COM Interop).

Entonces sería cuestión de cambiar el atributo CoClass para intercambiar una implementación por otra, burlarse, etc.

Dos inconvenientes que veo por adelantado son tener que volver a compilar (lo que limita en gran medida los escenarios de prueba al tiempo de desarrollo) y eventuales problemas relacionados con las dependencias circulares cuando se implementan interfaces e implementaciones en diferentes ensamblajes.

¿Alguien ha jugado con esta técnica? ¿Algún otro inconveniente? ¿Otros usos?