1 Softwareentwicklung mit.NET Teil 1 Was ist.NET? Die.NET Common Language Runtime Dr. Ralph Zeller DI. Wolfgang Beer Michael Willers.

Präsentation zum Thema: "1 Softwareentwicklung mit.NET Teil 1 Was ist.NET? Die.NET Common Language Runtime Dr. Ralph Zeller DI. Wolfgang Beer Michael Willers."—  Präsentation transkript:

1 1 Softwareentwicklung mit.NET Teil 1 Was ist.NET? Die.NET Common Language Runtime Dr. Ralph Zeller DI. Wolfgang Beer Michael Willers

2 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 3 Benutzer- sicht Web Services PCs und SmartDevices Infrastruktur Identity Notification Application Center 2000 BizTalk Server 2000 Commerce Server 2000 Exchange 2000 SQL Server 2000 ISA Server 2000 Mobile Information 2001 Server Host Integration Server 2000 Enterprise Servers VisualStudio.NET.NET Framework EntwicklerTools Was gehört zu.NET?

4 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 Design Web Services

5 5.NET Plattform Infrastruktur Framework & Tools Building Block Services Common Language Runtime Einheitliche Klassenbibliothek Visual Studio.NET Ständig verfügbare Internet-Dienste (Code-Updates, Suchdienste, Messenger) Heutige 2000-Produktfamilie (zukünftig.NET Enterprise Servers) Devices Mobile Geräte, auf denen.NET Anwendungen laufen (Handy, Handheld)

6 6 Class-LoaderRemoting KontextConcurrencyTransaktionenSprach-Integration 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 7.NET Framework ASPVB FormsMFC & ATL Windows API Warum ein Framework? Einheitliches Programmiermodell

8 8 System System.DataSystem.Xml System.Web Globalization Diagnostics Configuration Collections Resources Reflection Net IO Threading Text ServiceProcess Security Design ADO SQLTypes SQL XPath XSLT Runtime InteropServices Remoting Serialization ConfigurationSessionState CachingSecurity Services Description Discovery Protocols UI HtmlControls WebControls System.Drawing Imaging Drawing2D Text Printing System.WinForms DesignComponentModel Das.NET Framework

9 9 VB Compiler ASM Code Übersicht C# Compiler IL Code C++ Compiler JIT Compiler Common Language Runtime Betriebssystem

10 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 Basics Managed Code

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

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

13 13 JIT CompilerKlasse 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-Code durch native Code ersetzen Methode 1 (ASM) Basics Code wird kompiliert

14 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 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 Basics Common Type System

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

17 17 Basics Beispiel 1: Hello World unter.NET

18 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 perDefinition interoperabel Basics Implikationen

19 19 Basics Beispiel 2: Integration auf Codeebene

20 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 im Namespace System Common Type System Das Objektmodell

21 21 Common Type System Beispiel 3: Boxing und Unboxing

22 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 System Gleichheit und Identität von Objekten

23 23 Common Type System Beispiel 4: Delegates – Typisierte Funktionszeiger

24 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 System Attribute

25 25 Common Type System Beispiel 5: Attribute

26 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 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 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 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 30 Metadaten und Reflection Beispiel 6: Reflection

31 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 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 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 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 Assemblies Container für mehrere Module

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

36 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 Assemblies Manifest

37 37 Private Assembly Assembly kann nur von genau einer Anwendung benutzt werden Shared Assemby Assembly kann global von allen Anwendungen benutzt werden Assemblies Kategorien

38 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 Assemblies Private Assembly

39 39 Assemblies Beispiel 7: Private Assembly

40 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. ä. Assemblies Shared Assembly

41 41 Eindeutigkeit des Names wird mit Hilfe der Public-Key-Verschlüsselung hergestellt Strong Name = Identität + Public Key Attribut Originator im Manifest Assemblies Shared Assembly - Strong Name

42 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) Assemblies Sign-Verfahren für Shared Assemblies

43 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) Assemblies Shared Assembly zur Laufzeit laden

44 44 Assemblies Beispiel 8: Shared Assembly

45 45 Versionierung Aufbau der Versionsnummer

46 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 Versionierung Incompatible

47 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 Versionierung Maybe Compatible

48 48 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 Versionierung QFE – Quick Fix Engineering

49 49 Versionierung Beispiel 9: Standardvorgaben

50 50 <BindingRedir Name=[Assembly Name]" Originator="[Public Key]" Version="*" VersionNew=[Versionsnummer]" UseLatestBuildRevision=no"/> Versionierung Vorgaben per CFG-Datei definieren

51 51 Option BindingMode safe Runtime versucht die Assembly-Version zu laden, die im Client-Manifest eingetragen ist normal Runtime versucht, die Assembly-Version mit der höchsten Revision- und Buildnummer zu laden Versionierung Vorgaben per CFG-Datei definieren

52 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 Versionierung Vorgaben per CFG-Datei definieren

53 53 Option BindingRedir – Client soll eine ganz bestimmte Version eines Assemblies laden Name Name des Assemblies Originator Public Key des Assemblies, um Eindeutigkeit zu gewährleisten Version Version, die nicht geladen werden sollen ( ein Stern kennzeichnet alle Versionen) VersionNew Version des Assemblies, das geladen werden soll Versionierung Vorgaben per CFG-Datei definieren

54 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 Versionierung Vorgaben per CFG-Datei definieren

55 55 Versionierung Beispiel 10: Vorgaben per CFG-Datei definieren

56 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 57 Fragen? Uff...

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