Managed Code

Eintrag zuletzt aktualisiert am: 30.06.2005

Programmcode, der im .NET Framework unter der .NET-Laufzeitumgebung abläuft, wird als Managed Code bezeichnet. Im Gegensatz dazu wird herkömmlicher Code als Unmanaged Code oder Classic Code bezeichnet.
Das Kompilat von C#, Visual Basic .NET und JScript.NET ist immer Managed Code. Visual C++ 7.0 kann durch eine Compiler-Option Managed Code erzeugen.Visual FoxPro kann keinen Managed Code erzeugen. Es gibt zahlreiche weitere Sprachen, die Managed Code erzeugen können.

Ein .NET-Modul ist eine Einheit aus kompiliertem Programmcode im MSIL-Format und den zugehörigen Metadaten, die die im Code definierten Typen beschreiben. Ein .NET-Modul ist Teil einer .EXE- oder .DLL-Datei oder aber eine separate Datei mit der Dateiextension .NETMODULE. Die Datei liegt in beiden Fällen im Portable Executable (PE) File Format vor.

Übersetzung und Ablauf von .NET-Anwendungen

Sowohl die Programmiersprache Java als auch das .NET Framework basieren auf dem Konzept Write Once Run Anywhere (WORA). Das .NET Framework arbeitet – genau wie Java – mit einem Intermediationskonzept auf Basis einer Zwischensprache. Ein Compiler einer .NET-Sprache erzeugt also nicht einen pro-zessorspezifischen Maschinencode, sondern einen plattformunabhängigenZwischencode. Dieser Zwischencode wird Micro-soft Intermediate Language (MSIL) oder – im ECMA- und ISO-Standard - Common Intermediate Language (CIL) genannt. Code in MSIL wird auch als verwalteter Code (Managed Code) be-zeichnet. Im Gegensatz dazu wird prozessorspezifischer Maschienencode als nicht-verwalteter (Unmanaged Code) oder Native Code bezeichnet.

Erst zur Laufzeit wird der MSIL-Code dann in einen prozessor-spezifischen Maschinencode (Native Code) umgewandelt. MSIL-Code wird nicht interpretiert, sondern von einem sogenannten Just-in-Time-Compiler Stückchenweise umgewandelt und dann ausgeführt. Dabei berücksichtigt der Just-in-Time-Compiler prozessorspezifische Optimierungsmöglichkeiten. Dadurch, dass nicht interpretiert, sondern vor der Ausführung kompiliert wird und der Just-in-Time-Compiler sehr schnell ist, ist der Performance-Verlust durch die Intermediation sehr gering. Im Zweifel gibt es auch die Möglichkeit, die das Ergebnis der Kompilierung von MSIL zu Maschinencode zu speichern und später auszufüh-ren. Dies nennt man ein Native Image. Ein Native Image ist jedoch nicht mehr plattformunabhängig. Es ist nicht verboten, dass Sprachcompiler auch wahlweise auch direkt Native Code erzeugen, der nicht unter der Kontrolle der .NET-Laufzeitumgebung abläuft.

Der Just-in-Time-Compiler ist Teil der .NET-Laufzeitumgebung, die Common Language Runtime (CLR) genannt wird. Das In-termediationskonzept ist die Basis für die Plattformunabhängig-keit der Anwendungen. Managed Code kann auf jedem Betriebs-system ausgeführt werden, für das eine Implementierung der Common Language Runtime verfügbar ist.

Natürlich ist Managed Code langsamer als Native Code, wobei der Geschwindigkeitsunterschied sehr viel geringer ist als man vermuten kann. Wenn jedoch die optimale Geschwindigkeit notwendig ist, besteht die Möglichkeit, eine Managed Code-Datei einmalig in eine Native Code-Datei umzuwandeln. Dazu dient das Werkzeug ngen.exe. Der Vorgang wird als "Pre-Jitting" bezeichnet. Das Result von ngen.exe nennt man ein Native Image. Ngen.exe wurde in .NET 2.0 stark vereinfacht (z.B. wer-den nun alle referenzierten Komponenten automatisch mit über-setzt).

Grundsätzlich kann zwar ein Native Image bereits während der Entwicklung erzeugt werden, aufgrund der plattformspezifischen Übersetzung bietet es sich jedoch an, das Native Image erst bei der Installation einer .NET-Anwendung zu erzeugen (Install Time Compilation). Das Native Image ist spezifisch für eine bestimmte Version der .NET-Laufzeitumgebung. Auch benötigen DOS- und NT-basierte Windows-Systeme verschiedene Native Images. Auch eine .NET-Anwendung, die in einem Native Image gespeichert ist, benötigt die .NET-Laufzeitumgebung, um ausge-führt werden zu können.