Beispiel II – Visual Basic.NET nutzt C# Nun soll noch einmal kurz der umgekehrte Fall betrachtet werden. Das Beispiel ist genau das gleiche, nur dass dieses mal das Interface in C# und die Implementierung in Visual Basic.NET erfolgt.
Das C# Interface Das C# Interface ist ebenso einfach wie das VB.NET Interface, genau genommen ist es dasselbe:
namespace CSInterface {
public interface IInterface {
void SayHello();
void PrintText(string Msg);
DateTime GetTime();
}
}
Auf den ersten Blick scheint der erzeugte IL-Code wenig spannend, da er dem IL-Code des VB.NET Beispiels zum Verwechseln ähnlich sieht. Genau das ist aber der interessante Punkt. Zunächst betrachten wir noch einmal den IL-Code des VB.NET Interfaces:
.class interface public abstract auto ansi IInterface
{
} // end of class IInterface
Nun stellen dem wir den erzeugten IL-Code des C# Interfaces gegenüber:
.class interface public abstract auto ansi IInterface
{
} // end of class IInterface
Wie unschwer zu erkennen ist, ist der erzeugte Quellcode identisch. Damit ist klar, dass die eigentliche Programmiersprache auf der .NET-Plattform weitgehend irrelevant ist. Externe Konstrukte, wie z.B. eine IDL, sind aufgrund des IL-Zwischencodes nicht mehr notwendig, da dieser Zwischencode für alle Sprachen verständlich ist.
Einschränkungen im Sprachgebrauch Wie dargestellt wurde, ist die .NET-Plattform sprachneutral und setzt keine bestimmte Programmiersprache voraus. Jede Programmiersprache ist für .NET geeignet, sofern ein Compiler existiert, der den notwendigen IL-Code erzeugen kann. Auf Basis dieses IL-Codes sind alle .NET Sprachen binärkompatibel.
Achtung – Eines muss dabei jedoch zwingend beachtet werden! Die uneingeschränkte Kompatibilität und Interoperabilität wird nur dann erreicht, wenn bestimmte Restriktionen hinsichtlich der öffentlichen Interfaces eingehalten werden. Diese Restriktionen sind in der so genannten Common Language Specification hinterlegt, die eine Untermenge des Common Type System ist. Die CLS ist ein Regelsatz, der beispielsweise Pointertypen oder Unsafe-Code an der öffentlichen Klassenschnittstelle verbietet. Dies findet seine Ursache in einer genaueren Betrachtung des .NET „Sprachen-Zoos“. Hier finden sich beispielsweise So komplexe Sprachen wie C++ oder aber auch so abstrakte wie Visual Basic. Beiden Sprachen liegen unterschiedliche Konzepte zu Grunde. C++ kann beispielsweise mit Pointern umgehen – Visual Basic nicht.
Aus diesem Grund könnte beispielsweise ein VB.NET Programm nichts mit einer C++ geschriebenen Klasse anfangen, die Pointer an der öffentlichen Schnittstelle definiert.
Uneingeschränkte Sprachinteroperabilität wird nur von so genannten CLS-konformen Typen gewährleistet. Um die CLS-Konformität eines Typs garantieren zu können, kann man als Entwickler einen Typ, dem Attribut [CLSCompliance] kennzeichnen:
//Beispiel:
[CLScompliance(true)]
public class Foo
{
...
}
Dieses Attribut wird bereits durch den Sprachcompiler ausgewertet. Der Compiler bricht mit einem Fehler ab, wenn er die geforderte CLS-Konformität nicht feststellen kann. Ist ein Typ CLS-konform, dann ist er in jeder (!) .NET Sprache beliebig nachnutzbar.