Transcript Was ist .NET? Die .NET Common Language Runtime

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
Benutzersicht
Entwickler
Tools
VisualStudio.NET
.NET Framework
Web
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
Framework & Tools
Building Block
Services
Infrastruktur
Devices
Common Language Runtime
Einheitliche Klassenbibliothek
Visual Studio.NET
Ständig verfügbare Internet-Dienste
(Code-Updates, Suchdienste, Messenger,
.NET My Services)
Heutige „2000-Produktfamilie“
(zukünftig .NET Enterprise Servers)
Mobile Geräte, auf denen .NET Anwendungen
laufen (Handy, Handheld)
5
Warum eine Runtime?
Einheitliches Integrationsmodell
Sprachintegration
Layer
(VBRUNxx.DLL)
(MSVCRT.DLL)
Kontext
Concurrency
Transaktionen
Microsoft
Transaction
Server
(MTXEX.DLL)
Class-Loader
Remoting
COM Runtime
(OLE32.DLL)
Layer
(VBRUNxx.DLL)
(MSVCRT.DLL)
COM+ Runtime
(OLE32.DLL)
Common
Language
Runtime
(MSCOREE.DLL)
(MSCORLIB.DLL)
6
Warum ein Framework?
Einheitliches Programmiermodell
.NET Framework
VB Forms
MFC & ATL
ASP
Windows API
7
Das .NET Framework
System.Web
Services
Description
UI
HtmlControls
Discovery
WebControls
System.WinForms
Design
Protocols
ComponentModel
System.Drawing
Caching
Security
Drawing2D
Printing
Configuration
SessionState
Imaging
Text
System.Data
System.Xml
ADO
SQL
XSLT
Design
SQLTypes
XPath
Serialization
System
Collections
IO
Security
Runtime
InteropServices
Configuration
Net
ServiceProcess
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)
Methode1 1(ASM)
(IL)
Methode
Methode 3 (IL)
Methode 2 (IL)
Methode 4 (IL)
JIT Compiler
(2) IL-Code
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
SByte
Enum
Typen im
Namespace
System
Char
Single
Type
Currency
TimeSpan
DateTime
String
TypedRef.
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
für Typ A
MSIL-Code
für Typ B
MSIL-Code
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
Manifest
MSIL-Code
für Typ A
MSIL-Code
für Typ B
MSIL-Code
für Typ C
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)
Manifest
MSIL-Code
für Typ D
MSIL-Code
für Typ E
Metadaten für D und E
Modul 2 (app3.dll)
MSIL-Code
für Typ F
MSIL-Code
für Typ G
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(<outf>)]
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 MinorVersion ä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
<configuration>
<startup>
<requiredRuntime version="v1.0.0.0"
safemode="true"/>
</startup>
</configuration>
<?xml version ="1.0"?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Reverser"
publicKeyToken="2c47419262627255"/>
<bindingRedirect oldVersion=„1.0.0.0"
newVersion=„2.0.0.0"/>
</dependentAssembly>
<probing privatePath="Reverse;String"/>
</assemblyBinding>
</runtime>
</configuration>
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