Kleine Einführung in .Net

[Talla]

Eine kleine Einführung in .Net

Mit diesem Artikel möchte ich eine kleine Einführung geben, was der Begriff .Net überhaupt bedeutet und Kerntechnologien und Konzepte ein wenig erläutern. Ich werde dabei nicht über eine spezielle Programmiersprache reden, dies bleibt anderen Artikeln überlassen. Auch möchte ich vermeiden Wertungen abzugeben, dieser Artikel soll nur beschreiben. Ich beziehe mich hauptsächlich auf Version 1 vom Framework, werde aber an einigen Stellen auch Version 2 ansprechen.

Vision

Um das Gesamtkonzept von .Net zu verstehen, müssen wir uns erst einmal anschauen, wie die Soft-/Hardwarelandschaft momentan aussieht:

Das Internet hat eine zentrale Rolle im Alltag übernommen. Ein Großteil der Computeruser ist vernetzt und trotzdem wird es zum großen Teil nur dazu genutzt, Daten/Informationen in welcher Form auch immer zu verbreiten. Doch damit ließe sich noch viel mehr anfangen! In nicht allzu ferner Zukunft werden nicht nur PCs vernetzt sein, sondern auch Konsumelektronik, Handys oder Küchengeräte, gerade weil das Internet ein zuverlässiges Medium zur Datenübertragung darstellt.

Und da kommt .Net ins Spiel.
Es stellt eine Plattform zur Verfügung, auf der Programme laufen, unabhängig von dem Gastsystem. Anwendungen können auf einem Fernseher genauso laufen wie auf einem Handy oder dem PC. Überall wo es das .Net Framework gibt, können die Programme ohne großartige Anpassungen laufen.

Doch es geht noch weiter, ein zentraler Teil der Vision sind die Webservices. Anwendungen werden nicht nur mehr lokal auf einem Client ausgeführt, sondern nutzen immer mehr Services, die im Internet angeboten werden. Die Anwendungen verteilen sich praktisch. Ein Anbieter könnte eine GUI zur Verfügung stellen, aber die Business-Logik wird auf seinen Servern ausgeführt. Die Kommunikation geschieht über Standards wie SOAP, so dass auch dort keine Limitation soft- und hardwarebetreffend existiert. Wenn Sie mit .Net programmieren, macht es keinen Unterschied, ob sie Funktionen benutzen, die z.B. eine User Library lokal zur Verfügung stellt, oder ob sie Funktionen eines Webservices in Anspruch nehmen. Verteilte Anwendungen sind überall…

Auch wenn viele, wenn sie „.Net“ sagen, nur das .Net Framework meinen, ist es doch mehr. Es ist eine Vision, ein Zusammenspiel von Technologien und Hardware, das in Zukunft eine serviceorientierte Welt erlaubt, die von den unterschiedlichsten Geräten benutzt werden kann, die aber alle auf einer vereinheitlichten Plattform laufen.

Technologien

Die .Net-Vision wird hauptsächlich durch das .Net Framework und die Enterprise Server realisiert. Mein Augenmerk in diesem Artikel wird auf dem .Net Framework liegen, da der Inhalt sonst den Umfang eines Artikels bei weitem sprengen würde.

Das .Net Framework besteht nun aus folgenden Kerntechnologien:

Common Language Runtime (CLR)
Klassenbibliothek (BCL)
ASP.NET
ADO.NET

Die CLR bietet die Grundlage für .Net. Um .Net zu verstehen muss man die CLR verstehen, und deshalb werde ich darauf als Erstes eingehen.

Common Language Runtime

Die CLR ist die Laufzeitumgebung, die die .Net-Programme ausführt. Sobald sie auf einem Zielsystem vorhanden ist, können dort .Net-Programme ausgeführt werden.

Wenn Sie vorher noch nie von .Net gehört haben, fragen Sie sich sicherlich, wieso immer von .Net die Rede ist, dabei ist doch .Net keine Programmiersprache! Mit welcher Sprache programmiere ich dann? Die Antwort lautet ganz einfach: mit welcher Sie wollen! Alle Compiler für .Net-Sprachen generieren so genannten CIL-Code (Common Intermediate Language Code). Da wir von den Abkürzungen ja noch nicht genug haben, gibt’s auch noch die CLS (Common Language Specification). Die CLS beschreibt im Prinzip eine Untermenge an Funktionalität und ein gemeinsames Typensystem, das von allen .Net-Sprachen erfüllt werden muss. Dadurch ergibt sich auch die Möglichkeit, Klassen, die in einer .Net Sprache geschrieben wurden, in jeder anderen .Net-Sprache zu verwenden, solange der Code CLS-konform ist. Dieser CIL-Code wird vor dem bzw. beim Ausführen von einem Just-in-Time-Compiler in Maschinencode umgewandelt und dann ausgeführt. .Net-Programme sind nicht interpretiert, auch wenn das in manchen Quellen im Internet zu finden ist. Erst wenn der CIL-Code in Maschinencode vorliegt, wird er auch ausgeführt. Dadurch ergibt sich die Möglichkeit, ein Programm zu schreiben, bei dem man dem Compiler nicht angibt, für welche Plattform optimiert werden soll, wie in vielen klassischen Sprachen, sondern das Programm durch den JIT-Compiler der CLR optimiert wird, da sie ja eh auf die Plattform zugeschnitten ist. So ist auch zu erklären, warum .Net-Programme, wenn sie denn erst einmal kompiliert sind, prinzipiell genauso schnell sind wie klassische C++-Programme, im Fall von unoptimiertem C++-Code sogar schneller sein können, da der JIT-Compiler den Code an das ausführende System anpasst.

Es gibt aber noch einige Dinge, die das Laufzeitverhalten von .Net-Programmen beeinflussen. Die CLR überwacht die Ausführung von .Net-Programmen, deshalb wird .Net-Code auch oft als „managed“ bezeichnet. Doch was gibt es da zu überwachen? Als Erstes ist dort das automatische Speichermanagement von .Net zu nennen. Der Garbage Collector (GC) sorgt dafür, dass nicht mehr benötigte Objekte aus dem Speicher entfernt werden und deswegen ein manuelles Entfernen nicht mehr nötig ist. So werden Speicherlecks durch fehlende Freigaben seitens des Users auf ein Minimum reduziert. Außerdem gibt es mit den Exceptions ein durchweg konsistentes Fehlerbehandlungssystem. Wenn ein .Net-Programm eine Exception wirft, kann sie praktisch vor Ort im Code abgefangen und behandelt werden. Geschieht dies nicht, stürzt nicht etwa das Programm unkontrolliert ab, sondern die Fehlerbehandlung der CLR tritt in Kraft. Diese ständige Überwachung erzeugt ein wenig Overhead im Vergleich zu „unmanaged“ Programmen, die aber durch die größere Produktivität und Sicherheit ausgeglichen werden, wenn es um das Gesamtprodukt geht.

Ein weiteres wichtiges Feature von .Net ist die Codesicherheit. Es ist möglich sich Permissions im Code zu holen, um sicherheitsrelevante Funktionen auszuführen oder auch dem aktuellen User einige Funktionen zu verweigern. Die CLR arbeitet damit eng mit der Userverwaltung des Hostsystems zusammen, und so ist es möglich, sich im Code, nur durch Setzen von Attributen, je nach User automatisch unterschiedliche Permission zu holen und man muss nicht die Userverwaltung für das eigene Programm neu schreiben. Dies geschieht in der Regel durch Attribute.

Durch Attribute ist es aber auch möglich die Metadaten von Assemblies zu ändern. Aber was sind nun Metadaten und Assemblies?

Assemblies lassen sich äußerlich am ehesten mit den klassischen DLLs vergleichen. Aber sie sind mehr. Es ist im Prinzip CIL-Code, der im PE-Format vorliegt, daher ausführbar ist, aber sie enthalten unter anderem auch Ressourcen. Dabei formt eine Assembly eine Sicherheits-, eine Typ-, eine Referenz- und eine Versionierungsgrenze. Was ist das nun wieder alles? Fangen wir von vorn an: Die CLR ist ja eine Virtual Machine, die den .Net-Code ausführt. Sie regelt alle Zugriffe auf den Speicher und ein .Net-Programm kann prinzipiell erst einmal nicht im Speicher rumpfuschen. Jedes Assembly besitzt nun seinen eigenen Speicherbereich und so können Assemblies sich nicht gegenseitig beeinflussen. Außerdem bestimmt die Assembly selber, inwieweit von außerhalb darauf zugegriffen werden kann. Zur Typgrenze ein einfaches Beispiel: Wir haben Assembly A und einen eigenen Typ P1 und eine Assembly B und einen Typ P2. Selbst wenn die Typen vom Quellcode her(gleiche Members usw.) identisch sind, sind es unterschiedliche Typen, weil sie in anderen Assemblies existieren. Es existiert daher eine klare Grenze zwischen den Assemblies. In den Assemblies ist auch festgelegt, welche Referenzen benutzt werden, und sie sind das kleinste versionierbare Stück Code in .Net.

Mit klassischen Dlls kam man früher oder später zum Problem, dass Programm A eine DLL vom Typ D in Version 1 benötigt und Programm B auch eine DLL vom Typ D, aber in Version 1.5 braucht. Oft passierte es nun, dass Version 1 und 1.5 der DLL zueinander inkompatibel waren, und nun funktionierte entweder Programm A oder B nicht richtig. Die ganze Problematik ist wohl besser unter dem Namen "DLL Hell" bekannt! Dieses Problem gibt es in .Net nicht mehr. Die Metadaten beschreiben jede Assembly für sich und so können sie genau versioniert werden. Nicht nur der Name wird zur Unterscheidung herangezogen, sondern die gesamten Metadaten. In .Net können nun beide Versionen nebeneinander existieren, sodass das Problem gelöst wäre. Doch außer zur Versionierung sind die Metadaten noch zu viel mehr nützlich. Sie beschreiben wie gesagt die Assembly und so ist es möglich, Assemblies als Komponenten zu benutzen, ohne sie vorher im System registrieren zu müssen, wie es noch bei COM der Fall ist. Einfach zum Zielsystem kopieren und benutzen können. das ist das Ziel. Metadaten sind schon was Feines, denn es gibt ja nicht nur feste Metadaten, sondern sie können beliebig erweitert werden mit den schon oben genannten Attributen.

Darauf baut ein Feature von .Net auf, das sich Reflection nennt. Mit Attributen kann man nun seine eigene Klasse beschreiben, und mit Reflection lassen sich nun diese Informationen verwerten. Praktisch eingesetzt wird dies zum Beispiel bei Interfaces, IDL entfällt vollkommen, da die Klassen sich ja selber beschreiben und keine zusätzliche Beschreibung des Interfaces von Nöten ist.

Damit wäre der erste Überblick über die CLR geschafft. Die Themen lassen sich im Prinzip noch beliebig vertiefen, z.b. die verschiedenen Arten der Assemblies oder was im Überblick gerade vollkommen vernachlässigt wurde, die Interoperabilität mit COM und klassischen DLLs.

Die Klassenbibliothek

Was wäre eine Programmierumgebung ohne vernünftige Klassenbibliothek? Eine Programmiersprache lebt von den verfügbaren Funktionen und im Falle von .Net bietet die BCL die Grundlage für alle .Net-Sprachen. Das .Net Framework als Basis für viele mögliche Programmiersprachen führt sogar dazu, dass gerade im wissenschaftlichen Bereich viele Entwürfe für Experimentalsprachen existieren, die die umfangreiche BCL benutzen, um von Haus aus mächtige Funktionen zu bieten. Doch was macht die BCL so mächtig? .Net ist zwar prinzipiell plattformunabhängig, wurde aber natürlich mit Schwerpunkt Windows als Betriebssystem entwickelt. Dort gibt es viele Möglichkeiten zur Programmierung: MFC, ATL, STL, Win32-API um nur einige zu nennen. Das Ziel ist nun, alle diese teilweise recht veralteten Bibliotheken in einer gemeinsamen Klassenbibliothek abzubilden und das natürlich vollkommen objektorientiert. Während es in Version 1 noch einige Lücken gibt, bietet Version 2 schon fast alle Möglichkeiten der oben genannten Bibliotheken und bietet sogar bessere und modernere Klassen an. Die BCL ist klar hierarchisch gegliedert in Namespaces. Namespaces gliedern die Klassen logisch gesehen, nicht physikalisch. Ich möchte hier ein paar bedeutende Klassen und Namespaces aufzählen (bei weitem keine komplette Liste!)

System

Console
GC
Math
Random
String

System.Collections

ArrayList
Hashtable
Queue
Stack

System.Diagnostics

Debug
EventLog
Process
Trace

System.IO

File
FileInfo
Stream
StreamReader
StreamWriter

System.Net.{}
System.Runtime.{}
System.Security.{}
System.Web.{}
System.Xml.{}

Besonders die zuletzt genannten sind bei weitem zu komplex, um sie kurz zu beschreiben. In der BCL ist viel Funktionalität, die bei anderen Sprachen durch Zusatzbibliotheken zur Verfügung gestellt werden muss, schon vorhanden, wie z.B. mächtige XML-Klassen. Doch einige der wichtigsten Namespaces fehlen noch in der oben genannten Aufzählung: System.Windows.Forms und System.Data. In System.Data und den dazugehörigen Namespaces und Klassen befindet sich ADO.NET – die Datentechnologie von .Net. Es bietet eine vereinheitlichte, neue Möglichkeit auf Daten fast jeglicher Art zuzugreifen. Egal ob jetzt XML oder SQL-Datenbanken, der Zugriff erfolgt einheitlich. ADO.NET ist aber ein Thema an sich, das ich eventuell in einem Folgeartikel behandeln werde. Dies soll ja nur ein Überblick werden und kein Buch. Deshalb sei der Namespace Windows.Forms auch nur mal erwähnt. Mit den dort befindlichen Klassen lassen sich schnell Oberflächen entwickeln und es gibt viele vorgefertigte Controls, die man benutzen kann. Von der Einfachheit am ehesten mit VB oder Delphi zu vergleichen, nur machtvoller. Gerade in Version 2 wurde noch einiges erweitert/geändert, so dass mit Leichtigkeit extrem komplexe Oberflächen entwickelt werden können, die modern aussehen und auch eine entsprechend moderne Funktionalität bieten. Mit der Windows Presentation Foundation werden in Zukunft auch Klassen Einzug ins Framework halten, die es ermöglichen die grafischen Möglichkeiten von Windows Vista vollkommen auszureizen und so eine neue Art von Oberflächen zu entwickeln. Aber auch das wäre wieder einen gesonderten Artikel wert.

Zu beachten ist auch, dass die Namespaces bzw. Klassen nicht als Einzelnes gesehen werden dürfen. In der BCL arbeiten sie eng miteinander und nutzen so alle Möglichkeiten aus, dabei benutzt die BCL alle Möglichkeiten der CLR um eine moderne, objektorientierte, leicht zu benutzende Klassenbibliothek zu bilden. Auf Dauer wird die .Net-Klassenbibliothek die oben genannten klassischen Bibliotheken und Programmiermöglichkeiten für Windows ersetzen.

Auch wenn es hier nicht ganz passt, sei auch noch ASP.NET genannt.
ASP.NET ist die Webtechnologie in der .Net-Vision. Sie ist nicht nur einfach eine Weiterentwicklung vom klassischen ASP, sondern bietet eine fast vollkommen neue Möglichkeit, wirklich Web-Applikationen zu schreiben. Die Oberfläche besteht in Version 1 vom Framework aus Controls, ähnlich zu den Windows Forms Controls, die aber zu klassischem HTML gerendert werden. Auch das wird sich in Zukunft mit der Windows Presentation Foundation ändern. Sie vereinheitlicht die Oberflächen von Web- und Windows-Applikationen und beide können einheitlich mit XAML beschrieben werden. Technisch basiert ASP.NET in Version 1 größtenteils auf dem IIS als ausführende Umgebung, da aber ASP.NET auch extensiv die BCL benutzt, ist es ohne weiteres möglich mit den entsprechenden Klassen selbst in der eigenen Anwendung zu hosten. In Version 2 vom .Net Framework wurde diese Möglichkeit sogar noch ausgebaut. Es gibt im Prinzip schon einen einfachen http-Server als vorgefertigte Klassen im Framework. Auch Webservices lassen sich selber hosten. Webservices sind am ehesten vergleichbar mit den Diensten eines Windowssystems. Sie nehmen Anfragen entgegen, verarbeiten sie und senden eine Antwort zurück. Kommuniziert wird dabei über XML in Form von SOAP-Nachrichten. Das ganze geschieht auch so transparent, dass es möglich ist eine Funktion eines Webservices im eigenen Programm anzusprechen, als ob die Funktion in einer beliebigen lokalen Bibliothek vorhanden wäre.

Nun sind wir im Prinzip wieder bei den verteilten Anwendungen vom Anfang des Artikels! Und ich bin auch mit dem groben Überblick des Frameworks fertig. Man sieht, dass die CLR und das Framework wirklich durchdacht worden sind und neue aufregende Möglichkeiten bieten zum Programmieren. Die Art und Weise, wie in Zukunft, besonders auf der Windowsplattform, programmiert wird, wird sich ändern.

Ausblick

Man sieht schon heute, dass mit dem .Net Framework eine extrem fähige Programmierumgebung geschaffen wurde. Doch dies ist erst der Anfang. Microsoft hat beschlossen, selbst Teile künftiger Betriebssysteme in .Net-Code zu schreiben – daran sieht man die Tragweite dieser Vision. Mit der Version 2 steht schon ein großer Schritt vorwärts in die Richtung einer noch mächtigeren Plattform bevor. Version 3 ist schon in Planung bzw. es gibt erste Entwürfe. Außerdem werden die Windows Workflow/Presentation/Communication Foundations besonders im kommenden Windows Vista schon maßgeblich die Programme beeinflussen. Für Programmierer steht eine wahrlich aufregende Zukunft bevor. Momentan noch sehr auf Windows fixiert wachsen auch alternative Implementierungen wie MONO immer mehr aus den Kinderschuhen heraus und liefern eine stabile Plattform.

Abkürzungen

BCL: Base Class Library
Klassenbibliothek vom .Net Framework

CIL: Common Intermediate Language
Zwischensprache, in die .Net-Sprachen kompiliert werden

CLS: Common Language Specification
Grundfunktionalität, die eine .Net-Sprache erfüllen muss, um aus anderen .Net-Sprachen genutzt werden zu können

CLR: Common Language Runtime
Laufzeitbibliothek ,die .Net-Code verarbeitet und Funktionalität zur Verfügung stellt

JIT: Just in Time
Kompilierart, die bei .Net-Code angewendet wird. .Net-Code wird vor der ersten Ausführung kompiliert

[_maxE_]

Netter Artikel.
Ich würde aber den Unterschied zwischen BCL und FCL deutlicher herausheben. Du bezeichnest die gesammte Klassenbiblothek als BCL, was aber nicht ganz richtig ist. Die BCL bezeichnet nur die wichtigsten Basisklassen, die von der ECMA standardisiert worden sind. Siehe Technical Report:
http://www.ecma-international.org/publications/techreports/E-TR-084.htm
Und noch einige eventuelle Erweiterungen für zukünftige Versionen:
http://www.ecma-international.org/publications/techreports/E-TR-089.htm

Der Rest, wie System.Windows.Forms, System.Data, usw. sind nicht mehr Teil der BCL, sondern der FCL.
Ein paar nette Demos zu den technischen Möglichkeiten von .NET gibts bei MSDN TV http://msdn.microsoft.com/msdntv/

[Gast]

Ein netter Überblick für Leute, die sich unter .Net nichts vorstellen können. Der Artikel wird seiner Überschrift gerecht.
Ich hätte darüber hinaus noch etwas zum Common Type System gesagt und welche Rolle es bei der Interoperabilität zwischen verschiedenen Assemblies und Programmiersprachen spielt.

[lomtas]

Also ich hatte ungefähr gar kein Wissen über .NET aber jetzt kann ich mir darunter etwas vorstellen. Ich finde den Artikel auch für Leute die noch ganz am Anfang stehen gut und verständlich geschrieben. Einzige Ausnahme: Die Abkürzung PE die verwendet wird konnte ich nirgends im Artikel erklärt finden...

[7H3 N4C3R]

PE heißt PortableExecutable und ist das Standardformat unter Windows für ausführbare Dateien.

[TheBigW]

Super Einführung!

Auch wenn es in dem Artikel auch schonmal steht: eine der stärken ist IMO wirklich die einheitliche Datenrepräsentation und die damit verbundene einheitlichen Zugriffsmechanismen.
Ich probiere zum einstieg gerade mit XML und Datenbanken herum. Da ich das gleiche schon mit DAO und MFC gemacht habe, muß ich sagen: da hat .Net die Nase vorn.

Kannst du ein Buch als Referenz für das komplette .Net Framework empfehlen?