Softwareentwicklung mit .NET
Teil 1
Was ist .NET?
Die .NET Common Language Runtime
Dr. Ralph Zeller
1
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.
2
Was gehört zu .NET?
PCs und
Smart
Devices
Benutzer-
sicht
Entwickler
Tools
VisualStudio.NET
Web .NET Framework
Services
Notification Identity
Infrastruktur
Enterprise Servers
3
.NET Design
Web 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) 4
.NET Plattform
Common Language Runtime
Framework & Tools Einheitliche Klassenbibliothek
Visual Studio.NET
Building Block Ständig verfügbare Internet-Dienste
Services (Code-Updates, Suchdienste, Messenger,
.NET My Services)
Heutige „2000-Produktfamilie“
Infrastruktur
(zukünftig .NET Enterprise Servers)
Mobile Geräte, auf denen .NET Anwendungen
Devices
laufen (Handy, Handheld)
5
Warum eine Runtime?
Einheitliches Integrationsmodell
Layer Layer
Sprach- (VBRUNxx.DLL) (VBRUNxx.DLL)
integration (MSVCRT.DLL) (MSVCRT.DLL)
Common
Microsoft
Kontext Language
Transaction
Concurrency Runtime
Server
Transaktionen (MSCOREE.DLL)
(MTXEX.DLL) COM+ Runtime (MSCORLIB.DLL)
(OLE32.DLL)
Class-Loader COM Runtime
Remoting (OLE32.DLL)
6
Warum ein Framework?
Einheitliches Programmiermodell
.NET Framework
VB Forms MFC & ATL ASP
Windows API
7
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
Configuration Net ServiceProcess InteropServices
Diagnostics Reflection Text Remoting
Globalization Resources Threading Serialization
8
Übersicht
VB C# C++
Compiler Compiler Compiler ASM Code
IL Code
Common Language Runtime
JIT Compiler Ngen
(Native Image Generator)
Betriebssystem
9
Basics
Managed Code
Sämtlicher Code wird unter Aufsicht der
Common Language Runtime ausgeführt
• Runtime führt Sicherheitsüberprüfungen aus
• Runtime übernimmt Speicherverwaltung und
Fehlerbehandlung ( GC, Exceptions)
• Runtime führt Versionsprüfungen aus
• Dieser Code wird mit Managed Code
bezeichnet
10
Basics
Microsoft Intermediate Language
Compiler erzeugen keinen native Code
sondern eine prozessorunabhängige
Zwischensprache
• MSIL – Microsoft Intermediate Language
• Sprachintegration erfolgt auf Ebene von
MSIL
11
Basics
Code wird kompiliert
IL-Code wird vor der Ausführung
immer (!) durch Compiler in echten
Maschinencode übersetzt
• Unabhängigkeit von Hardwareplattformen
• für Windows CE gibt es das Compact
Framework
12
Basics
Code wird kompiliert
Klasse A (1) Methodenaufruf
Methode 1 (ASM) Klasse B
Methode 2 (IL)
Methode (ASM)
Methode 1 1 (IL)
Methode 3 (IL)
Methode 2 (IL)
Methode 4 (IL)
(2) IL-Code
JIT Compiler durch native
Code ersetzen
13
JIT Compiler
Ngen.exe
Erzeugt aus IL Code ein Native
Executable
Output ist abhängig von
• CPU Typ
• Betriebssystemversion
• Exakte Identität des Assemblies
• Exakte Identität aller referenzierten
Assemblies
• Command-line Schaltern
14
Basics
Common 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
15
Basics
Implikationen
MSIL unterscheidet sich von „reinen“
Assemblersprachen
• komplexe Datentypen und Objekte sind
fester Bestandteil
• Konzepte wie Vererbung und Polymorphie
werden von vornherein unterstützt
16
Basics
Beispiel 1: „Hello World“ unter .NET
17
Basics
Implikationen
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 per„Definition“ interoperabel
18
Basics
Beispiel 2: Integration auf Codeebene
19
Common Type System
Das Objektmodell
Object Value Type Boolean
Int64
Byte
Enum SByte
Char
Typen im Single
Currency
Namespace Type TimeSpan
System DateTime
TypedRef.
String Decimal
UInt16
Double
Array UInt32
Guid
UInt64
Exception Int16
Void
Int32
Delegate 20
Common Type System
Beispiel 3: Boxing und Unboxing
21
Common Type System
Gleichheit 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
22
Common Type System
Attribute
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 !!!
23
Common Type System
Beispiel 4: Attribute
24
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
25
Metadaten und Reflection
Übersetzen von Sourcen
Source Code
Typ A {…} Compiler
Typ B {…} (C#, VB.NET, etc.)
Typ C {…}
Modul
MSIL-Code MSIL-Code MSIL-Code
für Typ A für Typ B für Typ C
Metadaten für die Typen A, B und C
26
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“
27
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
28
Metadaten und Reflection
Beispiel 5: Reflection
29
Assemblies
.NET Anwendungen bestehen aus
Assemblies
• Assembly = Komponente?
Ein Assembly ist ein Container für
Module
Sämtliche Sicherheits- und
Versionsüberprüfungen durch die CLR
erfolgen auf der Basis von Assemblies !!!
30
Assemblies
Übersetzen von Sourcen
Source Code
(app1.vb)
Typ A {…} Compiler
Typ B {…} (C#, VB.NET, etc.)
Typ C {…}
Assembly (app1.dll)
Modul
MSIL-Code MSIL-Code MSIL-Code
für Typ A für Typ B für Typ C
Manifest
Metadaten für die Typen A, B und C
31
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
32
Assemblies
Container für mehrere Module
Assembly (app1.dll)
Modul 1 (app2.dll) Modul 2 (app3.dll)
MSIL-Code MSIL-Code MSIL-Code MSIL-Code
für Typ D für Typ E für Typ F für Typ G
Manifest
Metadaten für D und E Metadaten für F und G
33
Assemblies
Manifest
Jedes Assembly enthält genau ein
Manifest
Das Manifest beschreibt das Assembly
• Keine Headerdateien
• Keine Typenbibliothek, o. ä.
34
Assemblies
Manifest
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
35
Assemblies
Kategorien
Private Assembly
• Assembly kann nur von genau einer
Anwendung benutzt werden
Shared Assemby
• Assembly kann global von allen
Anwendungen benutzt werden
36
Assemblies
Private Assembly
Identifikation anhand eines einfachen
Namens, z.B. “Stringer”
Keine Versionsüberprüfung
Installation per Filecopy
• Standardmäßig befinden sich Assembly
und Anwendung im gleichen Verzeichnis
• Verzeichnis kann per .config-Datei
definiert werden
37
Assemblies
Beispiel 6: Private Assembly
38
Assemblies
Shared 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. ä.
39
Assemblies
Shared Assembly - Strong Name
Eindeutigkeit des Namens wird mit
Hilfe der Public-Key-Verschlüsselung
hergestellt
• Strong Name = Identität + Public Key
• Attribut Originator im Manifest
40
Assemblies
Sign-Verfahren für Shared Assemblies
1. Keyfile erstellen ( sn.exe –k outf)
2. Im Sourcecode des Shared Assemblies
Attribut [assembly: AssemblyKeyFile()]
angeben
3. Beim Kompilieren des Shared Assemblies
wird der Public Key im Manifest eingetragen
4. Client, der das Assembly referenziert, erhält
beim Kompilieren eien Hashwert d. Public Key
( publickeytoken in seinem Manifest)
41
Assemblies
Shared Assembly zur Laufzeit laden
Client wird standardmäßig an die
Version des Shared Assemblies
gebunden, die in seinem Manifest
eingetragen ist
Dieses Verhalten kann per .config-Datei
überschrieben werden ( später)
42
Assemblies
Beispiel 7: Shared Assembly
43
Versionierung
Aufbau der Versionsnummer
44
Versionisierung
Inkompatibel
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
45
Versionisierung
Vielleicht kompatibel
Ein Shared Assembly kann kompatibel
zum Client sein, wenn sich die Revision
bei gleich bleibender Major- und Minor-
Version ändert
• Beispiel: Servicepack
• Runtime versucht, das Assembly mit der
höchsten Revisions- und Buildnummer zu
laden
46
Versionisierung
QFE – Quick Fix Engineering
Ein Shared Assembly ist grundsätzlich
kompatibel zum Client, wenn sich nur
die Buildnummer ändert
• In diesem Fall liegt ein sogenannter
Quick Fix Engineering (QFE) vor
• Beispiel: Security Hotfix
• Runtime versucht, das Assembly mit der
höchsten Revisions- und Buildnummer zu
laden
47
Versionierung
Vorgaben per .config-Datei definieren
48
Versionisierung
Vorgaben per .config-Datei definieren
Beispiel für die Option bindingRedirect
• 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
49
Versionisierung
Vorgaben per .config-Datei definieren
Option bindingRedirect – Client soll eine
ganz bestimmte Version eines Ass. laden
• Name
Name des Assemblies
• Originator
Public Key des Assemblies, um Eindeutigkeit zu
gewährleisten
• oldVersion
Version, die nicht geladen werden sollen
( ein Stern kennzeichnet alle Versionen)
• newVersion
Version des Assemblies, das geladen werden soll
50
Versionierung
Vorgaben per .config-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
51
Zusammenfassung
Sprachübergreifende Integration und
einheitliche Fehlerbehandlung ü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)
52
Fragen?
Uff...
53