1 Softwareentwicklung mit.NET Teil 1 Was ist.NET? Die.NET Common Language Runtime Dr. Ralph Zeller...

transcript

Softwareentwicklung mit .NETTeil 1

Was ist .NET?Die .NET Common Language Runtime

Dr. Ralph ZellerDI. Wolfgang BeerMichael Willers

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.

Benutzer-Benutzer-sichtsicht

Web Web ServicesServices

PCs undPCs undSmartSmartDevicesDevices

InfrastrukturInfrastruktur

IdentityIdentityNotificationNotification

Enterprise ServersEnterprise Servers

VisualStudio.NETVisualStudio.NET.NET Framework.NET Framework

EntwicklerEntwicklerToolsTools

Was gehört zu .NET?

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

.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)

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)

.NET Framework

ASPVB Forms MFC & ATL

Windows API

Warum ein Framework?Einheitliches Programmiermodell

System

System.Data System.Xml

System.Web

Globalization

Diagnostics

Configuration

Collections

Resources

Reflection

Threading

ServiceProcess

Security

Design

SQLTypes

RuntimeInteropServices

Remoting

Serialization

Configuration SessionState

Caching Security

ServicesDescription

Discovery

Protocols

UIHtmlControls

WebControls

System.Drawing

Imaging

Drawing2D

Printing

System.WinForms

Design ComponentModel

Das .NET Framework

Compiler ASM Code

Übersicht

Compiler

IL Code

Compiler

JIT Compiler

Common Language Runtime

Betriebssystem

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

Compiler erzeugen keinen native Code sondern eine prozessorunabhängige Zwischensprache

• Sprachintegration erfolgt auf Codeebene

• MSIL – Microsoft Intermediate Language

BasicsMicrosoft Intermediate Language

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

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

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 ;-)

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

MSIL unterscheidet sich von „reinen“ Assemblersprachen

• komplexe Datentypen und Objekte sind fester Bestandteil

• Konzepte wie Vererbung und Polymorphie werden von vornherein unterstützt

BasicsImplikationen

BasicsBeispiel 1: „Hello World“ unter .NET

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

Basics Beispiel 2: Integration auf Codeebene

Object Value Type

String

Exception

Boolean

Currency

DateTime

Decimal

Double

Single

TimeSpan

TypedRef.

UInt16

UInt32

UInt64

Delegate

Typen imNamespaceSystem

Common Type SystemDas Objektmodell

Common Type SystemBeispiel 3: Boxing und Unboxing

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

Common Type SystemBeispiel 4: Delegates – Typisierte

Funktionszeiger

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

Common Type SystemBeispiel 5: Attribute

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

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

Metadaten und ReflectionÜbersetzen von Sourcen

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

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

Metadaten und ReflectionBeispiel 6: Reflection

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 !!!

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

(app1.vb)

Manifest

Assembly (app1.dll)

AssembliesÜbersetzen von Sourcen

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

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

Jedes Assembly enthält genau ein Manifest

Das Manifest beschreibt das Assembly

• Keine Headerdateien

• Keine Typenbibliothek, o. ä.

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

AssembliesManifest

Private Assembly

• Assembly kann nur von genau einer Anwendung benutzt werden

Shared Assemby

• Assembly kann global von allen Anwendungen benutzt werden

AssembliesKategorien

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

AssembliesBeispiel 7: Private 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. ä.

AssembliesShared Assembly

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

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

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

AssembliesBeispiel 8: Shared Assembly

VersionierungAufbau der Versionsnummer

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

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

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

VersionierungBeispiel 9: Standardvorgaben

VersionierungVorgaben per CFG-Datei definieren

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

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

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

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

VersionierungBeispiel 10: Vorgaben per CFG-Datei

definieren

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

Fragen?

Uff...

1 Softwareentwicklung mit.NET Teil 1 Was ist.NET? Die.NET Common Language Runtime Dr. Ralph Zeller...

Documents