Was ist .NET? Die .NET Common Language Runtime

1
Softwareentwicklung mit .NET Teil 1 Was ist
.NET? Die .NET Common Language Runtime Dr.
Ralph Zeller DI. Wolfgang Beer Michael Willers
2
Was ist .NET?
Mit dem .NET Framework können verteilte, XML
basierte Web Applikationen erstellt werden. Zu
einer .NET Plattform gehört ein geeignetes
Betriebssystem und Serversoftware.
3
Was gehört zu .NET?
PCs und Smart Devices
Benutzer-sicht
Entwickler Tools
VisualStudio.NET
.NET Framework
Web Services
Identity
Notification
Mobile Information 2001 Server
Host Integration Server 2000
BizTalk Server 2000
Commerce Server 2000
Exchange 2000
SQL Server 2000
ISA Server 2000
Application Center 2000
Infrastruktur
4
.NET DesignWeb Services

• Programmatischer Zugriff auf Services im Web
• Kommunikation von Web-Anwendungen untereinander
• XML als Standard für Daten(beschreibung)
• plattform- und sprachunabhängig
• SOAP als Protokoll für Funktionsaufrufe
• plattform- und sprachunabhängig
• Metabeschreibung der Services per XML
• Web Service Description Language WSDL
• in Zukunft per UDDI (Universal Description,
  Discovery and Integration)

5
.NET Plattform
Common Language Runtime Einheitliche
Klassenbibliothek Visual Studio.NET
Framework Tools
Building Block Services
Ständig verfügbare Internet-Dienste (Code-Updates,
Suchdienste, Messenger)
Infrastruktur
Heutige 2000-Produktfamilie(zukünftig .NET
Enterprise Servers)
Devices
Mobile Geräte, auf denen .NET Anwendungen laufen
(Handy, Handheld)
6
Warum eine Runtime?Einheitliches
Integrationsmodell
Layer (VBRUNxx.DLL) (MSVCRT.DLL)
Layer (VBRUNxx.DLL) (MSVCRT.DLL)
Common Language Runtime (MSCOREE.DLL) (MSCORLIB.
DLL)
Microsoft Transaction Server (MTXEX.DLL)
COM Runtime (OLE32.DLL)
COM Runtime (OLE32.DLL)
7
Warum ein Framework?Einheitliches
Programmiermodell
8
Das .NET Framework
System.Web
System.WinForms
Services
UI
Design
ComponentModel
Description
HtmlControls
Discovery
WebControls
Protocols
System.Drawing
Caching
Security
Drawing2D
Printing
Configuration
SessionState
Imaging
Text
System.Data
System.Xml
ADO
SQL
XSLT
Serialization
Design
SQLTypes
XPath
System
Collections
IO
Security
Runtime
InteropServices
Configuration
Net
ServiceProcess
Remoting
Diagnostics
Reflection
Text
Serialization
Globalization
Resources
Threading
9
Übersicht
VB
C
C
ASM Code
Compiler
Compiler
Compiler
IL Code
Common Language Runtime
JIT Compiler
Betriebssystem
10
BasicsManaged Code

• Sämtlicher Code wird unter Aufsicht der Common
  Language Runtime ausgeführt
• Runtime führt Sicherheitsüberprüfungen aus
• Runtime übernimmt Speicherverwaltungund
  Fehlerbehandlung (à GC, Exceptions)
• Runtime führt Versionsprüfungen aus
• Dieser Code wird mit Managed Code bezeichnet

11
BasicsMicrosoft Intermediate Language

• Compiler erzeugen keinen native Code sondern
  eine prozessorunabhängige Zwischensprache
• Sprachintegration erfolgt auf Codeebene
• MSIL Microsoft Intermediate Language

12
BasicsCode wird kompiliert

• IL-Code wird vor der Ausführung immer (!) durch
  Compiler in echten Maschinencode übersetzt
• Unabhängigkeit von Hardwareplattformen
• unter Windows CE bereits mit einemIL-Vorläufer
  im Einsatz

13
BasicsCode wird kompiliert
14
3 Arten von JIT Compiler

• JIT
• EconoJIT
• Gleiche Funktion wie JIT benötigt aber weniger
  Ressourcen
• Der erzeugte Code nicht so optimiert wie der von
  JIT
• OptJIT
• Kann nur OptIL verarbeiten und ist dafür
• Schnell
• Benötigt wenig Ressourcen
• Erzeugt optimierten Code.
• Und existiert noch nicht -)

15
BasicsCommon Type System

• Das Typsystem wandert vom Compiler in die Runtime
• Typen werden eindeutig
• ein String unter C und ein String unter VB.NET
  sind identisch
• Sprachen werden interoperabel, da sie das gleiche
  Typsystem benutzen
• CTS Common Type System

16
BasicsImplikationen

• MSIL unterscheidet sich von reinen
  Assemblersprachen
• komplexe Datentypen und Objekte sind fester
  Bestandteil
• Konzepte wie Vererbung und Polymorphie werden von
  vornherein unterstützt

17
BasicsBeispiel 1 Hello World unter .NET
18
BasicsImplikationen

• Sprachen werden gleichwertig, da alle Compiler
  MSIL-Code erzeugen
• eine C Klasse kann von einer VB.NET Klasse
  abgeleitet sein
• einheitliche Fehlerbehandlung
• Compilerbau wird einfacher
• kein Typsystem
• Sprachen sind perDefinition interoperabel

19
Basics Beispiel 2 Integration auf Codeebene
20
Common Type SystemDas Objektmodell
Object
Value Type
Boolean
Int64
Byte
Enum
SByte
Char
Single
Type
Currency
TimeSpan
Typen im Namespace System
DateTime
String
TypedRef.
Decimal
UInt16
Double
Array
UInt32
Guid
UInt64
Exception
Int16
Void
Int32
Delegate
21
Common Type SystemBeispiel 3 Boxing und Unboxing
22
Common Type SystemGleichheit und Identität von
Objekten

• Zwei Objekte sind gleich, wenn deren Inhalte
  gleich sind
• Zwei Objekte sind identisch, wenn sie die gleiche
  Instanz referenzieren
• Gleichheit definiert sich über die virtuelle
  Methode System.Object.Equals
• identisch System.Object.Equals true
• gleich System.Object.Equals.Value true

23
Common Type SystemBeispiel 4 Delegates
Typisierte Funktionszeiger
24
Common Type SystemAttribute

• Klassen und Methoden können über Attribute mit
  Metadaten versehen werden
• Der Wert eines Attributs kann zur Laufzeit
  ausgelesen werden
• Attribute werden durch Ableitungen von der Klasse
  System.Attribute definiert
• Konsequente Weiterentwicklung des
  Attribut-Gedankens von COM
• Aber COM Attribut ? CLR Attribut !!!

25
Common Type SystemBeispiel 5 Attribute
26
Bestandsaufnahme

• Die Common Language Runtime ermöglicht unabhängig
  von Programmiersprachen eine durchgängig objekt-
  und komponentenorientierte Programmierung
• .NET Sprachen sollten sich auf die Typen
  beschränken, die über das Common Type System
  definiert sind

27
Metadaten und ReflectionÜbersetzen von Sourcen
Source Code
Typ A
Compiler (C, VB.NET, etc.)
Typ B
Typ C
28
Metadaten und Reflection

• Ein Modul dient als Container für Typen
• Ein Modul enthält
• den IL-Code der Typen
• Beschreibung der Typen
• Die Beschreibung der Typen wird mit Metadaten
  bezeichnet
• Jedes Modul enthält Metadaten
• Compiler erstellt Metadaten on the fly

29
Metadaten und Reflection

• Metadaten sind für alle Module auf die gleiche
  Art und Weise aufgebaut
• Einheitliches Format !!!
• Metadaten eines Moduls können zur Laufzeit
  ausgelesen und geändert werden
• Diesen Vorgang nennt man Reflection
• .NET Framework stellt entsprechende Klassen über
  den Namespace System.Reflection bereit

30
Metadaten und ReflectionBeispiel 6 Reflection
31
Assemblies

• .NET Anwendungen bestehen aus Assemblies
• Assembly Komponente?
• Ein Assembly ist ein Container für Module
• Sämliche Sicherheits- und Versionsüberprüfungen
  durch die CLR erfolgen auf der Basis von
  Assemblies !!!

32
AssembliesÜbersetzen von Sourcen
Compiler (C, VB.NET, etc.)
33
Assemblies

• Sobald ein Modul kompiliert ist, gehört es zu
  einem Assembly
• Compiler erstellt Assembly on the fly
• .NET Framework stellt entsprechende Klassen über
  den Namespace System.Reflection.Emit bereit
• Die im Modul vorhandenen Typen sind nur innerhalb
  des Assemblies bekannt

34
AssembliesContainer für mehrere Module
35
AssembliesManifest

• Jedes Assembly enthält genau ein Manifest
• Das Manifest beschreibt das Assembly
• Keine Headerdateien
• Keine Typenbibliothek, o. ä.

36
AssembliesManifest

• Das Manifest enthält
• Assembly-Identität
• Name Version Ländercode
• Liste der Module, aus denen das Assembly besteht
• Referenzierte Assemblies
• Exportierte Typen und Resourcen
• Attribute

37
AssembliesKategorien

• Private Assembly
• Assembly kann nur von genau einer Anwendung
  benutzt werden
• Shared Assemby
• Assembly kann global von allen Anwendungen
  benutzt werden

38
AssembliesPrivate Assembly

• Identifikation anhand eines einfachen Namens,
  z.B. Reverse
• Keine Versionsüberprüfung
• Installation per Filecopy
• Standardmäßig befinden sich Assembly und
  Anwendung im gleichen Verzeichnis
• Verzeichnis kann per CFG-Datei definiert werden

39
AssembliesBeispiel 7 Private Assembly
40
AssembliesShared Assembly

• Identifikation über einen Strong Name
• Versionsüberprüfung durch die Runtime
• Installation im Global Assembly Cache(à SDK-Tool
  al.exe oder gacutil.exe)
• systemweiter Speicherbereich
• normale Dateien
• keine Registry-Einträge, o. ä.

41
AssembliesShared Assembly - Strong Name

• Eindeutigkeit des Names wird mit Hilfe der
  Public-Key-Verschlüsselung hergestellt
• Strong Name Identität Public Key
• Attribut Originator im Manifest

42
AssembliesSign-Verfahren für Shared Assemblies

1. Keyfile erstellen (à SDK-Tool sn.exe k outf)
2. Compiler mit Keyfile und Versionsnummer aufrufen
3. Beim Erstellen des Assemblies wird der Public Key
   im Manifest eingetragen
4. Nach dem Erstellen wird das Modul, in dem sich
   das Manifest befindet, mit dem Private Key
   signiert
5. Client, der das Assembly referenziert, erhält
   beim Kompilieren den Public Key(à Attribut
   Originator in seinem Manifest)

43
AssembliesShared Assembly zur Laufzeit laden

• Client wird standardmäßig an die Version
  gebunden, die in seinem Manifest eingetragen ist
• Dieses Verhalten kann per CFG-Datei überschrieben
  werden (à später)

44
AssembliesBeispiel 8 Shared Assembly
45
VersionierungAufbau der Versionsnummer
46
VersionierungIncompatible

• Ein Shared Assembly ist grundsätzlich
  inkompatibel zum Client, wenn sich die Major-
  oder Minor-Version ändert
• Beispiel neues Produktrelease
• Runtime wirft eine Type Load Exception

47
VersionierungMaybe Compatible

• Ein Shared Assembly kann kompatibel zum Client
  sein, wenn sich die Revision bei gleichbleibender
  Major- und Minor-Version ändert
• Beispiel Servicepack
• Runtime versucht, das Assembly mit der höchsten
  Revisions- und Buildnummer zu laden

48
VersionierungQFE Quick Fix Engineering

• Ein Shared Assembly ist grundsätzlich kompatibel
  zum Client, wenn sich nur die Buildnummer ändert
• In diesem Fall liegt ein sogenannterQuick Fix
  Engineering (QFE) vor
• Beispiel Security Hotfix
• Runtime versucht, das Assembly mit der höchsten
  Revisions- und Buildnummer zu laden

49
VersionierungBeispiel 9 Standardvorgaben
50
VersionierungVorgaben per CFG-Datei definieren
51
VersionierungVorgaben per CFG-Datei definieren

• Option BindingMode ltsafe normalgt
• safeRuntime versucht die Assembly-Version zu
  laden, die im Client-Manifest eingetragen ist
• normalRuntime versucht, die Assembly-Version mit
  der höchsten Revision- und Buildnummer zu laden

52
VersionierungVorgaben per CFG-Datei definieren

• Beispiel für die Option BindingMode
• Version 2.0.0.0 ist inkompatibel zu 2.0.1.0
• ohne neu zu kompilieren können Clients dennoch
  die Version 2.0.0.0 benutzen

53
VersionierungVorgaben per CFG-Datei definieren

• Option BindingRedir Client soll eine ganz
  bestimmte Version eines Assemblies laden
• NameName des Assemblies
• OriginatorPublic Key des Assemblies, um
  Eindeutigkeit zu gewährleisten
• VersionVersion, die nicht geladen werden
  sollen(à ein Stern kennzeichnet alle Versionen)
• VersionNew Version des Assemblies, das geladen
  werden soll

54
VersionierungVorgaben per CFG-Datei definieren

• Beispiel für die Option BindingRedir
• Version 2.0.0.0 wurde installiert, hat aber einen
  Fehler
• Die Version 1.0.0.0 funktionierte hingegen
  reibungslos
• ohne neu zu kompilieren können sämtliche Aufrufe
  auf die Version 1.0.0.0 umgeleitet werden

55
VersionierungBeispiel 10 Vorgaben per CFG-Datei
definieren
56
Zusammenfassung

• Sprachübergreifende Integration und einheitliche
  Fehlerbehandung über ein gemeinsames Typsystem
• Unterschiedliche Versionen gleicher Komponenten
  können parallel betrieben werden (à Ende der DLL
  Hölle)
• Deployment von Anwendungen wird einfacher (à
  Filecopy, keine Registry)

57
Fragen?
58
Glossar

• IIS Internet Information Server Der Webserver
  von Microsoft
• CLR Common Language Runtime gemeinsame
  Laufzeitumgebung für alle .NET Anwendungen.
• CG Garbage Collection Sie sorgt dafür, das
  Speicher, der von einem Programm angefordert und
  benutzt wurde automatisch wieder freigegeben
  wird. Vorsicht beim Programmieren Die GC
  bestimmt, wann Speicher physikalisch freigegeben
  wird. Deshalb sollten teure Resourcen - wie
  bspw. Datenbankverbindungen - explizit innerhalb
  einer eigens dafür geschriebenen Methode
  entsorgt werden. Diese Methode sollte immer
  dann aufgerufen werden, wenn die Resourcen
  unmittelbar freigegeben werden sollen.
• MSIL Microsoft Intermediate Language
• JIT Just in time
• Managed Code In der .NET Plattform wird kein
  nativer Code mehr erzeugt. Stattdessen generieren
  Compiler unter .NET eine Zwischensprache (MSIL),
  die dann unter Aufsicht der CLR bei Bedarf (JIT)
  in nativen Code übersetzt und ausgeführt wird.
  Deshalb wird der von den Compilern erzeugte Code
  auch Managed Code genannt.
• CFG-Datei Jede .NET Anwendung kann mit
  benutzerspezifischen Einstellungen versehen
  werden. Diese Einstellungen können in einer
  XML-Datei abgelegt sein, die sich im Verzeichnis
  der Anwendung befinden muss. Die Datei muß
  ausserdem die Endung CFG haben und den gleichen
  Namen wie die Anwendung besitzen (z.B.
  C\Test.EXE und C\Test.CFG).