Ein Programm kann nicht für dich entscheiden, was es tut, das musst du ihm schon sagen.
Du musst also mindestens sagen, dass in jeder Methode eine NotImplementedException geworfen wird, wobei du dann aber auch z.B. den Konstruktor ausschließen musst, da die Klasse sonst praktisch nutzlos ist.
Wenn du ein Interface automatisch implementieren möchtest, fallen mir mehrere Möglichkeiten ein.
Zum Einen, wenn es darum geht, das zur Design-Zeit zu machen, gibt es T4. Das ist z.B. ganz praktisch, wenn du Delegates wie Func hast, die sehr viele generische Parameter unterstützen.
Im Projekt Mono.Cecil wurden so eine Reihe Func-Delegaten für die Abwärzkompatibilität generiert, da ein manuelles Schreiben einfach lange dauern würde.
Zum Anderen gibt es übliche Mocking-Frameworks, wie ja schon genannt wurde. Wie sie dann am Ende implementieren, kann ich dir nicht sagen, das hängt am ehesten vom jeweiligen Framework ab. Ohne eigene Angaben wird das aber vermutlich nicht funktionsfähig enden.
Wenn es darum geht, ein Programm zur Laufzeit zu programmieren (und damit auch die Implementierung eines Interfaces), dann gibt es zwei Optionen. Als erstes gibt es Reflection.Emit im .NET-Framework. Damit kannst du ebenfalls Assemblies erzeugen, sowohl in eine Datei, als auch in den Speicher. Oder du nimmst das Mono.Cecil-Projekt, was ich schon erwähnt habe. Das kann unabhängig vom .NET-Framework Assemblies erstellen oder Bestehende bearbeiten. Letzteres hat den Vorteil, dass es komplett unabhängig von so unflexiblen Komponenten wie die Type-Klasse sind. Mit Cecil lässt sich die Arbeit generischer und flexibler erledigen. Aus dem Grund wird es auch gerne für Frameworks (z.B. Mocking-Frameworks, wie Moq) und Programme (wie z.B. ILSpy) verwendet, die auf einer so tiefen ebene arbeiten.
Als letztes kannst du natürlich den Code als String zur Laufzeit generieren und anschließend kompilieren.
Zusammenfassend kann ich aber sagen:
Wenn T4 nicht in Frage kommt und Mocking-Frameworks nicht das tun, was du willst, dann solltest du dich auf viel Arbeit und eine ganze Reihe Herausforderungen einstellen. Auch, wenn du Mono.Cecil oder Reflection.Emit nutzt, musst du dich darauf einstellen, CIL-Code zu verstehen und was der Compiler aus dem C#-Code macht.
Ich habe mich damit lange Zeit auseinander gesetzt und eine ganze Menge neuer Versuche für eine Idee gebraucht um zu kapieren, dass der Aufwand den Nutzen schlicht und einfach nicht rechtfertigt. Abgesehen davon ist die Fehleranfälligkeit so hoch, dass es am Ende sogar mehr Aufwand kosten würde.
Soll heißen: Überlege dir lieber nochmal, warum du das genau machen willst und ob es nicht einen besseren Weg dafür gibt.
Das Ganze kann zwar nnützlich sein, aber nur in seltenen Fällen.
ILSpy zum Beispiel ist ein Decompiler, oder du möchtest tatsächlich Assemblies nach der Kompilierung berarbeiten, was bestimmt Nutzen im weniger legalen Bereich der Softwareentwicklung findet.
Für die meisten anderen Anwendungsfälle lässt sich aber auch ein anderer Weg finden, oder zumindest ein Umweg mit Koompromissen, der am Ende immer noch besser ist.
PS:
Wenn du doch selber den Code generieren möchtest (Emit, Mono.Cecil, C#-Code zur Laufzeit kompilieren), dann überlege dir vorher sehr genau, was wie gemacht werden soll, da der pure Umfang sonst sehr schnell ausufert.
