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

1. Softwareentwicklung mit .NET Teil 1 Was ist .NET? Die .NET Common Language Runtime Dr. Ralph Zeller DI. Wolfgang Beer Michael 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. Was gehört zu .NET? Enterprise Servers PCs und Smart Devices Benutzer-sicht Entwickler Tools VisualStudio.NET .NET Framework Web Services Identity Notification Host Integration Server 2000 Mobile Information 2001 Server ISA Server 2000 SQL Server 2000 Exchange 2000 BizTalk Server 2000 Commerce Server 2000 Application Center 2000 Infrastruktur

4. .NET DesignWeb 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)

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

6. Sprach- Integration Kontext Concurrency Transaktionen Class-Loader Remoting Warum eine Runtime?Einheitliches Integrationsmodell Layer (VBRUNxx.DLL) (MSVCRT.DLL) Layer (VBRUNxx.DLL) (MSVCRT.DLL) Common Language Runtime (MSCOREE.DLL) (MSCORLIB.DLL) Microsoft Transaction Server (MTXEX.DLL) COM+ Runtime (OLE32.DLL) COM Runtime (OLE32.DLL)

7. .NET Framework Windows API ASP VB Forms MFC & ATL Warum ein Framework?Einheitliches Programmiermodell

8. 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 InteropServices Configuration Net ServiceProcess Remoting Diagnostics Reflection Text Serialization Globalization Resources Threading

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

10. BasicsManaged Code • 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

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

12. BasicsCode wird kompiliert • 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

13. Klasse A (1) Methodenaufruf Methode 1 (IL) Klasse B Methode 2 (IL) Methode 1 (IL) Methode 1 (ASM) Methode 3 (IL) Methode 2 (IL) Methode 4 (IL) JIT Compiler (2) IL-Code durch native Code ersetzen 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. BasicsCommon 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

16. BasicsImplikationen • MSIL unterscheidet sich von „reinen“ Assemblersprachen • komplexe Datentypen und Objekte sind fester Bestandteil • Konzepte wie Vererbung und Polymorphie werden von vornherein unterstützt

17. BasicsBeispiel 1:„Hello World“ unter .NET

18. BasicsImplikationen • 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

19. BasicsBeispiel 2:Integration auf Codeebene

20. Common Type SystemDas Objektmodell Object Value Type Boolean Int64 Byte Enum SByte Char Single Type Currency TimeSpan Typen im Namespace System DateTime String TypedRef. Decimal UInt16 Double Array UInt32 Guid UInt64 Exception Int16 Void Int32 Delegate

21. Common Type SystemBeispiel 3:Boxing und Unboxing

22. Common Type SystemGleichheit 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

23. Common Type SystemBeispiel 4:Delegates – Typisierte Funktionszeiger

24. Common Type SystemAttribute • 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 !!!

25. Common Type SystemBeispiel 5:Attribute

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

27. 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 Metadaten und ReflectionÜbersetzen von Sourcen Source Code Typ A {…} Compiler (C#, VB.NET, etc.) Typ B {…} Typ C {…}

28. 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“

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

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. Source Code (app1.vb) Typ A {…} Typ B {…} Typ C {…} Assembly (app1.dll) Modul MSIL-Code für Typ A MSIL-Code für Typ B MSIL-Code für Typ C Manifest Metadaten für die Typen A, B und C AssembliesÜbersetzen von Sourcen Compiler (C#, VB.NET, etc.)

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. Assembly (app1.dll) Modul 2 (app3.dll) Modul 1 (app2.dll) MSIL-Code für Typ F MSIL-Code für Typ G MSIL-Code für Typ D MSIL-Code für Typ E Manifest Metadaten für F und G Metadaten für D und E AssembliesContainer für mehrere Module

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

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

37. AssembliesKategorien • Private Assembly • Assembly kann nur von genau einer Anwendung benutzt werden • Shared Assemby • Assembly kann global von allen Anwendungen benutzt werden

38. AssembliesPrivate Assembly • 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

39. AssembliesBeispiel 7:Private Assembly

40. AssembliesShared 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. ä.

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

42. AssembliesSign-Verfahren für Shared Assemblies • Keyfile erstellen (à SDK-Tool sn.exe –k outf) • Compiler mit Keyfile und Versionsnummer aufrufen • Beim Erstellen des Assemblies wird der Public Key im Manifest eingetragen • Nach dem Erstellen wird das Modul, in dem sich das Manifest befindet, mit dem Private Key signiert • Client, der das Assembly referenziert, erhält beim Kompilieren den Public Key(à Attribut Originator in seinem Manifest)

43. AssembliesShared Assembly zur Laufzeit laden • Client wird standardmäßig an die Version gebunden, die in seinem Manifest eingetragen ist • Dieses Verhalten kann per CFG-Datei überschrieben werden (à später)

44. AssembliesBeispiel 8:Shared Assembly

45. VersionierungAufbau der Versionsnummer

46. VersionierungIncompatible • Ein Shared Assembly ist grundsätzlichinkompatibel zum Client, wenn sich die Major- oder Minor-Version ändert • Beispiel: neues Produktrelease • Runtime wirft eine Type Load Exception

47. VersionierungMaybe Compatible • 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

48. VersionierungQFE – Quick Fix Engineering • Ein Shared Assembly ist grundsätzlichkompatibel 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

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