Um par de dias atrás, eu vi o CoClassAttribute sendo usado de uma maneira que eu não tinha 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!");
    }
}

sendo usado como:

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

Isso não deveria me surpreender, pois o COM Interop faz exatamente isso desde os primeiros dias do .NET Framework. Eu simplesmente não prestei muita atenção ao pesquisar códigos de interoperabilidade COM no .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 
}

O que aconteceu é que fora do contexto da COM Interop, eu imediatamente imaginei isso sendo usado como uminjeção de dependência de tempo de compilação do pobre homem.

Tudo o que há a fazer é se livrar do prefixo convencional "I" no nome da interface (assim como COM Interop).

Então seria uma questão de mudar o atributo CoClass para trocar uma implementação por outra, zombaria, etc.

Duas desvantagens que vejo de antemão estão sendo recompiladas (o que praticamente limita os cenários de teste ao tempo de desenvolvimento) e eventuais problemas relacionados às dependências circulares quando interfaces e implementações são implantadas em diferentes montagens.

Alguém jogou com essa técnica? Alguma outra desvantagem? Outros usos?