Eintrag kommentierenEintrag bewerten
Dieser Eintrag wurde im Schnitt mit 0 von 5 Punkten bewertet
Erfahrung
Interoperabilität von .NET-Sprachen (Teil 3)
Erfahrung:21844
Externe Quellen zum Thema NEU: Externe Quellen zum Thema suchen 
Beschreibung der Erfahrung
Des Weiteren existiert noch eine Abhängigkeit auf der Dateiebene. Um korrekt funktionieren zu können, benötigt die Implementationsklasse Kenntnis vom Interface. Dies beinhaltet Metadaten, Signaturen etc. Dazu wird bereits in den Metadaten der C# Assembly eine Referenz zum Compilat des VB.NET Interfaces hergestellt. Das folgende Listing zeigt das Manifest der C# Assembly, in der diese Abhängigkeiten hinterlegt sind.

.assembly extern mscorlib
{
.publickeytoken = (B7 7A 5C 56 19 34 E0 89 ) // .z\V.4..
.ver 1:0:5000:0
}
.assembly extern VBInterface {.ver 1:0:1614:20421}

.assembly CSClass
{
.custom instance void [mscorlib]System.Reflection.Assembly-
KeyNameAttribute::.ctor(string) = ( 01 00 00 00 00 )
.custom instance void [mscorlib]System.Reflection.Assembly-
KeyFileAttribute::.ctor(string) = ( 01 00 00 00 00 )
.custom instance void [mscorlib]System.Reflection.Assembly-
DelaySignAttribute::.ctor(bool) = ( 01 00 00 00 00 )
.custom instance void [mscorlib]System.Reflection.Assembly-
TrademarkAttribute::.ctor(string) = ( 01 00 00 00 00 )
.custom instance void [mscorlib]System.Reflection.Assembly-
CopyrightAttribute::.ctor(string) = ( 01 00 00 00 00 )
.custom instance void [mscorlib]System.Reflection.Assembly-
ProductAttribute::.ctor(string) = ( 01 00 00 00 00 )
.custom instance void [mscorlib]System.Reflection.Assembly-
CompanyAttribute::.ctor(string) = ( 01 00 00 00 00 )
.custom instance void [mscorlib]System.Reflection.Assembly-
ConfigurationAttribute::.ctor(string) = ( 01 00 00 00 00 )
.custom instance void [mscorlib]System.Reflection.Assembly-
DescriptionAttribute::.ctor(string) = ( 01 00 00 00 00 )
.custom instance void [mscorlib]System.Reflection.Assembly-
TitleAttribute::.ctor(string) = ( 01 00 00 00 00 )

// --- Folg. benutzerdef. Attribut automat. hinzugefügt.
// Kommentare nicht entf. -------
.custom instance void [mscorlib]System.Diagnostics.Debuggable-
Attribute::.ctor(bool, bool) = ( 01 00 01 01 00 00 )
.hash algorithm 0x00008004
.ver 1:0:1614:20569
}
.module CSClass.exe
// MVID: {23E2A187-90AE-4096-89C7-5FE671768862}
.imagebase 0x11000000
.subsystem 0x00000003
.file alignment 4096
.corflags 0x00000001
// Image base: 0x06ce0000

Das Manifest beschreibt dabei nicht nur, was in einer Assembly (Datentypen, Ressourcen) enthalten ist, sondern wie im gerade gezeigten Fragment auch ersichtlich ist, was zusätzlich noch an externen Ressourcen benötigt wird. Im hervorgehobenen Teil .assembly extern VBInterface {…} wird die Referenz zu einer externen Assembly hergestellt. Der Classloader (Analogon zu Java) der CLR kann daraufhin bestimmen, wo eventuell referenzierte Typen zu finden sind und kann somit alle Verweise korrekt auflösen.

Da sowohl das Visual Basic.NET Interface als auch die Implementationsklasse durch die jeweiligen Sprachcompiler immer in den IL-Zwischencode übersetzt werden, ist es auf der Ebene dieses Codes irrelevant, durch welche Programmiersprache er erzeugt wurde. Für die Laufzeitumgebung ist nur (!) der IL-Code interessant – nicht jedoch die Ursprungssprache. Auf der Ebene der Compilate sind somit alle .NET Sprache binärkompatibel.
Analog ist für das Schnittstellenkonzept zu argumentieren. Da Schnittstellen immer im Zwischencode vorliegen, ist es für einen Entwickler, der ein Interface implementieren muss unerheblich, in welcher Sprache es definiert wurde. Er kann ein beliebiges Interface somit auch in einer beliebigen Sprache implementieren. Die folgende Abbildung skizziert dies noch einmal:
langinterop2

zurück...
weiter...
Externe Quellen zum Thema NEU: Externe Quellen zum Thema suchen 
 Eintrag kommentieren 
 Eintrag bewerten 
Zu dieser Seite wurden noch keine Kommentare oder Bewertungen abgegeben.
 
Zum Seitenanfang Top Drucken Impressum AGB
Home

VSEK ©2001-2012