Seminar: Komponentenorientierte Softwareentwicklung Prof. Dr. F. Thiesing

Transkript

1 Seminar: Komponentenorientierte Softwareentwicklung Prof. Dr. F. Thiesing Daniel Böhner Sebastian Heybach

2 Inhaltsverzeichnis Entstehung von.net... 3 CLR & MSIL... 6 XML und SOAP als Transportprotokolle CTS Ausführliche Übersicht über die.net-basistypen Datentypen und die Verarbeitung in IL Sprachübergreifende Vererbung in.net Referenz-/Werttypen und Boxing Delegates (typisierte Funktionszeiger) JIT-Kompilation Assemblies Namespaces in.net Die.NET-Klassenbibliothek Übersicht über die wichtigsten.net-namespaces Remoting NET-Sprachen C# Visual Basic.NET J# VC Andere.NET-Sprachen ADO.NET Aussicht in die Zukunft Quellenverzeichnis Seite 2 von 40

3 Entstehung von.net Die IT-Welt strebt seit ihrem Bestehen auf mehr Vereinheitlichung, Standardisierung und Komfortabilität. Während man sich in DOS-Zeiten z. B. mit der Anbindung der vielfältigen Druckermodelle für einzelne Anwendungsprogramme beschäftigen musste, wurde dies mit der Einführung von Windows 3.0 vereinfacht, indem dieses die Verwaltung von Druckertreibern, Mausunterstützung oder der Zwischenablage unter einer Benutzeroberfläche zusammengefasst hat. Diese Fortentwicklung auf einer höheren Stufe findet auf ähnliche Weise mit.net statt, nämlich die Zusammenfassung vieler Funktionen in ein Software-Paket..NET firmierte während seiner Entwicklungsphase auch unter dem Namen NGWS (Next Generation Windows Services), sowie unter COM 2.0. Aber nicht nur die Software hat sich innerhalb der vielen Jahre verändert, sondern auch die Ziele und Strategien. Das Ziel von Microsoft, dass alle Anwender mit Hilfe von Microsoft-Programmen auf ihre Daten zugreifen, konnte Mitte der 90er Jahre mit der großen Verbreitung von Desktop-PCs mit Windows als Betriebssystem bis auf wenige Ausnahmen als erfüllt betrachtet werden. Mit der beginnenden weltweiten Vernetzung mussten diese Ziele verändert werden. Applikationen müssen nun nicht mehr zwingenderweise monolithisch auf Rich Clients (PCs mit hoher Prozessorleistung, viel Arbeitsspeicher und Plattenspeicher) oder in einem lokalen Netzwerk laufen, sondern können serverseitig betrieben werden und der Zugriff darauf kann mit so genannten Thin Clients durchgeführt werden. Hierdurch bietet sich die Möglichkeit, Software auf völlig neue Weise zu vermarkten. Sie wird in Zukunft nicht mehr nur als Ware an Kunden verkauft, vielmehr kann Software als Dienstleistung angeboten werden. Die Abrechnung kann somit bei Gebrauch, nach Dauer, Umfang, Nutzungsfrequenz oder über ein Abonnement erfolgen. Dieses Marketingkonzept wird auch Outsourcing von Funktionalität genannt. Dabei ist es nicht erforderlich, ganze Softwarepakete anzubieten, da es genügt, einzelne Softwarekomponenten zur Verfügung zu stellen. Es entsteht für viele Firmen der Vorteil, Softwarekosten (TCO=Total Cost of Ownership) zu senken, da serverseitig betriebene Software besser wartbar, und die benötigte Hardware billiger ist als teure Desktop-PCs. Heutzutage ist es noch üblich, dass Internetdienstleistungen eher direkt auf den Menschen zugeschnitten sind, wie z. B. HTML-basierte Internetpräsenzen, deren Informationen nicht für maschinelle Weiterverarbeitung gedacht sind. Selten greifen Programme über das Internet auf Dienstleistungen anderer Programme zu. So wäre es doch denkbar, dass eine Buchhaltungssoftware auf eine Softwarekomponente zur Wechselkursberechnung zugreift, die an einem beliebigen Ort der Welt durch einen Internetserver zur Verfügung gestellt wird. Aber nicht nur die Vernetzung, sondern auch die Entwicklung von kleinerer und leistungsfähigerer Hardware, wie PDAs (Personal Digital Assistants), Handhelds, eingebettete Systeme (z. B. Computer in Videorecordern) und Handys mit Softwareaustattung führten zu einer Schwächung von Desktop-PCs. Als Lösung Seite 3 von 40

4 hierfür ergibt sich der Aspekt der Plattformunabhängigkeit. Eine immer breiter werdende Hardwarelandschaft erfordert eine einheitliche Programmierschnittstelle, um Software mit geringem Aufwand entwickeln zu können. Dieses Konzept der Interoperabilität hat Sun bereits mit Java begonnen. Das Hauptaugenmerk bei Microsoft liegt jedoch bei der Sprachunabhängigkeit von.net. Das bedeutet, dass Programmiersprachen, die sich an gewisse Konventionen halten, auf.net aufsetzen können. Neben den veränderten Hardwarebedingungen bereiteten Microsoft die bisherigen Software-Technologien wie die Win32 API, COM oder ASP Probleme. Aufgrund der ständigen Weiterentwicklung und Einführung von Neuerungen in alte Systeme mit der dazu gehörigen Abwärtskompatibilität wurden diese immer komplexer und undurchschaubarer. Gerade die Win32 API ist so komplex geworden, dass selbst die Entwickler kein einheitliches System mehr verfolgen und jedes Subsystem mit einer anderen Philosophie realisiert ist. Z. B. beginnen die API-Funktionen für die Windows-Registry alle mit dem Präfix Reg, und als Rückgabe haben sie eine Fehlernummer. Die API-Funktionen des Windows-Kernels hingegen haben keine erkennbaren Namen und liefern keine Rückgabe, sondern erwarten, dass man diese mit GetLastError abfragt wurde mit COM (Component Object Model) versucht Abhilfe zu schaffen. Man kapselte Low-Level-Funktionen der Win32 API in COM-Objekte. Aber dadurch, dass nicht alle API-Funktionen in COM gekapselt wurden, blieb die Uneinheitlichkeit vorhanden. Die Komplexität hat aufgrund einer komplizierten COM-Umsetzung auch nicht sonderlich abgenommen. Weitere Entwicklungen wie DCOM oder COM+ haben eine Fülle von Funktionen hinzugefügt, führten jedoch dazu, dass Entwickler viel Zeit aufbringen mussten sich in die neuen Technologien einzuarbeiten. Komplexität API DDE COM OLE Automation OCX ActiveX DCOM COM+.NET Zeit Quelle: Crashkurs.NET für Delphianer Seite 4 von 40

5 Aus diesen Problemen und Erfahrungen heraus entschloss sich Microsoft eine neue Technologie zu entwickeln. An diese Technologie wurden einige Anforderungen gestellt, um in einer vernetzten, heterogenen Hard- und Softwarewelt langfristig erfolgreich zu sein..net ist also die Antwort Microsofts auf den Wechsel von einer produktorientierten Desktop-Softwarewelt in eine dienstleistungsorientierte Internetkomponentenwelt mit der Öffnung gegenüber einer Vielzahl von Hardware- bzw. Betriebssystemplattformen. Seite 5 von 40

6 CLR & MSIL Die Idee idealer Plattformen ist unter anderem bereits in Hochsprachen wie C, C++, Pascal, Visual Basic aufgegriffen worden. Sie abstrahieren von den zugrunde liegenden Maschinensprachen, was eine gewisse Unabhängigkeit gegenüber konkreter Technik auf niedriger Ebene zur Folge hat. Ein Compiler übernimmt dann die Aufgabe, das Programm in den notwendigen Maschinencode zu übersetzen. Damit erfolgt jedoch wieder die Bindung an konkrete Hardware. So muss es für jeden Maschinentyp, auf dem das Programm ausgeführt werden soll, einen speziell dafür ausgelegten Compiler geben. Solche Sprachen haben also das Problem der Maschinenabhängigkeit vom Quellcode zum Compiler verlagert. Eine weitere Abstraktionsstufe beschreiben die virtuellen Maschinen. Dabei erzeugt der Compiler Code, der nicht hardwaregebunden ist, sondern der Maschinensprache der virtuellen Maschine entspricht. Meist führt ein Interpreter die virtuellen Maschinenanweisungen Schritt für Schritt mit den Befehlen der zugrunde liegenden Hardware aus. Auf Grund der geringen Größe dieser Interpreter sind sie leicht auf andere Plattformen zu portieren. Somit ist der Code, der der virtuellen Maschine entspricht, auf allen Plattformen ausführbar, für die solch ein Interpreter existiert. Viele objektorientierte Programmiersprachen bilden noch eine Abstraktionsschicht zwischen sich und dem Betriebssystem, welches alle Hardwarefunktionen, Speicherverwaltung etc. kapselt, die so genannte Runtime. In dieser Runtime sind meistens die Interpreter für die Virtuelle Maschine implementiert. Sie stellt zusätzliche Dienste zur Verfügung, wie eigene Speicherverwaltungen und Funktionsbibliotheken. In.NET heißt diese Runtime CLR (Common Language Runtime). Die CLR ist im Gegensatz zu anderen Runtimes sehr viel komplexer. Sie bietet viele Dienste, wie z. B. die Codeverifizierung und Codeoptimierung, die Garbage Collection und kann mit dem Code sämtlicher.net Sprachen umgehen. Daher ist auch der Begriff Common Language Runtime und nicht z. B..NET Runtime gewählt worden, um zu zeigen, dass die Runtime für eine Vielzahl von Programmiersprachen gültig ist, eben Common. Als bekannte Sprachen wären hier zu nennen: Prozedurale Sprachen: - Pascal Objektorientierte Sprachen: - Smalltalk - Eiffel - C# - VB.NET - J# - Jscript.NET - Delphi for.net Seite 6 von 40

7 Funktionale Sprachen: - ML - Haskell Eine tiefergreifende Beschreibung einiger wichtiger.net-sprachen wird im dazu gehörigen Abschnitt behandelt. Durch die Kompilation werden.net-sprachen in einen Zwischencode umgewandelt, den so genannten MSIL (Microsoft Intermediate Language), kurz auch IL genannt. Die IL ist im Gegensatz zum Java Byte Code nicht für die Interpretation ausgelegt. Die CLR übernimmt nach der Kompilation die Aufgabe, diesen Zwischencode in prozessorspezifischen Maschinencode (auch Native Code genannt) umzuwandeln. Da die CLR immer den Zwischencode erhält, kann sie nicht zwischen den verschiedenen.net-sprachen unterscheiden, man spricht auch von Sprachintegration. Beispiel Hello World in C# using System; namespace HelloWorld_in_C_Sharp class HelloWorld [STAThread] static void Main(string[] args) System.Console.WriteLine("Hello World"); Zugehöriger MSIL-Code.method private hidebysig static void Main(string[] args) cil managed.entrypoint.custom instance void [mscorlib]system.stathreadattribute::.ctor() = ( ) // Codegröße 11 (0xb).maxstack 1 IL_0000: ldstr "Hello World" IL_0005: call void [mscorlib]system.console::writeline(string) IL_000a: ret // end of method HelloWorld::Main Seite 7 von 40

8 Beispiel Hello World in VB.NET Module Module1 Sub Main() Console.WriteLine("Hello World") End Sub End Module Zugehöriger MSIL Code.method public static void Main() cil managed.entrypoint.custom instance void [mscorlib]system.stathreadattribute::.ctor() = ( ) // Codegröße 14 (0xe).maxstack 8 IL_0000: nop IL_0001: ldstr "Hello World" IL_0006: call void [mscorlib]system.console::writeline(string) IL_000b: nop IL_000c: nop IL_000d: ret // end of method Module1::Main Diese MSIL-Codeauszüge liefert das Tool ildasm.exe, welches dem.net SDK beiliegt. Der IL-Code liegt natürlich nicht im Textformat vor, sondern als Binärcode. Mit Hilfe des IL-Disassemblers ildasm.exe kann dieser in eine für Menschen lesbare Form gebracht werden. Dies bringt aber auch den Nachteil mit, dass die die Programmlogik von bereitgestellten kompilierten Komponenten leichter zu entschlüsseln ist. Um dies zu verhindern, werden einige Sicherheitsdienste bereitgestellt. Seite 8 von 40

9 Compiler und Lader Codeverifizierung und -optimierung Speicherverwaltung und Garbage Collection Codezugriffssicherheit (weitere Dienste für verwalteten Code) Die CLR (Common Language Runtime) Quelle: ASP.NET und die.net-plattform In IL vorliegende Programme enthalten zusätzliche Informationen über ihre Klassen und die Komponenten, die für ihren Ablauf benötigt werden. Die Metadaten, die im so genannten Manifest enthalten sind, sorgen dafür, dass die CLR Anwendungen daran hindern kann, falsche Versionen einer Komponente zu verwenden. Es können aber gleichzeitig mehrere Versionen einer Komponente geladen werden. Das heißt, eine korrekte Version einer Komponente kann parallel einer Anwendung zur Verfügung stehen, während man Aktualisierungen vornimmt. Seite 9 von 40

10 XML und SOAP als Transportprotokolle Bei der Kommunikation zweier stark entkoppelter Systeme, eventuell sogar mit unterschiedlichen Sprachen implementiert, müssen sich beide auf eine gemeinsame Datenbasis einigen. Hierbei findet XML (Extensible Markup Language) eine immer stärkere Verbreitung. XML transportiert Daten in lesbaren Zeichenketten, die der Sender aus internen Daten aufbereitet und der Empfänger in interne Daten verwandelt. Nach der Festlegung der Darstellung muss aber ebenfalls eine einheitliche Struktur implementiert werden, da der Empfänger erkennen muss, wo eine Information aufhört und die nächste beginnt. Hierfür wird in XML eine geschachtelte Struktur verwendet, ähnlich wie in HTML. Mit Hilfe von Eröffnungsklammern und Schließungsklammern können den gesendeten Informationen Metadaten mitgegeben werden. Eine eröffnende, benannte Klammer könnte so aussehen: <name>, analog dazu die Schließende: </name>. Hier ein kleines Beispiel für einen XML-Datensatz: <seminar> <name>komponentenorientierte Softwareentwicklung</name> <dozent>prof. Dr. Frank Thiesing</dozent> <wochentag>dienstag</wochentag> <raum>a.2.03</raum> </seminar> Mit XML wird jedoch nur die Darstellung sowie die Struktur definiert, man benötigt aber auch ein XML-basiertes Datenformat für WebService-Aufrufe. Hierfür hat ein Konsortium aus mehreren Firmen und Institutionen, in dem Microsoft ebenfalls Mitglied war, ein Datenformat namens SOAP vorgeschlagen. SOAP ist die Abkürzung für Simple Object Access Protocol. SOAP ist zwar noch kein Standard wie XML, findet aber inzwischen eine relativ starke Verbreitung. SOAP definiert, wie ein Methodenaufruf mit Endpunkt, Methodenname und Parametern, sowie ein eventuelles Resultat in XML zu übersetzen ist. Eine SOAP-Nachricht besteht aus zwei Teilen, einem Umschlag (Envelope) und den zu transportierenden Daten (Body). Der Envelope dient als Träger von Angaben über den oder die Empfänger und als Behälter für den Body. Seite 10 von 40

11 Beispiel für eine SOAP-Nachricht: POST /AktienAbfrage.asmx HTTP/1.1 Host: Content-Type: text/xml; charset=utf-8 Content-Length:... SOAPAction:... <?xml version="1.0" encoding="utf-8"?> <soap:envelope...> <soap:body> <GetKurs...> <WKN>870747</WKN> <Datum> </Datum> </GetKurs> </soap:body> </soap:envelope> Als Transportmedium für WebService-Aufrufe dient das Hypertext Transfer Protocol (HTTP). SOAP stellt damit eine Einigung auf den kleinsten gemeinsamen Nenner zwischen stark entkoppelten Systemen dar. Aber SOAP ist keine Komplettlösung, da nicht über alles eine Einigung erzielt wurde. Insofern hatte Sun mit seiner Strategie Recht: Wenn alle Entwickler dieselbe Programmiersprache benutzten, wäre es viel leichter, Code in verschiedenen Komponenten zusammenarbeiten zu lassen. Das betrifft die Laufzeit wie auch die Übersetzungs- beziehungsweise Entwicklungszeit. Seite 11 von 40

12 CTS Bisher war es so, dass jede Programmiersprache ihre eigenen Datentypen definiert hat. Z. B. besitzt jeder String in Delphi ein vorangestelltes Längenbyte, während in C/C++ jeder String mit einem speziellen, abschließenden ASCII-Zeichen endet, dem 0-Byte. Dieses Problem wollte Sun mit seiner Programmiersprache Java so lösen, dass jeder Entwickler auf jeder Plattform mit Java programmieren sollte, womit es keine Interoperabilitätsprobleme mehr gäbe. Sun vertritt die Philosophie der sprachlichen Monokultur. Diese Strategie ist jedoch aufgrund der Pluralität des Marktes nicht geglückt. Bis heute werden die meisten Programme in Visual Basic und C++ entwickelt. Microsoft hatte zu Anfang der 90er Jahre den Nutzen und die Unumgänglichkeit von programmiersprachlicher Pluralität erkannt, da für jedes Problem eine Programmiersprache durchaus geeigneter sein kann als eine andere. Z. B. werden mathematische Berechnungen aufgrund von höherer Genauigkeit und Geschwindigkeit besser mit C/C++ als mit Java durchgeführt. Eine weitere Strategie, um Interoperabilität mit verschiedenen Programmiersprachen zu erreichen ist es, ein allgemeingültiges Typsystem zu entwickeln, was Microsoft in.net verwirklicht hat. Unter Typsystem versteht man die Menge aller Datenstrukturen. Wie obiges Beispiel mit Strings in C/C++ und Delphi zeigt, besitzen die meisten Programmiersprachen unterschiedliche Typsysteme. Zu den Typsystemen einer Programmiersprache zählen sowohl primitive Typen (z. B. Ganzzahlen, gebrochene Zahlen oder Wahrheitswerte), sowie komplexe Datentypen (z. B. struct in C/C++, record in Pascal bzw. type in Visual Basic, Felder und Klassen). Bisher gab es also zwei Möglichkeiten, Interoperabilität zu realisieren, entweder man bringt alle Entwickler dazu, das Typsystem ein und derselben Hochsprache zu benutzen (Sun-Strategie mit Java), oder man setzt ein darüberliegendes, unabhängiges Typsystem, wie SOAP ein. Microsoft geht hier einen neuen Weg und hat das CTS (Common Type System) entwickelt..net- Programmiersprachen haben also nicht jede für sich ein eigenes Typsystem, sondern sie implementieren alle dasselbe Typsystem, beziehungsweise eine Untermenge hieraus die CLS (Common Language Specification). Die CLS definiert einen Grundstamm an Typen, die jede.net-sprache unterstützt. Darüber hinaus können die Sprachen aber auch weitere Typen unterstützen die CTS-konform sind, jedoch kann der erzeugte IL-Code dann nicht von anderen Sprachen verarbeitet werden. Visual Basic z. B. ist eine reine CLS-Sprache, C# unterstützt jedoch das gesamte CTS (z. B. vorzeichenlose Ganzzahlen und den Typ SByte, die nicht im CLS enthalten sind). Eine Übersicht über die.net Datentypen und ihre CLS- Konformität liefert unten stehende Tabelle. Seite 12 von 40

13 Ausführliche Übersicht über die.net-basistypen Datentypname System.Byte System.SByte System.Int16 System.Int32 System.Int64 System.UInt16 System.UInt32 System.UInt64 System.Single System.Double System.Object System.Char System.String System.Decimal System.Boolean Länge in Bit Wertebereich 0 bis bis bis bis bis bis bis bis e38 bis e e308 bis e308 beliebig Unicode-Zeichen bis zu 2 Mrd. Unicode-Zeichen bis True (1 oder -1)/False (0) Name in MSIL unsigned int8 int8 int16 int32 int64 unsigned int16 unsigned int32 unsigned int64 float32 float64 class System.Object wchar class System.String decimal bool Name in VB.NET Byte - Short Integer Long Single Double Object Char String Decimal Boolean Name in C# byte sbyte short int long ushort uint ulong float double object char string decimal bool CLS- Typ ja nein ja ja ja nein nein nein ja ja ja ja ja ja ja Seite 13 von 40

14 Datentypen und die Verarbeitung in IL CLS-Typen, die in den verschiedenen.net-sprachen noch einen anderen Namen besitzen, werden im IL-Code unter demselben Namen geführt (fettgedruckter Text), was folgendes Beispiel zeigt. Datentypen in C# using System; namespace Typisierung_in_C_Sharp class Class1 [STAThread] static void Main(string[] args) byte bytetyp; short shorttyp; int inttyp; long longtyp; float floattyp; double doubletyp; object objecttyp; char chartyp; string stringtyp; decimal decimaltyp; bool booltyp; Zugehöriger MSIL-Code.method private hidebysig static void Main(string[] args) cil managed.entrypoint.custom instance void [mscorlib]system.stathreadattribute::.ctor() = ( ) // Codegröße 2 (0x2).maxstack 0.locals init ([0] unsigned int8 bytetyp, [1] int16 shorttyp, [2] int32 inttyp, [3] int64 longtyp, [4] float32 floattyp, [5] float64 doubletyp, [6] object objecttyp, [7] char chartyp, [8] string stringtyp, [9] valuetype [mscorlib]system.decimal decimaltyp, [10] bool booltyp) IL_0000: nop IL_0001: ret // end of method Class1::Main Seite 14 von 40

15 Datentypen in VB.NET Module Module1 Sub Main() Dim ByteTyp As Byte Dim ShortTyp As Short Dim IntegerTyp As Integer Dim LongTyp As Long Dim SingleTyp As Single Dim DoubleTyp As Double Dim ObjectTyp As Object Dim CharTyp As Char Dim StringTyp As String Dim DecimalTyp As Decimal Dim BooleanTyp As Boolean End Sub End Module Zugehöriger MSIL-Code.method public static void Main() cil managed.entrypoint.custom instance void [mscorlib]system.stathreadattribute::.ctor() = ( ) // Codegröße 3 (0x3).maxstack 0.locals init ([0] bool BooleanTyp, [1] unsigned int8 ByteTyp, [2] char CharTyp, [3] valuetype [mscorlib]system.decimal DecimalTyp, [4] float64 DoubleTyp, [5] int32 IntegerTyp, [6] int64 LongTyp, [7] object ObjectTyp, [8] int16 ShortTyp, [9] float32 SingleTyp, [10] string StringTyp) IL_0000: nop IL_0001: nop IL_0002: ret // end of method Module1::Main Sprachübergreifende Vererbung in.net Aus dieser Entwicklung heraus, dass.net-sprachen auf die gleichen Typen zugreifen, ergibt sich die Möglichkeit, dass beispielsweise C# uneingeschränkt VB.NET-Objekte benutzen kann. Aber das CTS geht noch weiter: Nicht nur die Interoperabilität zur Laufzeit ist gegeben, sondern auch die zur Entwicklungszeit. Eine C#-Klasse kann über Komponentengrenzen hinweg beispielsweise von einer VB.NET Klasse abgeleitet werden. Dazu ist zu sagen, dass im CTS keine Mehrfachvererbung möglich ist. Seite 15 von 40

16 Beispiel für eine sprachübergreifende Vererbung Hier erbt die Klasse Mitarbeiter einer C#-Anwendung von der Klasse Person einer VB.NET-Klasse. VB.NET-Klasse: Public Class PersonVBNET Public Dim Name as String End Class C#-Klasse using System; class Mitarbeiter : PersonVBNET public int Gehalt; static void Main(string[] args) Mitarbeiter M=new Mitarbeiter(); M.Name="Dieter Müller"; M.Gehalt=85000; Console.WriteLine(M.Name + " verdient " + M.Gehalt + " Euro/Jahr"); Console.ReadLine(); Referenz-/Werttypen und Boxing.NET ist ohne Einschränkung objektorientiert. Dies gilt auch für die sonst als primitiv bezeichneten Typen, als da wären integer, boolean, byte, char etc.. Alle Datentypen in.net werden von System.Object abgeleitet und sind damit eigentlich Referenztypen. Allgemein bekannt ist aber, dass Werttypen in ihrer Behandlung performanter sind, da keine Dereferenzierung stattfinden muss. Aus diesem Grund unterscheidet das CTS zwischen Referenz- und Werttypen. Diese Werttypen erben im Gegensatz zu den Referenztypen nur indirekt von System.Object, da sie von System.ValueType abgeleitet sind. Dazu zählen die oben genannten Primitivtypen, sowie Strukturen (ähnlich wie in C/C++ struct oder in Pascal record) und Aufzählungstypen (Enumerationen). Die CLR behandelt diese gesondert. Sie werden auf dem Stack oder innerhalb von Referenztypen auf dem Heap abgelegt, was folgendes Bild zeigt. Seite 16 von 40

17 struct Artikel int Nummer; float Preis; class Kunde int Nummer; Artikel letzterartikel;... int j; j = 2004; Artikel a; a.nummer = 999; a.float = 13.5; Kunde k; k.nummer = 43; k.letzterartikel.nummer = 998; k.letzterartikel.preis = 18.99; j a k Stack Heap Die Werttypen werden aber genauso wie die Referenztypen objektorientiert behandelt. Dadurch werden folgende C#-Codezeilen möglich, die ungewöhnlich scheinen, da sie in verbreiteten Sprachen wie Java, C/C++ oder Pascal nicht denkbar wären. Console.WriteLine( ToString()); oder int i; i. Seite 17 von 40

18 Trotzdem gibt es die Möglichkeit, Werttypen als Referenztypen zu behandeln. Durch die Erzwingung, wandelt die CLR ihn in einen Referenztypen um, diese Technik wird Boxing genannt. Vergleichbar ist dies mit den Java-Wrapperklassen. In C# würde das Boxing wie folgt aussehen: Stack Heap int i = 77; object o; o = i; Delegates (typisierte Funktionszeiger) Ein weiteres Feature, welches das CTS beinhaltet, sind die typisierten Funktionszeiger. Bisher, in C/C++, war es so, dass es für Funktionszeiger keine Kontrolle gab, ob sie auf eine richtige Stelle verweisen, also wirklich auf eine Routine, die die richtigen Parameter und den richtigen Rückgabewert hat. Im.NET- CTS ist dies durch so genannte Delegates gelöst, also typisierte Funktionszeiger. Seite 18 von 40

19 Beispiel für Delegates using System; class Delegates delegate bool vergleich(int a, int b); static bool vergleichlaenge(int a, int b) return a.tostring().length > b.tostring().length; static bool vergleichgroesse(int a, int b) return a > b; static void bubblesort(int[] zahlen, int max, vergleich v) bool ok = false; while (!ok) ok = true; for (int i=0; i<max; i++) if (v(zahlen[i], zahlen[i+1])) int temp = zahlen[i]; zahlen[i] = zahlen[i+1]; zahlen[i+1] = temp; ok = false; static void Main(string[] args) int[] a = new int[] 9, 10, 19, 256, -2786; bubblesort(a, 4, new vergleich(vergleichlaenge)); System.Console.WriteLine("Nach Länge sortiert:"); for (int i=0; i<=4; i++) System.Console.WriteLine(a[i].ToString()); System.Console.WriteLine(); bubblesort(a, 4, new vergleich(vergleichgroesse)); System.Console.WriteLine("Nach Größe sortiert:"); for (int i=0; i<=4; i++) System.Console.WriteLine(a[i].ToString()); System.Console.ReadLine(); Seite 19 von 40

20 Mit delegate wird ein neuer typisierter Funktionszeiger definiert. Der Methode bubblesort wird ein neu instantiierter Delegate übergeben, im obigen Beispiel entweder vergleichlaenge oder vergleichgroesse. Es lassen sich hier jedoch nur Funktionen übergeben, die der definierten Delegate-Anweisung entsprechen, diese Kontrolle macht die Bezeichnung typisiert aus. Einer Delegate-Variablen können auch mehrere Funktionen zugewiesen werden, was Grundlage der.net-ereignisverarbeitung ist. Es werden alle zugewiesenen Funktionen ausgeführt, wenn die Delegate-Variable aufgerufen wird. Beispiel für Mehrfachzuweisung an Delegate-Variablen delegate void OnClickHandler(object eventsource); OnClickHandler clickevent; void button1_onclick(object eventsource)... void textbox1_onclick(object eventsource) clickevent += new OnClickHandler(button1_OnClick); clickevent += new OnClickHandler(textbox1_OnClick); clickevent(this); Seite 20 von 40

21 JIT-Kompilation Die endgültige Übersetzung eines Hochsprachenprogramms in Maschinencode findet nicht auf dem System des Entwicklers statt, sondern auf dem des Anwenders. Hier gibt es zwei Möglichkeiten, wann der IL-Code auf der Zielplattform übersetzt wird: - bei der Installation, auch PreJIT genannt - beim Aufruf (just in time, JIT) Die Standardeinstellung ist JIT, wobei hier auch noch zwei Varianten existieren, das EconoJIT und das (Standard-)JIT. EconoJIT ist dafür ausgelegt, IL-Code schnellstmöglich in Maschinenbefehle umzuwandeln, während (Standard-)JIT die beste Codeoptimierung umsetzt. Der Einwand, dass jeder Programmstart bei JIT zu einer Verzögerung führt, scheint zunächst berechtigt zu sein. Bei genauerer Betrachtung der Umsetzung in.net wird man feststellen, dass dies kaum ins Gewicht fällt. Die Kompilation wird schrittweise ausgeführt, jedoch nicht nach benötigten Dateien, sondern eine Schicht tiefer nach benötigten Methoden. Auch die hohe Geschwindigkeit einer JIT-Kompilation von mehreren Megabyte pro Sekunde sorgt dafür, dass kaum Verzögerungen auftreten. Die JIT-Kompilation sorgt für weitere Vorteile, als da wären, z. B. die Sicherheitsaspekte und die Codeoptimierierung. Was die Sicherheit angeht, kann auf der Zielplattform eine Prüfung des IL-Codes anhand der vorhandenen Metainformationen vorgenommen werden. Dieses Konzept, der Prüfung und Verwaltung des Codes durch eine Kontrollinstanz wird Managed Code genannt. Sobald der IL-Code in Maschinencode umgewandelt wurde, unterliegt er nicht mehr der Kontrolle der CLR, daher bietet die JIT-Kompilation gerade für Komponenten, die nicht 100% vertrauenswürdig sind, das größte Sicherheitspotenzial. Die CLR kontrolliert mit jeder JIT-Kompilation den angemeldeten Benutzer, sowie die Version von aufgerufenen Komponenten. Mit anderen Worten, eine Kompilation bei der Installation führt zwar zu einem geringen Performance-Gewinn, sorgt aber für eine Erhöhung des Sicherheitsrisikos. Bei einer Vielzahl von Komponenten sind die Quelle, das Ziel sowie die Laufzeitumgebung unbekannt, daher sind die Sicherheit und die Korrektheit des Codes ungemein wichtig. Die Codeoptimierung kann mithilfe der JIT-Kompilation für jede Zielplattform geschehen. So kann für jeden speziellen Prozessor, mathematischen Coprozessor oder die Registerverwendung eine Optimierung vorgenommen werden. Man kann sich nun die Frage stellen, warum geht Microsoft nicht den UNIX-Weg und liefert einen Compiler (bei UNIX C-Compiler) und alle Software Pakete in dem dazugehörigen Quellcode (bei UNIX in C), damit er dann auf dem Zielsystem kompiliert werden kann. Als erstes würde OpenSource nicht dem Microsoft- Verkaufsprinzip entsprechen. Weiterhin legt Microsoft eindeutig Wert auf die JIT- Kompilation, diese würde aber bei einer reinen Hochsprache zu deutlichen Performance-Einbrüchen führen. Und ein reiner Hochsprachen-Compiler ist schwerer zu portieren als ein JIT-Compiler. IL-Operationen sind primitiver als Seite 21 von 40

22 Hochsprachenoperationen und daher deutlich schneller in Maschinencode zu übersetzen. Daher ist IL optimal für die geforderte Plattformunabhängigkeit, die jedoch anders definiert ist als die bekannte Java-Plattformunabhängigkeit. Während es die Java Virtual Machine auch für viele Microsoft-unabhängige Betriebssysteme, wie Linux, Unix oder MacOS gibt, schränkt Microsoft den Begriff nur auf eigene Produkte, wie z. B. Windows XP, Windows CE.NET oder Windows basierte Smartphone-Betriebssysteme ein. C#- Quellcode VB.NET- Quellcode Anderer Quellcode C#- Compiler VB.NET- Compiler Anderer Compiler Entwicklung MSIL JIT-Compiler Laufzeit Ausführbarer Code Diese Grafik stellt die Entwicklung vom Quelltext bis zum lauffähigen Programm dar. Seite 22 von 40

23 Assemblies Dass Programme heutzutage nicht mehr nur aus einer einzigen Datei bestehen, bringt unter Windows gewisse Schwierigkeiten mit sich. Bei einer einfachen C-dll reicht es aus, wenn sich diese im selben Verzeichnis wie das Programm befindet. Werden jedoch Funktionen aus COM-dlls eingebunden, müssen diese Metainformationen über die in ihnen implementierten Typen und Klassen in der Windows-Registry hinterlegen. Hinter COM steht die Philosophie, dass vorhandene Funktionalität global bereitgestellt wird. Die Trennung von ausführbaren Dateien und ihren zentral verwalteten Metadaten hat außerdem zur Folge, dass von jeder Komponente nur eine einzige Version installiert sein kann und bei Aktualisierungen die Synchronisation beider Seiten bedacht werden muss. Dadurch kann die Installation eines Programms, das weitere COM- Komponenten mitbringt, die Ausführbarkeit anderer Anwendungen beeinträchtigen. Allgemein hat sich für diesen Zustand der Begriff dll-hölle durchgesetzt. Eine Teillösung dieses Problems ist in.net mit Namespaces verwirklicht. Namespaces in.net Hinter Namespaces steckt die Idee, die Sicht auf den Code zur Entwicklungs- und Installationszeit voneinander zu trennen. In der Entwicklung ist es vorteilhaft, wenn Code als eine Einheit repräsentiert wird und die Tatsache, dass Code auf verschiedene Dateien verteilt ist, sollte für den Programmierer weitestgehend versteckt bleiben, denn auf wie viele Dateien das Endprodukt aufgeteilt ist, ist für den Entwickler uninteressant. Alle Typen im CTS gehören zu einem Namespace, die Namen dieser Typen müssen innerhalb eines Namespaces eindeutig sein, können aber die gleichen Namen innerhalb verschiedener Namespaces tragen. Namespaces lassen sich beliebig tief verschachteln, das Prinzip ähnelt dem der Verzeichnisse auf Datenträgern. Seite 23 von 40

24 Beispiel für die Namensvergebung in Namespaces namespace Seminare namespace Komponenten_O_SE class Vortrag1... namespace Boersenseminar class Vortrag1... namespace Schulungswochenende struct Vortrag1... Der Name Vortrag1 wurde dreimal verwendet, es entsteht jedoch kein Konflikt, da alle in verschiedenen Namespaces definiert sind. Das Ansprechen dieser Typen und Klassen sieht wie folgt aus: Seminare.Komponenten_O_SE.Vortrag1 c1; Seminare.Boersenseminar.Vortrag1 c2; Schulungswochenende.Vortrag1 s; Die Einbindung kann ebenfalls mithilfe von using erfolgen, wodurch das Vollqualifizieren wegfällt, sofern keine Namenskonflikte entstehen: using Seminare.Boersenseminar; Vortrag1 v; Um Namespaces aus verschiedenen physikalischen Referenzen (z. B. dll-dateien) zu benutzen, müssen diese selbstverständlich in das Projekt eingebunden werden. Also ein Projekt besteht meist aus mehreren Quelldateien, die zusammen nach der Kompilierung eine ausführbare Datei ergeben, eine so genannte Assembly. Diese Assemblies tragen die Dateiendung exe oder dll. Aber im Grunde unterscheiden sie sich nur dadurch voneinander, dass exe-dateien einen Einstiegspunkt enthalten, was sie direkt von der Kommandozeile ausführbar macht, während dll-dateien eine exe als Host benötigen, in der sie laufen. In Assemblies können beliebig viele Typen in beliebig vielen Namespaces definiert werden. Wie oben bereits erwähnt, tragen COM-Komponenten ihre Metadaten nicht bei sich selbst..net-assemblies hingegen trennen Code nicht von ihren Metadaten und tragen diese in ihrem Manifest. Daher kann man auch sagen, dass.net- Seite 24 von 40

25 Applikationen selbstbeschreibend sind. Diese Metadaten enthalten Informationen über jede Klasse oder Methode, jeden Parameter und ebenfalls über ihre Version. Die.NET-CLR geht bei der Ausführung davon aus, das die benötigten Assemblies im selben Verzeichnis wie das Programm liegen, und diese sind für Programme in anderen Verzeichnissen nicht sichtbar, durch dieses Prinzip auch private Assemblies genannt entfällt die globale Registrierung. Dieser Sinneswandel von Microsoft gegenüber dem COM-Prinzip dient der Stabilität der Anwendung, nimmt dabei aber erhöhten Speicherbedarf durch Redundanz in Kauf. Dadurch können sich Applikationen nicht mehr gegenseitig ihre global gespeicherten Komponenten überschreiben, was zum Abbau der dll-hölle führt. Trotzdem gibt es weiterhin noch globale Assemblies, die so genannten Shared Assemblies, welche im GAC (Global Assembly Cache) abgelegt sind. Hier sind auch die Assemblies des.net Frameworks abgelegt. In diesem GAC können von einzelnen Assemblies mehrere Versionen enthalten sein, bei der Ausführung von Programmen werden also die privaten Assemblies, sowie die Globalen berücksichtigt, hierbei standardmäßig die neueste Version, sofern ein Programm nicht durch die Veränderung seiner Konfiguration an eine bestimmte Assemblyversion gebunden ist. Bei der Arbeit mit Shared Assemblies tauchen zwei Probleme auf. Wie werden Namenskonflikte vermieden, und wie werden Assemblies vor Sabotage geschützt? Hierfür gibt es die Technik der Strong Names, standardmäßig wird auf ein Assembly nur schwach verwiesen, was bedeutet, dass nur der kurze Assemblyname (Dateiname ohne die Erweiterung) berücksichtigt wird. Um aber die Sicherheit und Stabilität zu gewährleisten, kann Assemblies ein Strong Name zugewiesen werden, der zusätzlich aus einer Version (Haupt-, Unterversion, Revision und Übersetzung), Kulturinformation (z. B. de) und einem öffentlichen Schlüssel. Verweist ein Assembly a auf ein anderes Assembly b mit Strong Name, so wird im Manifest von a der Schlüssel von b abgelegt (genauer: eine daraus extrahierte verkürzte Version, ein Public Key Token)..NET bedient sich hier dem Public Key-Verfahren. Beim Laden des Programms wird die Authentizität überprüft, und somit werden die Verknüpfungen zwischen Assemblies geschützt. Auszug aus einem Beispiel-Manifest einer Assembly, die mit der Komponente mscorlib.dll verknüpft ist..assembly extern mscorlib.publickeytoken = (B7 7A 5C E0 89 ).ver 1:0:5000:0 //.z\v.4.. Seite 25 von 40

26 Die.NET-Klassenbibliothek Wer mit Java gearbeitet hat, kennt das Prinzip der Klassenbibliotheken. Wie Java enthält auch das.net Framework solche eine Klassenbibliothek, die in der Version 1.1 bereits 2303 öffentliche Klassen umfasst und in der angekündigten Version 2.0 auf 3913 Klassen anwachsen soll. Für die.net-klassenbibliothek sind zwei Bezeichnungen geläufig, einmal.net-fcl (Framework Class Library) und.net-bcl (Base Class Library). Einige dieser Klassen halten sich an den Standard 335, auch CLI (Common Language Infrastructure) genannt, der ECMA (der European Association for Standardizing Information and Communication Systems). Diese Klassen werden auch als CLI Class Library bezeichnet. Eine erste Version dieses Standards wurde von Microsoft entworfen, aber nach der Mitsprache vieler anderer Unternehmen in diesem Standardisierungsprozess in einer zweiten Version an vielen Stellen geändert. Die FCL vereinigt viele Dienste mit objektorientiertem Zugriff. Dies ist ein weiterer Schritt, die Komplexität bisheriger API-Programmierung zu verringern. Allen.NET- Sprachen stehen diese Basisklassendienste in derselben Weise zur Verfügung, somit unterscheiden sie sich nicht mehr in den Möglichkeiten ihrer Standardbibliotheken. Sie besitzen also selber keine mehr, sondern benutzen alle dieselben FCL-Klassen. Z. B. war vor.net die Benutzung der Zwischenablage selbst in den unterschiedlichen Microsoft-Sprachen anders implementiert. So muss man in Visual C++ über die MFC (Microsoft Foundation Classes) auf die Zwischenablage zugreifen, während dies in Visual Basic über eigene Funktionen geschieht. Als weitere Variante bietet sich beiden der Weg direkt über die Win32 API an. Diese Anzahl unterschiedlicher Wege mit verschiedener Schwierigkeit und Leistungsfähigkeit führt zu einer undurchschaubaren Softwareentwicklung. Die.NET-Klassenbibliothek ist verteilt auf mehrere Shared Assemblies (im GAC), die z. B. Funktionen für den Zugriff auf das Dateisystem, die Anzeige von Fenstern, Druckfunktionen, Remoting, Serialisierung, Grafikfunktionen, Datenbankzugriff etc. bieten und hierfür hunderte Typen in geschachtelten Namespaces bereitstellt. Als wichtigste Namespaces sind hier sicherlich Microsoft und System zu nennen. Der Namespace Microsoft versammelt insbesondere Typen für den Umgang mit Microsoft-spezifischen Diensten (z. B. der Windows Registry). Eine Übersicht über die wichtigsten.net-namespaces liefert die folgende Tabelle. Seite 26 von 40

27 Übersicht über die wichtigsten.net-namespaces Namespace Beschreibung Beispielklassen Microsoft.Win32 Registryzugriffe und Systemereignisse (Shutdown etc.) Registry RegistryKey SystemEvents System System. Collections System.Drawing System. Globalization System.IO System.Net System.Runtime. Remoting System.Runtime. Serialization System.Text System.Threading Elementare Datentypen, Shell- Fenster, Garbage-Collection Objektmengen Funktionen des Windows Graphics Device Interface (GDI) Zugriff auf Ländereinstellungen (Kalender, Datums- und Zahlenformat) Dateisystemzugriff und Dateizugriff Zugriff auf Netzwerkprotokolle (TCP, UDP, HTTP, DNS, etc.) Nutzung von entfernten Komponenten (Remoting) Serialisierung von Objekten Zeichenfunktionen, Textkodierung (z. B. UTF-7 und UTF-8) Multi-Threading- Programmierung System.Timers Zeitgesteuerte Ereigniss Timer System.Web Kommunikation zwischen Browser und Webserver System.Windows. Forms System.Xml Steuerelemente für die Gestaltung von Windows- Desktop-Anwendungen Zugriff auf das Document Object Model der XML Object, Buffer, Byte, Char, Array, Int32, Exception, GC, Console, String ArrayList, BitArray, Dictionary, Hashtable, Queue, SortedList, Stack Bitmap, Brush, Cursor, Font, Image, Pen, Point, Rectangle CultureInfo, Calendar, DaylightTime, GregorianCalender Directory, File, FileStream, MemoryStream, Path, StreamReader, StreamWriter HTTPWebRequest, HTTPWebResponse, DNS, IPAdress, Cookie, TCPClient, TCPListener ChannelServices, RemotingServices, IMessage, IMessageSink Formatter, Serilization, Info Encoder, Decoder, StringBuilder Thread, Mutex, ThreadPool HttpApplication, HttpCookie, HttpRequest, HttpResponse Button, CheckBox, DataGrid, FileDialog, Form, ListBox, MainMenu, MonthCalendar, NewFontDialog, RichEdit, ToolBarTreeView XmlDocument, XmlAttribute, XmlElement Seite 27 von 40

28 Remoting Bei komplexen Anwendungen, die auf verschiedene Rechner verteilt sind, ist es notwendig, dass Objekte über die Grenzen von Anwendungsdomänen, Prozessen und Computern hinweg kommunizieren können. Anwendungsdomänen (Application Domain) stellen eine isolierte Umgebung mit eigenem Speicherbereich innerhalb eines Prozesses dar, können also als Subprozess bezeichnet werden. Ein Prozess kann mehrere Anwendungsdomänen enthalten. Sie können schneller als Prozesse erzeugt werden, ohne die Sicherheit und die Speicherisolation zu gefährden, was sie für Web-Anwendungen prädestiniert. Das.NET-Remoting ist im Gegensatz zu den XML-WebServices eher für Kommunikation von.net-komponenten untereinander in einem lokalen Netzwerk gedacht. WebServices setzen einen WebServer voraus und sind somit für die breite Nutzung über das Internet vorgesehen. Beim Remoting dagegen, kann jeder Rechner als Host dienen, auf dem die Server-Anwendung gestartet wird. Daher ist Remoting als einfache Intranet-Technologie zu verstehen und leichtgewichtiger als WebServices. Die Remotingmechanismen des.net Frameworks ermöglichen es, Methoden von Objekten in anderen CLRs im Netzwerk aufzurufen. Nachrichten, die über.net-remoting übertragen werden, werden in serialisierter Form weitergeleitet. Wie das Serialisierungsformat aussieht, bestimmt ein Formatter. Microsoft bietet verschiedene Formatter an, beispielsweise den SoapFormatter und den BinaryFormatter. Als Transportmedium für die Remotingnachrichten stehen Channels zur Verfügung. Standardmäßig werden zwei Channels angeboten: ein TcpChannel und ein HttpChannel. Als Serialisierungsformat ist für den TcpChannel der BinaryFormatter und für den HttpChannel der SoapFormatter voreingestellt. Microsoft verlangt nicht, diese Realisierungen zu benutzen, sondern stellt sie nur zur Verfügung. Es können beliebige eigene Formatter und Channels definiert werden. Seite 28 von 40

29 Remoting-Beispiel für entferntes Berechnen einer Fibonacci-Zahl Server.cs Server.dll using System; namespace RemotingBeispiel public class RemotingServer : MarshalByRefObject int i=0; public RemotingServer() Console.WriteLine("Warte auf Input"); public int Fib(int a) Console.WriteLine(++i + ". Durchlauf"); if (a<=1) return 1; else return Fib(a-1)+Fib(a-2); Die Assembly Server.dll implementiert die eigentliche Funktionalität (rekursive Methode zur Berechnung der Fibonacci-Zahlen) und stellt diese der Serveranwendung (ServerApp.exe) zur Verfügung. Dabei ist es für die Server.dll transparent, ob der Zugriff lokal oder fern geschieht. Für die entfernte Objektkommunikaktion stehen zwei Mechanismen zur Verfügung die unter dem Oberbegriff Marshalling zusammengefasst sind. Zum Einen Marshalling by Value, hier geschieht die Übertragung anhand von Objektkopien, oder Marshalling by Reference, durch Austausch von Meldungen über einen Proxy (Stellvertreter). Letzteres wird durch die Ableitung von der Basisklasse MarshalByRefObject erreicht, was im aktuellen Beispiel zu sehen ist. Dabei existiert ein Proxy innerhalb der Client-Anwendungsdomäne und agiert als Stellvertreter für das Original-Serverobjekt und leitet Nachrichten an dieses weiter. Seite 29 von 40

30 ServerApp.cs ServerApp.exe using System; using System.Runtime.Remoting; using System.Runtime.Remoting.Channels; using System.Runtime.Remoting.Channels.Http; using RemotingBeispiel; namespace RemotingBeispiel class RemotingServerApp [STAThread] static void Main(string[] args) ChannelServices.RegisterChannel(new HttpChannel(8085)); RemotingConfiguration.RegisterWellKnownServiceType( typeof(remotingserver), "Aufruf", WellKnownObjectMode.SingleCall); Console.WriteLine("Zum Beenden die Enter-Taste drücken!"); Console.ReadLine (); Die Server-Anwendung stellt die Funktionalität für Remoting-Kontakte zur Verfügung. Mit RegisterChannel wird festegelegt, auf welchem Kanal der Dienst angeboten wird. In diesem Fall ein HttpChannel, der voreingestellt den SoapFormatter benutzt. Anschließend wird die Klasse bestimmt, von der Objekte per Remoting erzeugt werden (RemotingServer). Ein eigener multithreaded HTTP-Server hört daraufhin den Endpunkt auf Remoting-Aufrufe ab. Das Argument WellKnownObjectMode.SingleCall bewirkt, dass Objekte auf dem Server nur für die Dauer des Methodenaufrufs existieren, was den Vorteil bringt, dass nur kurz Ressourcen belegt werden und somit eine hohe Skalierbarkeit erreicht wird. Neben der Möglichkeit die Server-Einstellungen imperativ im Quelltext zu beeinflussen, kann man dies auch über XML-Konfigurationsdateien durchführen. Daraufhin würde sich die Serverkonfiguration innerhalb des Quelltextes der Server- Anwendung auf eine Zeile reduzieren und sähe wie folgt aus. static void Main(String[] args) RemotingConfiguration.Configure("ConfigDatei.config"); Console.ReadLine(); Seite 30 von 40

31 Die dazugehörige XML-Konfigurationsdatei ConfigDatei.config <configuration> <system.runtime.remoting> <application name="remotingbeispiel"> <service> <wellknown mode="singlecall"> type="remotingbeispiel.remotingserver" objecturi="aufruf" /> </service> <channels> <channel port="8085" type="system.runtime.remoting.channels.http.httpchannel, System.Runtime.Remoting"/> </channels> </application> </system.runtime.remoting> </configuration> Client.cs Client.exe using System; using System.Runtime.Remoting; using System.Runtime.Remoting.Channels; using System.Runtime.Remoting.Channels.Http; namespace RemotingBeispiel class RemotingClient [STAThread] static void Main(string[] args) ChannelServices.RegisterChannel(new HttpChannel()); RemotingConfiguration.RegisterWellKnownClientType( typeof(remotingserver), " Console.WriteLine("Zahl eingeben für die Fibonacci berechnet werden soll:"); int a=int32.parse(console.readline()); RemotingServer obj = new RemotingServer(); Console.WriteLine("Das Ergebnis lautet: " + obj.fib(a)); Console.WriteLine("Taste drücken zum Beenden"); Console.ReadLine(); Analog zu der Server-Anwendung wird beim Client der Kanal sowie die Klasse, die fern genutzt werden soll, registriert. Beim Client wird die Kenntnis, ob ein Aufruf lokal oder fern realisiert wird, auf eine Zeile Code (RemotingConfiguration...) reduziert. Wenn diese Zeile nicht existieren würde, könnte RemotingServer auch eine lokale Klasse sein, von der ein Objekt instantiiert wird. Also sorgt Remoting dafür, dass der Operator new korrekt zwischen lokalen und fernen Klassen unterscheidet. Seite 31 von 40

32 .NET-Sprachen Wie schon mehrfach erwähnt, vertritt Microsoft die Meinung, dass sprachliche Pluralität absolut wichtig für professionelle Softwareentwicklung ist. Daher hat Microsoft seine z. T. schon vorhandenen Programmiersprachen auf die.net- Plattform portiert. Zu den Wichtigsten sind hier einige Eigenschaften aufgeführt. C# C# ist eine Sprache, die für.net neu entwickelt wurde, aber im Grunde der C/C++ Familie angehört. Doch es lässt sich nicht leugnen, dass C# viele Eigenschaften von Java geerbt hat. Warum also hat Microsoft eine neue Sprache erfunden und nicht das vorhandene C++ weiter geführt? Dies lässt sich damit erklären, dass, aufgrund der inzwischen hohen Komplexität von C++ und den darin enthaltenen Konstrukten, das.net Sicherheits- und Stabilitätskonzept ausgehebelt würde. C# kann als Hauptsprache des.net-konzeptes angesehen werden, was eigentlich, nach den Plänen Microsofts Java hätte sein sollen, doch Rechtsstreitigkeiten mit Sun haben dies verhindert. Diese Streitigkeiten sind zu einem späteren Zeitpunkt beigelegt worden. Das.NET Framework wurde komplett in C# entwickelt und mit C# wurden gegenüber C/C++ einige Verbesserungen eingeführt, zu nennen wäre hier sicherlich der Verzicht auf Header-Dateien, Makros und globale Variablen/Konstanten/Unterprogramme. Als weiteres Feature wurde die automatische Speicherverwaltung eingeführt, sowie die Reduzierung auf Einfachvererbung, im Gegensatz zu der Mehrfachvererbung in C++. Aber bei dem Vergleich mit nicht.net-sprachen ist zu beachten, dass viele Features in C# nicht aus ihr selber stammen, sondern einfach eine Realisierung von CLR/CTS- Funktionen in C#-Syntax/Semantik sind. Visual Basic.NET Aufgrund der großen Zahl Visual Basic 6-Programmierer, musste Microsoft bei der Entwicklung von.net auf diese Rücksicht nehmen, und so entstand VB.NET. Es stand sogar zur Diskussion VB.NET zur.net Standardsprache machen, aber ein wahrscheinlich unbegründeter Ruf der Unprofessionalität der Sprache, ließ diese Pläne schnell wieder versiegen. Der Name VB.NET lässt vermuten, dass die Sprache 100% kompatibel zu VB6 ist, jedoch konnte dies wegen der engen VB6-Bindung an COM nicht realisiert werden. Jedoch steht ein Wizard bei der Portierung von VB6-Projekten auf die VB.NET- Plattform zur Verfügung, der alle Inkompatibilitäten bereinigen soll. Hierzu ist aber zu sagen, dass dies nicht ohne großen Aufwand geschieht. Manche Konstrukte können nicht konvertiert werden, weil es keine Entsprechung in VB.NET gibt, wieder andere werden durch kompatiblen Code ersetzt, was aber zu hohem Wartungsaufwand führt. Wiederum andere Programme können zwar übernommen werden, entsprechen Seite 32 von 40

33 aber nicht mehr der zeitgemäßen Programmierung einer.net-sprache. Da VB.NET wie alle anderen.net Sprachen auch auf die CLR und das CTS aufsetzen, waren gegenüber VB6 auch in der Syntax einige Änderungen von Nöten. Hinzu kommt die.net Klassenbibliothek, die viele der Visual Basic eigenen Fenster- und Standardbibliotheken ersetzt hat. Mit der Entwicklung zu VB.NET hat Microsoft für die Programmiersprache Basic eine komplett objektorientierte Stufe erreicht. Logischerweise gehen hiermit auch objektorientierte Ansätze wie Polymorphie, Überladen und Vererbung mit ein. Darüber hinaus hat Microsoft den Wunsch vieler Visual Basic-Programmierer in die Tat umgesetzt, nämlich eine strukturierte Ausnahmenbehandlung (mit try-catchfinally-blöcken), sowie volles Multithreading. Aber ebenfalls gilt für VB.NET was für C# gilt, viele Sprachkonstrukte kommen aus der CLR, dem CTS bzw. der FCL. Mit anderen Worten, VB.NET ist also keine VB6 Erweiterung, sondern eine neue Sprache auf Basis von.net mit ähnlicher Syntax wie VB6. Jedoch ist für VB.NET eine andere Bestimmung vorgesehen als für C#. VB.NET soll mittelfristig zu einer RAD-Sprache ausgebaut werden. RAD steht für Rapid Application Development, was bedeutet, das Entwicklungsprozesse beschleunigt werden sollen, indem zeitaufwändige und wiederkehrende Teilaufgaben automatisiert erledigt, oder durch Tools vereinfacht werden sollen. Somit ist VB.NET mit etwas wenigeren Features wie C# ausgestattet, so gibt es in VB.NET keine vorzeichenlosen Zahlentypen (was in der Tabelle auf Seite 13 auch zu erkennen ist) und kein Überladen von Operatoren. Während in C# immer weitere Sprachfeatures entwickelt werden, geht es in VB.NET eher um die Entwicklungserleichterung, was ganz dem Motto entspricht, dass jede Sprache unterschiedliche Stärken haben sollte, was sie für jeden Einzelfall speziell brauchbar macht. J# Wie schon erwähnt, war am Anfang der.net-entwicklung Java als Standardsprache vorgesehen. Nach dem Rechtsstreit mit Sun wurde dieser Plan erst einmal auf Eis gelegt, da Sun nicht wollte, dass Microsoft eigene Java-Implementationen realisiert. Im Oktober 2001, nachdem der Streit beendet war, stellte Microsoft doch eine eigene Java-Implementation für.net vor, J#. J# erzeugt aber nicht wie Java ByteCode, sondern, wie alle anderen.net-sprachen auch, Code in MSIL. J# ist aber trotzdem kompatibel mit dem JDK, mit anderen Worten Java-Programme können mit dem J#- Compiler verarbeitet werden. Keine Unterstützung jedoch finden JNI, RMI, und Applets, die jedoch schon lange in der Kritik von Microsoft standen. Mit diesen Ausnahmen, ist J# eine vollständige Java-Implementation. J# enthält also neben der FCL noch die Klassenbibliothek des JDK. So werden folgende äquivalente Codezeilen unter J# möglich System.Console.WriteLine("FCL oder JCL"); Seite 33 von 40