[X] Kleine Einführung in .Net

[Mr. B]

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 und 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 auf 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 ~Ich würde es so schreiben, bin mir aber nicht sicher. Aber ohne Bindestriche muss es falsch sein.~ 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 Permissions zu holen und man nicht die Userverwaltung für das eigene Programm neu schreiben muss. Dies geschieht in der Regel durch Attribute.

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

Assemblys 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 Assemblys sich nicht gegenseitig beeinflussen. Außerdem bestimmt die Assembly [anm]Was denn nun? Der, die oder das "Assembly"? (Siehe Vorsatz "Jedes Assembly")[/amm] 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 Member usw.) identisch sind, sind es unterschiedliche Typen, weil sie in anderen Assemblys existieren. Es existiert daher eine klare Grenze zwischen den Assemblys. In den Assemblys 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, Assemblys 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 etwas Feines, denn es gibt ja nicht nur feste Metadaten, sondern sie können mit den schon oben genannten Attributen beliebig erweitert werden.

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 Assemblys 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, all 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 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 und 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, wirkliche 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 Klasse im Framework. Auch Webservices lassen sich selber hosten. Webservices sind am ehesten vergleichbar mit den Diensten eines Windows-Systems. 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 sich neue aufregende Möglichkeiten zum Programmieren bieten. 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, selber 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 wird die Windows Workflow/Presentation/Communication Foundation 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.

[Mr. B]

Wenn ich noch meinen Senf dazu geben darf:

Wenn du schon das Wort "Assembly" im Deutschen benutzt, dann würde ich es auch auf Deutsch schreiben, sprich "Assemblys" im Plural.

Auch würde ich versuchen, so viele englische Begriffe zu meiden, wie es nur geht. Ich bleib der deutschen Sprache eben treu!

Mr. B

[Talla]

Wollte gerade den Artikel korrigieren aber bin mit einigen Sachen net ganz einverstanden bzw, unschlüssig

Diese ganzen Sachen hier wie:

.Net Framework <-> .Net-Framework

Das ist nen verzwicktes Thema, weil in der MSDN werden manche Sachen mit Bindestrich geschrieben, manche ohne, als Beispiel mal zwei Zitate:

http://www.microsoft.com/germany/msdn/aktuell/default.mspx schrieb:

Die Express-Edition erweitert die Produktpalette von Visual Studio um kleine, leicht zu erlernende und einfach einzusetzende Werkzeuge für Hobbyprogrammierer, Amateure und Programmiereinsteiger, die dynamische Windows-Anwendungen und Websites auf dem .NET Framework erstellen möchten.

http://www.microsoft.com/germany/msdn/aktuell/default.mspx schrieb:

Pünktlich zur weltweiten Markteinführung von Visual Studio 2005, SQL Server 2005 und BizTalk Server 2006 veranstalten in den nächsten Wochen eine Reihe von .NET User Groups kostenlose „Launch-Events“ in Zusammenarbeit mit Microsoft und der .NET-Vereinigung INETA.

Welche werden nun mit und welche ohne Bindestrich geschrieben?
.Net Framework anscheinend ja ohne

Und mir der Sache zu den englischen Begriffen: Das ist ein Fachartikel, wenn man mit dem Framework programmiert und Ressourcen sucht im Internet, wird man nie auf die deutschen Begriffe (soweit sie sich überhaupt sinnvoll übersetzen lassen) stoßen. In will sie auch nicht deutscher machen als sie sind, deshalb habe ich z.b. Assembly auch englisch behandelt und die Mehrzahl als Assemblies geschrieben, wie es z.B. in 5 von 6 Büchern gemacht wird, die ich zu .Net bzw. einer .Net Sprache habe. Auch werden bei Google nur knapp 700 Seiten gefunden zu Assemblys und 224000 zu Assemblies (bei Suche auf Seiten in Deutsch). Ich denke Assemblies ist der angebrachtere Begriff.

Die meisten restlichen Fehler sind klar, meistens halt Komma net gesetzt

Kann sich dazu mal jemand äußern wie ich da korrigieren soll?

Dann noch zu Polofreak, wegen dem Material: Nen paar Grafiken könnte ich bestimmt benutzen, aber kläre das mal mit dem Dozenten ab wegen Vervielfältigungsrecht, sind immerhin Folien zur Vorlesung so wie ich des sehe.

Das wars erstmal mit rumkommentieren, ihr seid dran
Gruß Karsten

[Polofreak]

ich frag ihn mal aber ich denke schon dass das klar geht, aber wie gesagt ich frag ihn nochmal. Muss ihm aber wahrscheinlich ne Mail schrieben, weil die Woche seh ich ihn nicht mehr.

VLG

[Mr. B]

Talla schrieb:

.Net Framework <-> .Net-Framework

Wenn man strikt nach den Regeln der deutschen Rechtschreibung geht, muss man nun mal mit Bindestrich schreiben. Ich würde es lassen, auch wenn das eigentlich mein Vorgänger Michael E. gemacht hat.

Talla schrieb:

Und mir der Sache zu den englischen Begriffen: Das ist ein Fachartikel, wenn man mit dem Framework programmiert und Ressourcen sucht im Internet, wird man nie auf die deutschen Begriffe (soweit sie sich überhaupt sinnvoll übersetzen lassen) stoßen. In will sie auch nicht deutscher machen als sie sind, deshalb habe ich z.b. Assembly auch englisch behandelt und die Mehrzahl als Assemblies geschrieben, wie es z.B. in 5 von 6 Büchern gemacht wird, die ich zu .Net bzw. einer .Net Sprache habe. Auch werden bei Google nur knapp 700 Seiten gefunden zu Assemblys und 224000 zu Assemblies (bei Suche auf Seiten in Deutsch). Ich denke Assemblies ist der angebrachtere Begriff.

Auch hier gilt: Die Engländer sagen zur Mehrzahl von "bratwurst" auch nicht "bratwuerste", sondern "bratwursts". Wieso sollen/dürfen wir nicht auch eingedeutschte Begriffe nach deutschen Regeln verwenden? Kurzum, so wie "Hobby" und "Handy" (was ja eigentlich nicht einmal englisch ist), wird auch "Assembly" im Plural mitm s und ohne ie geschrieben. So würde ich es machen. Basta.

Talla schrieb:

Kann sich dazu mal jemand äußern wie ich da korrigieren soll?

Worauf bezogen jetzt?

Mr. B

[Michael E.]

Mr. B schrieb:

Talla schrieb:

.Net Framework <-> .Net-Framework

Wenn man strikt nach den Regeln der deutschen Rechtschreibung geht, muss man nun mal mit Bindestrich schreiben. Ich würde es lassen, auch wenn das eigentlich mein Vorgänger Michael E. gemacht hat.

Ich habs zuerst sein gelassen, wie du an dem einen Fehler bei Suchen und Ersetzen wahrscheinlich erkannt hast. Dann hab ichs aber aus Konsistenzgründen mit Bindestrich geschrieben.

Talla schrieb:

Und mir der Sache zu den englischen Begriffen: Das ist ein Fachartikel, wenn man mit dem Framework programmiert und Ressourcen sucht im Internet, wird man nie auf die deutschen Begriffe (soweit sie sich überhaupt sinnvoll übersetzen lassen) stoßen. In will sie auch nicht deutscher machen als sie sind, deshalb habe ich z.b. Assembly auch englisch behandelt und die Mehrzahl als Assemblies geschrieben, wie es z.B. in 5 von 6 Büchern gemacht wird, die ich zu .Net bzw. einer .Net Sprache habe. Auch werden bei Google nur knapp 700 Seiten gefunden zu Assemblys und 224000 zu Assemblies (bei Suche auf Seiten in Deutsch). Ich denke Assemblies ist der angebrachtere Begriff.

Auch hier gilt: Die Engländer sagen zur Mehrzahl von "bratwurst" auch nicht "bratwuerste", sondern "bratwursts". Wieso sollen/dürfen wir nicht auch eingedeutschte Begriffe nach deutschen Regeln verwenden? Kurzum, so wie "Hobby" und "Handy" (was ja eigentlich nicht einmal englisch ist), wird auch "Assembly" im Plural mitm s und ohne ie geschrieben. So würde ich es machen. Basta.

So stehts auch im Duden (also bei meiner Ausgabe, kann sein, dass sich da was in den letzten sieben Jahren was getan hat).

[estartu]

Hierzu fehlt auch noch der Neu-Post mit [E].
Wird es was mit Morgen Abend? So 19:00 bis 20:00 hatte ich mir überlegt.

[Talla]

Klar kein Problem, bin aber immer noch unschlüssig wie ich korrigieren soll.

So wie der Hersteller(Microsoft in dem Fall) auf seinen Webseiten ihr Produkt schreibt(.Net Framework) oder wie es wohl nach deutscher Rechtschreibung richtig ist(.Net-Framework)... Ich tendiere eher zur Herstellerschreibweise, ist immerhin ihr Produkt, die werden schon wissen, wie sie es geschrieben haben wollen. So wie es aussieht werden nämlich alle technischen Dinge im Zusammenhang mit .Net auseinander geschrieben und wie beim letzten Beispiel Organisationen und sonstiges mit Bindestrich.

[estartu]

Entscheide dich einfach für eine Regelung und zieh sie durch.

So ging das doch früher im Diktat auch immer: Wenn du keine Ahnung hast, wie ein Wort richtig geschreiben wird, entscheide dich für EINE falsche Version. Das ist dann nur ein Fehler.

Ich persönlich habe nen Bindestrich-Tick, also gebe ich lieber keinen Tip ab.

[Talla]

Dachte eigentlich bin raus aus der Schule Aber okay, werde dann nacher einen korrigierten Artikel nochmal reinschreiben, und dann falls dazu bis Morgen nichts mehr kommt dann endgültig posten.

[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