1 softwareentwicklung mit.net teil 1 was ist.net? die.net common language runtime dr. ralph zeller...
TRANSCRIPT
1
Softwareentwicklung mit .NETTeil 1
Was ist .NET?Die .NET Common Language Runtime
Dr. Ralph ZellerDI. Wolfgang BeerMichael 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
Benutzer-Benutzer-sichtsicht
Web Web ServicesServices
PCs undPCs undSmartSmartDevicesDevices
InfrastrukturInfrastruktur
IdentityIdentityNotificationNotification
App
licat
ion
App
licat
ion
Cen
ter 2
000
Cen
ter 2
000
Biz
Talk
B
izTa
lk
Serv
er 2
000
Serv
er 2
000
Com
mer
ce
Com
mer
ce
Serv
er 2
000
Serv
er 2
000
Exch
ange
Ex
chan
ge
2000
2000
SQL
Serv
er
SQL
Serv
er
2000
2000
ISA
Ser
ver
ISA
Ser
ver
2000
2000
Mob
ile
Mob
ile
Info
rmat
ion
Info
rmat
ion
2001
Ser
ver
2001
Ser
ver
Hos
t H
ost
Inte
grat
ion
Inte
grat
ion
Serv
er 2
000
Serv
er 2
000
Enterprise ServersEnterprise Servers
VisualStudio.NETVisualStudio.NET.NET Framework.NET Framework
EntwicklerEntwicklerToolsTools
Was gehört zu .NET?
4
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)
.NET DesignWeb Services
5
.NET Plattform
Infrastruktur
Framework & Tools
Building Block Services
Common Language RuntimeEinheitliche KlassenbibliothekVisual Studio.NET
Ständig verfügbare Internet-Dienste(Code-Updates, Suchdienste, Messenger)
Heutige „2000-Produktfamilie“(zukünftig .NET Enterprise Servers)
DevicesMobile Geräte, auf denen .NET Anwendungenlaufen (Handy, Handheld)
6
Class-LoaderClass-LoaderRemotingRemoting
KontextKontextConcurrencyConcurrency
TransaktionenTransaktionen
Sprach-Sprach-IntegrationIntegration
Warum eine Runtime?Einheitliches Integrationsmodell
COM Runtime(OLE32.DLL)
Microsoft Transaction
Server(MTXEX.DLL)
Layer(VBRUNxx.DLL)(MSVCRT.DLL)
COM+ Runtime(OLE32.DLL)
Layer(VBRUNxx.DLL)(MSVCRT.DLL)
Common Language Runtime
(MSCOREE.DLL)(MSCORLIB.DLL)
7
.NET Framework
ASPVB Forms MFC & ATL
Windows API
Warum ein Framework?Einheitliches Programmiermodell
8
System
System.Data System.Xml
System.Web
Globalization
Diagnostics
Configuration
Collections
Resources
Reflection
Net
IO
Threading
Text
ServiceProcess
Security
Design
ADO
SQLTypes
SQL
XPath
XSLT
RuntimeInteropServices
Remoting
Serialization
Serialization
Configuration SessionState
Caching Security
ServicesDescription
Discovery
Protocols
UIHtmlControls
WebControls
System.Drawing
Imaging
Drawing2D
Text
Printing
System.WinForms
Design ComponentModel
Das .NET Framework
9
VB
Compiler ASM Code
Übersicht
C#
Compiler
IL Code
C++
Compiler
JIT Compiler
Common Language Runtime
Betriebssystem
10
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
BasicsManaged Code
11
Compiler erzeugen keinen native Code sondern eine prozessorunabhängige Zwischensprache
• Sprachintegration erfolgt auf Codeebene
• MSIL – Microsoft Intermediate Language
BasicsMicrosoft Intermediate Language
12
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
BasicsCode wird kompiliert
13
JIT Compiler
Klasse A
Methode 1 (IL)
Methode 2 (IL)
Methode 3 (IL)
Methode 4 (IL)
Klasse B
Methode 1 (IL)
Methode 2 (IL)
(1) Methodenaufruf
(2) IL-Codedurch native
Code ersetzen
Methode 1 (ASM)
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
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
BasicsCommon Type System
16
MSIL unterscheidet sich von „reinen“ Assemblersprachen
• komplexe Datentypen und Objekte sind fester Bestandteil
• Konzepte wie Vererbung und Polymorphie werden von vornherein unterstützt
BasicsImplikationen
17
BasicsBeispiel 1: „Hello World“ unter .NET
18
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
BasicsImplikationen
19
Basics Beispiel 2: Integration auf Codeebene
20
Object Value Type
Enum
Type
String
Array
Exception
Boolean
Byte
Char
Currency
DateTime
Decimal
Double
Guid
Int16
Int32
Int64
SByte
Single
TimeSpan
TypedRef.
UInt16
UInt32
UInt64
Void
Delegate
Typen imNamespaceSystem
Common Type SystemDas Objektmodell
21
Common Type SystemBeispiel 3: Boxing und Unboxing
22
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
Common Type SystemGleichheit und Identität von Objekten
23
Common Type SystemBeispiel 4: Delegates – Typisierte
Funktionszeiger
24
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 !!!
Common Type SystemAttribute
25
Common Type SystemBeispiel 5: Attribute
26
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
Bestandsaufnahme
27
Compiler
(C#, VB.NET, etc.)
Typ A {…}
Source Code
Typ B {…}
Typ C {…}
Metadaten für die Typen A, B und C
MSIL-Code für Typ A
MSIL-Code für Typ B
MSIL-Code für Typ C
Modul
Metadaten und ReflectionÜbersetzen von Sourcen
28
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“
Metadaten und Reflection
29
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
Metadaten und Reflection
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
Compiler
(C#, VB.NET, etc.)
Typ A {…}
Source Code
Typ B {…}
Typ C {…}
Metadaten für die Typen A, B und C
MSIL-Code für Typ A
MSIL-Code für Typ B
MSIL-Code für Typ C
Modul
(app1.vb)
Manifest
Assembly (app1.dll)
AssembliesÜbersetzen von Sourcen
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
Metadaten für D und E
Modul 1 (app2.dll)
Manifest
Assembly (app1.dll)
MSIL-Code für Typ D
MSIL-Code für Typ E
Metadaten für F und G
Modul 2 (app3.dll)
MSIL-Code für Typ F
MSIL-Code für Typ G
AssembliesContainer für mehrere Module
35
Jedes Assembly enthält genau ein Manifest
Das Manifest beschreibt das Assembly
• Keine Headerdateien
• Keine Typenbibliothek, o. ä.
AssembliesManifest
36
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
AssembliesManifest
37
Private Assembly
• Assembly kann nur von genau einer Anwendung benutzt werden
Shared Assemby
• Assembly kann global von allen Anwendungen benutzt werden
AssembliesKategorien
38
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
AssembliesPrivate Assembly
39
AssembliesBeispiel 7: Private Assembly
40
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. ä.
AssembliesShared Assembly
41
Eindeutigkeit des Names wird mit Hilfe der Public-Key-Verschlüsselung hergestellt
• Strong Name = Identität + Public Key
• Attribut Originator im Manifest
AssembliesShared Assembly - Strong Name
42
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)
AssembliesSign-Verfahren für Shared Assemblies
43
Client wird standardmäßig an die Version gebunden, die in seinem Manifest eingetragen ist
Dieses Verhalten kann per CFG-Datei überschrieben werden ( später)
AssembliesShared Assembly zur Laufzeit laden
44
AssembliesBeispiel 8: Shared Assembly
45
VersionierungAufbau der Versionsnummer
46
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
VersionierungIncompatible
47
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
VersionierungMaybe Compatible
48
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
VersionierungQFE – Quick Fix Engineering
49
VersionierungBeispiel 9: Standardvorgaben
50
<Configuration><BindingMode> <AppBindingMode Mode="safe"/> <!-- normal | safe --> </BindingMode></ Configuration>
<Configuration><BindingPolicy> <BindingRedir Name=“[Assembly Name]" Originator="[Public Key]" Version="*" VersionNew=“[Versionsnummer]" UseLatestBuildRevision=“no"/> <!-- no | yes --> </BindingPolicy></Configuration>
VersionierungVorgaben per CFG-Datei definieren
51
Option BindingMode <safe | normal>
• 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
VersionierungVorgaben per CFG-Datei definieren
52
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
VersionierungVorgaben per CFG-Datei definieren
53
Option BindingRedir – Client soll eine ganz bestimmte Version eines Assemblies laden• Name
Name 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
VersionierungVorgaben per CFG-Datei definieren
54
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
VersionierungVorgaben per CFG-Datei definieren
55
VersionierungBeispiel 10: Vorgaben per CFG-Datei
definieren
56
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)
Zusammenfassung
57
Fragen?
Uff...