1.3 Assemblys 
Das Ergebnis der Kompilierung von .NET-Quellcode ist eine Assembly. Bei der Kompilierung wird, abhängig davon, welchen Projekttyp Sie gewählt haben, entweder eine EXE- oder eine DLL-Datei erzeugt. Wenn Sie nun in diesen Dateien ein Äquivalent zu den EXE- oder DLL-Dateien sehen, die Sie mit Visual Basic 6.0 oder C/C++ erzeugt haben, liegen Sie falsch – beide sind nicht miteinander vergleichbar.
Assemblys liegen im IL-Code vor. Zur Erinnerung: IL bzw. MSIL ist ein Format, das erst zur Laufzeit einer Anwendung vom JITter in nativen Code kompiliert wird. Eine Assembly kann nicht nur eine, sondern auch mehrere Dateien enthalten – eine Assembly ist daher eher als die Baugruppe einer Anwendung zu verstehen.
Assemblys liegen, wie auch die herkömmlichen ausführbaren Dateien, im PE-Format (Portable Executable) vor, einem Standardformat für Programmdateien unter Windows. Das Öffnen einer PE-Datei hat zur Folge, dass die Datei der Laufzeitumgebung übergeben und als Folge dessen ausgeführt wird. Daher wird Ihnen beim Starten auch kein Unterschied zwischen einer Assembly und einer herkömmlichen Datei auffallen.
1.3.1 Die Metadaten 
Assemblys weisen eine grundsätzlich neue, andersartige Struktur auf. Assemblys enthalten nämlich nicht nur IL-Code, sondern auch sogenannte Metadaten. Die Struktur einer kompilierten .NET-Komponente gliedert sich demnach in
- IL-Code und
- Metadaten.
Metadaten sind Daten, die eine Komponente beschreiben. Das hört sich im ersten Moment kompliziert an, ist aber ein ganz triviales Prinzip. Nehmen wir an, Sie hätten die Klasse Auto mit den Methoden Fahren, Bremsen und Hupen entwickelt. Wird diese Klasse kompiliert und der IL-Code erzeugt, lässt sich nicht mehr sagen, was der Binärcode enthält, und vor allem, wie er genutzt werden kann. Wenn eine andere Komponente auf die Idee kommt, den kompilierten Code eines Auto-Objekts zu nutzen, steht sie vor verschlossenen Türen.
Den Zusammenhang zwischen Metadaten und IL-Code können Sie sich wie das Verhältnis zwischen Inhaltverzeichnis und Buchtext vorstellen: Man sucht unter einem Stichwort im Inhaltverzeichnis nach einem bestimmten Begriff, findet eine Seitenzahl und kann zielgerichtet im Buch das gewünschte Thema nachlesen. Viel mehr machen die Metadaten eines .NET-Kompilats auch nicht, wenn auch die Funktionsweise naturgemäß etwas abstrakter ist: Sie liefern Objektinformationen, beispielsweise die Eigenschaften eines Objekts und die Methoden. Das geht sogar so weit, dass wir über die Metadaten in Erfahrung bringen, wie die Methoden aufgerufen werden müssen.
Das grundsätzliche Prinzip der Aufteilung in Code und Metadaten ist nicht neu und wurde auch schon unter COM angewandt – allerdings mit einem kleinen, aber doch sehr wesentlichen Unterschied: COM trennt Code und Metadaten. Die Metadaten einer COM-Komponente, die man auch als Typbibliothek bezeichnet, werden in die Registry eingetragen und dort ausgewertet. Das ist nicht gut, denn schließlich sollten Sie Ihren Personalausweis immer bei sich tragen und ihn nicht irgendwo hinterlegen. Ebenso sollte auch der Code nicht von seinen Metadaten getrennt werden. COM ist dazu nicht in der Lage; erst innerhalb des .NET Frameworks wird dieser fundamentalen Forderung nach einer untrennbaren Selbstbeschreibung Rechnung getragen.
Die Metadaten versorgen die .NET-Laufzeitumgebung mit ausreichenden Informationen zum Erstellen von Objekten sowie zum Aufruf von Methoden und Eigenschaften. Sie bilden eine klar definierte Schnittstelle und vereinheitlichen den Objektzugriff, was allen .NET-Entwicklern zugute kommt: Unabhängig von der Sprache – vorausgesetzt, sie ist .NET-konform – können problemlos Objekte verwendet werden, die von anderen Entwicklern bereitgestellt werden. Dass die Objekte in einer beliebigen .NET-Sprache entwickelt sein können, braucht fast nicht erwähnt zu werden.
1.3.2 Das Manifest
Die Folgen der Trennung von Code und Selbstbeschreibung einer COM-Komponente sind uns wahrscheinlich allen bewusst: Durch die Installation einer neuen Anwendung werden alte COM-Komponenten überschrieben, die für andere Anwendungen von existenzieller Bedeutung sind. Die Auswirkungen können fatal sein: Eine Anwendung, die auf die Methoden der überschriebenen Komponente zugreifen will, kann sich im schlimmsten Fall mit einem Laufzeitfehler sang- und klanglos verabschieden.
Mit Assemblierungen gehören diese Fehler definitiv der Vergangenheit an. Verantwortlich dafür sind Metadaten, die nicht die einzelnen Objekte, sondern die Assemblierung als Ganzes beschreiben. Diese Daten werden als Manifest bezeichnet. Ein Manifest enthält die folgenden Informationen:
- Name und Versionsnummer der Assembly
- Angaben über andere Assemblierungen, von denen die aktuelle Assembly abhängt
- die von der Assembly veröffentlichten Typen
- Sicherheitsrichtlinien, nach denen der Zugriff auf die Assembly festgelegt wird
Das Manifest befreit eine Assembly von der Notwendigkeit, sich in die Registrierung eintragen zu müssen, und die logischen Konsequenzen gehen sogar noch weiter: Während sich COM-Komponenten erst durch eine Setup-Routine oder zusätzliche Tools in die Registrierungsdatenbank eintragen, können Sie mit den primitivsten Copy-Befehlen eine Assemblierung in ein beliebiges Verzeichnis kopieren – Altbewährtes ist manchmal doch nicht so schlecht.
