Mit seiner Werbekampagne für .NET hat Microsofts Werbemaschinerie auf breiter Front versagt. Jede Menge Dienste, Systeme und Lösungen erhielten plötzlich ein Label mit .NET. Das Resultat: Niemand wusste mehr, was .NET eigentlich genau sein soll.
Als die Verwirrung auf dem Höhepunkt angelangt war, ruderte Microsoft plötzlich in die andere Richtung und entfernte das .NET-Label wieder aus den Produktnamen. Dennoch ist .NET noch immer als Komponente in vielen Produkten enthalten und wird sich in Zukunft auch immer stärker verbreiten. Es hat erheblichen Einfluss auf die Art und Weise, wie jedermann mit Computern umgeht: Anwender, Administratoren und Programmierer sind betroffen.
Kurz gefasst handelt es sich bei .NET um eine Vielzahl von Bestandteilen - im Wesentlichen ist es die zukünftige Grundlage für das Programmieren mit Systemen von Microsoft. Als Laufzeitumgebung fließt es in die Betriebssysteme von Microsoft ein.
Diese neue Grundlage baut auf den vorhandenen Funktionen von Windows auf und stellt eine Menge an Erweiterungen dafür zur Verfügung. Die Konsequenz daraus ist, dass viele Programme und Programmarten einfacher zu programmieren sind als zuvor. Zumindest wenn man ausschließlich für eine Microsoft-Plattform entwickelt.
Besonders Programme, die in irgendeiner Form Netzwerke oder Netzwerkdienstleistungen verwenden oder zur Verfügung stellen, sollen mit .NET deutlich einfacher zu entwickeln sein als mit der klassischen Windows-API und Windows-Sockets. Dasselbe gilt für Windows- oder XML-Dienste. Mit dem passenden Tool - dem Developer Studio .NET - ist auch die Verwendung von XML-Diensten durch .NET viel einfacher geworden.
Bisheriger .NET-Einsatz
Das am häufigsten mit dem .NET-Label versehene Produkt ist Windows XP. Dabei wurde das Label zunächst nur aus Marketing-Gründen aufgebracht, denn XP enthielt ursprünglich noch nicht einmal die .NET-Laufzeitumgebung. Erst das erste Servicepack von XP lieferte diese Komponente nach, so dass zumindest mit Visual Studio .NET erstellte Programme unter XP laufen.
Seit kurzem ist auch der Windows 2003 Server verfügbar. Ursprünglich sollte er .NET Server oder auch XP Server heißen und zeitgleich mit Windows XP ausgeliefert werden. Das geschah aber nicht, und so gibt es nun stattdessen seit dem Frühjahr 2003 den Windows 2003 Server. Auch dieser enthält die .NET-Laufzeitumgebung, hat aber zusätzlich noch die Version 6 des IIS (Internet Information Server) dabei, die ihrerseits für die Zusammenarbeit mit .NET konzipiert ist.
Außerdem gibt es verschiedene "Web Services" genannte Pläne und Produkte - ein recht bekanntes ist zum Beispiel Microsoft Passport. Der Passport-Dienst soll sich als zentrale Anmeldestelle im Internet verwenden lassen: Einmal bei Passport angemeldet, kann man automatisch an allen zugehörigen Webseiten teilnehmen, und jedem Webseitenbetreiber ist es dabei überlassen, an Passport teilzunehmen.
Schließlich gibt es inzwischen schon eine ganze Menge von Programmen, die die .NET-Laufzeitumgebung verwenden - und die Anzahl solcher Programme wird in Zukunft stetig zunehmen, so viel ist sicher.
Bleibt noch anzumerken, dass es auch bei Linux Projekte gibt, die sich mit .NET beschäftigen. So kümmert sich das MONO-Projekt beispielsweise um eine Implementierung der .NET-Laufzeitbibliothek für das Open-Source-System.
Die .NET-Umgebung - eine Kurzbeschreibung
Bei .NET handelt es sich - wie bereits erwähnt - um ein Laufzeitsystem, auf das Anwendungsprogramme zurückgreifen können, um vorgefertigte Funktionen zu nutzen. Diese Beschreibung wird dem System aber eigentlich nicht ganz gerecht. In der Praxis ist die Sache erheblich vielschichtiger.
Tatsächlich setzt sich .NET aus einer Reihe von Schichten zusammen, die unter dem Begriff CLI (Common Language Infrastructure) zusammengefasst sind. Zunächst einmal gibt es die Common Language Runtime (CLR), die das eigentliche Laufzeitsystem darstellt: .NET-Programme werden innerhalb der CLR ausgeführt. Prinzipiell können Programme für die CLR mit praktisch allen Programmiersprachen erzeugt werden, allerdings müssen sich diese natürlich an die Gegebenheiten der CLR halten.
Foto:
Dann gibt es die ".NET Framework"-Klassenbibliothek, die von Programmen innerhalb der CLR verwendet werden kann. Diese Bibliothek umfasst einige tausend Klassen, die einen riesigen Funktionsumfang für beinahe alle Zwecke zur Verfügung stellen. Diese Klassenbibliothek stellt die eigentliche Programmierschnittstelle für Anwendungsprogramme innerhalb der CLR dar. Sie ersetzt mehr oder weniger die Win32-API. Dabei haben .NET-Programme aber weiterhin Zugriff auf Funktionen in normalen Windows-DLLs. Dazu gibt es einen eigenen Mechanismus für die Kommunikation mit diesen "außerhalb" liegenden Funktionen.
Programmiersprachen für .NET
Passend zur Klassenbibliothek gibt es im Rahmen von .NET auch fertige, mitgelieferte Programmiersprachen - und zwar einschließlich der zugehörigen Compiler für diese Sprachen. Von Haus aus werden mit der .NET-Laufzeitumgebung Compiler für C# und Visual Basic mitgeliefert. Außerdem ist .NET auch von Javascript aus verfügbar. Nicht mitgeliefert wird dagegen eine grafische Entwicklungsumgebung. Dabei steht zum einen natürlich Microsofts Visual Studio zur Verfügung, aber auch Borland hat bereits eine IDE angekündigt. Ebenso gibt es in Form von ICSharpCode ein exzellentes Open-Source-Entwicklungssystem.
Wer einen C/C++-Compiler benötigt, wird ebenfalls in Visual Studio fündig. Dort gibt es Visual C++, mit dem sowohl normaler Code als auch Code für .NET erzeugt werden kann. Beim .NET-Laufzeitsystem selbst ist jedoch kein Compiler für C++ dabei.
Ferner handelt es sich bei .NET auch um eine Sammlung von Spezifikationen für verschiedene Dienste und Protokolle - diese sind dafür gedacht, von Dritten implementiert zu werden, damit die Programme und Dienste dieser Drittanbieter einfacher zusammenarbeiten können. Ob sich dieses Konzept durchsetzen wird, bleibt abzuwarten.
.NET hat einen recht weit gehenden Einfluss auf die Art und Weise, wie Software entwickelt, eingesetzt, verteilt und verwaltet wird. Und das ist auch der wesentliche Grund dafür, dass bei .NET eine solche Verwirrung herrscht, denn .NET stellt für praktisch jeden Personenkreis etwas anderes dar. Was .NET für wen bedeutet, das erfahren Sie im weiteren Verlauf dieses Beitrags.
.NET aus Anwendersicht
Im Großen und Ganzen ist es aus Sicht des Anwenders eigentlich völlig gleichgültig, mit welcher Sprache oder für welches System eine Software programmiert wurde. So praktisch verschiedenste Webdienste auch sein mögen - für den Anwender ist es hauptsächlich von Interesse, dass diese Dinge funktionieren, nicht aber, mit welchem Entwicklungssystem sie erstellt wurden.
Trotzdem ist es aber so, dass .NET auch auf Anwender Einfluss haben wird - und zwar einfach deshalb, weil das System Entwickler in die Lage versetzt, effizienter zu arbeiten und zuvor nur schwer zu implementierende Dienste anzubieten.
.NET hat auch einen Einfluss auf die Art und Weise, wie Anwender mit Computern arbeiten können, denn das System löst einige der bisher sehr ärgerlichen Probleme. So ermöglicht es beispielsweise, mehrere Versionen der gleichen Anwendung parallel zu installieren, ohne dass sich diese Versionen gegenseitig stören. Dabei wird auch gleich noch mit dem DLL-Hell genannten Problem aufgeräumt: Verschiedene Versionen der gleichen DLL können parallel installiert und verwendet werden. Das Problem, dass durch die Installation einer Anwendung eine andere nicht mehr funktioniert, gehört damit der Vergangenheit an. Zumindest für Programme, die innerhalb der .NET-Umgebung laufen.
Das normale Windows wird dadurch aber nicht einfach verschwinden. Es bildet die Grundlage, auf der .NET betrieben wird. Auf einem normalen Windows-PC werden dann also .NET-Programme und klassische Windows-Programme Seite an Seite laufen. Die klassischen Programme behalten dabei die altbekannten Probleme, die .NET-Programme laufen hoffentlich ohne zusätzlichen Wirrwarr ab.
Transparente Programmausführung
Der Betrieb eines .NET-Programms ist dabei aber völlig transparent. Anders als bei DOS-Programmen, die unter Windows betrieben werden, kann man einem .NET-Programm von außen nicht ohne Weiteres ansehen, dass es ein solches Programm ist. Fenster, Schaltknöpfe und alles Übrige sehen auch nicht anders aus als bei normalen Windows-Programmen. Zudem verbergen sich hinter dem Programm-Icon keine direkt ersichtlichen neuen Eigenschaften. Auf den ersten Blick sieht ein .NET-Programm auf der Festplatte also genauso aus wie ein klassisches Windows-Programm.
Durch die Installation der .NET-Umgebung auf einem Computer ändert sich auf dem System zunächst nichts. Die einzigen sichtbaren Merkmale sind zwei neue Einträge im Startmenü. Bei Windows XP tauchen diese beiden Einträge zum Beispiel im Menü "Verwaltung" auf.
Bei diesen beiden Einträgen handelt es sich um die Icons für den .NET-Framework-Assistenten und die .NET-Framework-Konfiguration. Um zu verstehen, wofür diese beiden Anwendungen gedacht sind, braucht man etwas Hintergrundwissen über einige Elemente von .NET.
Werden Programmteile mehrfach verwendet, liegen diese Teile meist in Form von DLL-Dateien auf der Festplatte vor. Früher enthielten diese Dateien tatsächlich direkt ausführbaren Code, der von außen angesprungen wurde. Das ist noch immer möglich, hat sich aber im Laufe der Zeit nachhaltig verändert. Heute sind DLL-Dateien häufig nur noch das Transportmedium für Objekte, die ihre Dienste und Funktionen zwar auch in Form von Programmcode in der DLL enthalten, aber nicht direkt angesprungen werden können. Stattdessen erzeugt ein Programm heute ein Objekt vom gewünschten Typ (das geht mit Hilfe von Programmcode aus der DLL) und fordert dieses dann auf, einen seiner Dienste oder Funktionen zur Verfügung zu stellen beziehungsweise auszuführen.
COM als Vorgänger von .NET
Die Bereitstellung von Objekten und deren Diensten und Funktionen ist mehr oder minder auch die Aufgabe von COM, einem der technologischen Vorgänger und Wegbereiter für .NET. Bei .NET enthalten DLLs weiterhin eines oder mehrere Objekte, aber auch eine ganze Menge an weiteren Informationen. Dazu gehört zum Beispiel eine Information über die Abhängigkeiten der Objekte in der DLL. Diese Informationen klären beispielsweise, welche Versionen anderer DLLs von einem gegebenen Objekt benötigt werden. Darüber hinaus ist es so, dass der Programmcode innerhalb einer DLL nicht alles darf, was der Programmierer dieses Codes unter Umständen wollte. Stattdessen hat der Besitzer des Rechners die Möglichkeit, dem Code innerhalb der DLL bestimmte Schranken vorzugeben. Wurde eine DLL nicht in ihrer Funktion eingeschränkt, nennt man das "der DLL wird vertraut".
Im Rahmen der Versionsvielfalt und der Sicherheit ist ein besonderer Teil der Vertrauensstellung der, in welcher Weise die DLL anderen Programmcode ausführen darf und in welcher Art und Weise sie Programmcode von anderen Orten kopieren darf. Sei das nun aus dem Internet oder aber von einem anderen Rechner im LAN: In solchen Fällen können der DLL die für das Kopieren benötigten Rechte verweigert werden.
Ferner können .NET-DLLs auch Ressourcen (Texte, Bilder, Bitmaps, Menüs) enthalten, und zwar gleich mehrere Versionen dieser Ressourcen für verschiedene Sprachen. Damit ist es im Prinzip ganz einfach möglich, ein Programm mit mehreren fest eingebauten Sprachen auszuliefern.
Im Sprachgebrauch von .NET heißen solche verwaltbaren DLLs, denen ein bestimmtes Maß an Vertrauen zugesprochen wird und die andere Zusatzinformationen enthalten "Assemblies".
Foto:
Die Assemblies befinden sich entweder ganz normal auf der Festplatte oder an einem speziellen Speicherort, dem so genannten Assembly-Cache. Dieser hat eine Reihe von Aufgaben, die wichtigste ist jedoch die Caching-Funktion, damit sich Assemblies schneller laden lassen.
Die beiden Programme, die im Zuge der .NET-Installation auf dem Rechner installiert werden, dienen der Verwaltung von Assemblies und zugeordneten Funktionen wie dem "Reparieren" der von .NET verwalteten Anwendungen.
.NET für Programmierer
Den größten Einfluss hat .NET auf jeden Fall auf die Programmierer - zumindest auf diejenigen, die sich darauf einlassen. Dafür gibt es eine Menge guter Gründe, nicht zuletzt die Verfügbarkeit einer riesigen Klassenbibliothek, die nicht nur die bisherigen Windows-Funktionen, sondern auch eine ganze Reihe an zusätzlicher Funktionalität zur Verfügung stellt.
Und zwar nicht in Form der über Jahre gewachsenen Win32-API mit all ihren zusätzlichen und drangebastelten Elementen wie OpenGL, DirectX und dergleichen, sondern eben in Form einer einheitlich strukturierten, objektorientierten Bibliothek.
Dabei kann man entweder die gewohnte Sprache weiterverwenden (zunächst gilt das für Visual Basic und Visual C++, weitere sollen aber folgen), oder man erlernt mit der Sprache C# eine neue, C++ und Java ähnliche Sprache. Außerdem gibt es von Microsoft einen Java-Compiler für .NET. Die grundsätzlichen Vorteile und Neuheiten, die man als Programmierer durch die Verwendung von .NET erhält, sind die folgenden:
Umfangreiche Klassenbibliothek als objektorientierte Windows-API
GUI-Anwendungen, Webanwendungen, XML-Dienste, Windows-Dienste und viele weitere Zielprojekte sind möglich
Einfache Entwicklung von exportierbaren Klassen, leichte Wiederverwendung von selbst definierten Objekten
Scripting-Support in der eigenen Anwendung
Compiler-Support auf dem Zielsystem
Optimierter Code für unterschiedliche Zielsysteme
Vereinfachungen bei Setup und Deployment
Cross-Language, Cross-Prozess-Debugging
Memory-Management mit Garbage Collection
Type-Checking, Range-Checking durch die Laufzeitumgebung
Die .NET-Klassenbibliothek
Die Klassenbibliothek des .NET-Framework ist das zunächst eindrucksvollste Novum. Einige tausend Klassen bieten die neue, komplett objektorientierte API für Windows. Dabei enthält die Klassenbibliothek Objekte für normale Aufgaben wie das Öffnen von Fenstern oder das Lesen und Schreiben von Dateien. Es finden sich aber auch Klassen für die Kommunikation im Internet, für das Lokalisieren von Anwendungen in mehrere Sprachen und so weiter und so fort. In Tausenden von Klassen kann man schon eine ganze Menge an Funktionalität unterbringen, und Microsoft hat sich viel Mühe gegeben, genau das zu tun.
Bisherige Klassenbibliotheken wie zum Beispiel die MFC (Microsoft Foundation Classes) deckten immer nur einen kleinen Teil der unter Windows möglichen Anwendungstypen ab. So war es mit der MFC beispielsweise nicht ohne Weiteres möglich, einen Windows-Service zu programmieren. Mit dem .NET-Framework können hingegen nicht nur alle "klassischen" Windows-Anwendungen wie Dienste, Kommandozeilen-Programme und GUI-Anwendungen entwickelt werden, sondern es werden obendrein eine ganze Reihe zusätzlicher Anwendungstypen ermöglicht. Dazu zählen zum Beispiel Webanwendungen oder XML-Dienste.
Einen XML-Dienst kann man sich dabei als ein Objekt vorstellen, dessen ausführbarer Code auf einem entfernten Rechner lebt, von dem aber Instanzen auf dem lokalen Rechner ganz so benutzt werden können, als würde sich der Code vor Ort befinden. Ein solcher Dienst wird zum Beispiel von Google angeboten. Verwendet man diesen Dienst, dann erhält man ein lokales "Google"-Objekt auf dem eigenen Rechner, das sich zur Suche im Google-Index verwenden lässt. Das lokale Objekt dient aber nur zur Kommunikation mit Google, die eigentliche Suche findet weiterhin auf dem Google-Server statt. Auf die Verwendung dieses Objekts hat das aber nicht den geringsten Einfluss, denn man verwendet das Objekt einfach so, als würde es sich dabei um lokal vorliegenden und ausführbaren Code handeln. Die Kommunikation zwischen dem lokalen und dem echten Google erfolgt dabei über XML - daher stammt die Bezeichnung.
Wiederverwendung mit .NET: Alle Objekte stehen zur Verfügung
Wer bisher mit C oder C++ programmiert hat und versuchte, seine Klassen oder Funktionen an dritter Stelle weiterzuverwenden, tat dies in Form von öffentlichen Header-Dateien und Bibliotheken. Dabei konnten die Bibliotheken entweder in Quell-Codeform oder in Form vorkompilierter Libraries vorliegen. Das hat seinen Vorteil - schließlich will man meist seinen eigenen Code wiederverwenden und hat daher auch nur wenig Probleme, dabei das "richtige" Werkzeug zu verwenden - sprich: den richtigen Linker.
Etwas modernere Varianten der Wiederverwendung fanden unter Windows bisher in Form von COM-Objekten statt. Dabei werden die Objekte in ihrer binären Form wiederverwendet, und Type-Libraries enthalten die benötigten Informationen für Compiler und Entwicklungsumgebung. Die Programmierung eines COM-Objekts ist allerdings ohne die Hilfe von Klassenbibliotheken sehr mühevoll. Bestehende COM-Objekte basieren meist auf einer Bibliothek wie MFC oder ATL.
Hinsichtlich der Wiederverwertung von Code kann man bei .NET problemlos von der "Fortsetzung von COM mit allen Mitteln" sprechen. Jedes, wirklich jedes, mit einer der .NET-Sprachen entwickelte Objekt lässt sich direkt wiederverwenden - und zwar in seiner binären Form. Dazu muss der Programmierer rein gar nichts tun, denn alle dazu benötigten Informationen werden von den CLR-Compilern automatisch erzeugt. Auch die verwendete Sprache ist hierbei gleichgültig. Benutzt der Compiler das CTS (Common Type System) - und das muss er, um Code für die CLR zu erzeugen -entstehen automatisch beim Übersetzen wiederverwendbare Komponenten. Diese sind dann in jeder .NET-Sprache verwendbar, egal ob es sich um VB.NET, VC++.NET, Javascript oder eine zukünftige .NET-Sprache handelt.
Das ist nicht nur nützlich, sondern auch extrem effizient, denn zusätzliche Arbeiten zum Erzeugen neuer Komponenten entfallen einfach, und die Wiederverwendung von Code ist ein Kinderspiel. Eigene Komponenten lassen sich einfach in das Entwicklungssystem einbetten und benutzen.
.NET und Scripting: Eingebaute Compiler verwenden
Nachdem man alle selbst programmierten Objekte problemlos wiederverwenden kann, ist es auch kein Wunder, dass es ebenfalls extrem einfach ist, die eigene Anwendung um Scripting-Möglichkeiten zu erweitern. Dazu verwendet man einfach den bei .NET mitgelieferten Scripting-Mechanismus, der von Haus aus mit Javascript und VBScript klarkommt. Alternativ kann man auch einfach Scripts in C# akzeptieren und deren Quellcode on Demand übersetzen, da der in die Laufzeitumgebung integrierte Compiler ebenfalls als wiederverwendbare Komponente zur Verfügung steht.
Das versetzt den Programmierer in die Lage, seine eigene Anwendung so zu erweitern, dass Anwender eigene Methoden und Programme innerhalb der Anwendung schreiben könnten. Mit ein wenig zusätzlichem Code können die Anwender dann ebenfalls die für das Programm implementierten Klassen verwenden. Erweiterbare Anwendungen sind damit so einfach zu haben wie noch nie.
Das Beste daran: Anders als beim Automationsmechanismus muss auch hier kein eigener Code geschrieben werden - die Scripts der Anwender benutzen einfach die Objekte, die der Programmierer der Anwendung auch verwendet hat.
Die Sprachen VB.NET, C# und Javascript sind Teil der .NET-Laufzeitumgebung. Das bedeutet auch, dass jeder Anwender, der diese Laufzeitumgebung installiert hat, über die entsprechenden Compiler verfügt. Zwar stehen diese nicht in Form von Kommandozeilen-Compilern bereit (die kann man aber in Form des .NET-SDKs umsonst erhalten), sondern nur in Form von Compiler-Services, die per Programm-Code angeworfen werden müssen. Wer aber schon immer ein Interesse daran hatte, auf dem Zielsystem beim Anwender Code zu übersetzen, kann das mit .NET nun tun.
Setup Compilation: Optimierter Code für unterschiedliche Zielsysteme
Beim Übersetzen von .NET-Anwendungen wird kein nativer Code erzeugt - zumindest nicht, wenn man sich nicht ausdrücklich darum bemüht. Stattdessen erzeugen die Compiler so genannten MSIL-Code (Microsoft Intermediate Language). Dieser wird erst beim Laden der Anwendung auf dem Zielsystem in nativen Code umgewandelt. In der Praxis bedeutet das, dass die Eigenschaften des Zielsystems deutlich besser ausgenutzt werden können: Liegt eine Pentium-2-CPU vor, so können spezielle Optimierungen für diese CPU vorgenommen werden - ist es ein P4, dann fällt die Optimierung entsprechend anders aus.
Ein ebenso interessanter Nebeneffekt ist dabei die Tatsache, dass die Codegeneratoren beim Laden der Anwendung auch weitere Informationen über das Zielsystem berücksichtigen können. So lassen sich etwa unterschiedliche Optimierungen abhängig von der vorhandenen Speichermenge oder anhand der bereits geladenen Module durchführen. An dieser Stelle ist noch viel von zukünftigen Versionen des .NET-Framework und der zugehörigen Codegeneratoren zu erwarten. Langsamer wird der Code dadurch sicherlich nicht.
Wer sich daran stört, dass die Übersetzung jedes Mal beim Laden der Anwendung stattfindet, kann natürlich entweder weiterhin nativen Code für ein festes Zielsystem erzeugen oder auf ein Feature zurückgreifen, das sich Setup Compilation nennt. Dabei wird die Anwendung während der Installation in nativen Code umgewandelt. Der Vorteil ist, dass die Übersetzung beim Starten entfällt und die Zielumgebung dennoch beim Erzeugen des Binary berücksichtigt werden kann. Diese Art der Übersetzung wird sich zumindest zu Beginn der Verbreitung von .NET mit Sicherheit als Standard durchsetzen. Allerdings berücksichtigt diese Variante Systemänderungen nach der Installation nicht.
.NET-Programme sind von Haus aus autark: Sofern der Programmierer nichts Gegenteiliges unternimmt, lässt sich eine .NET-Anwendung einfach per XCOPY installieren. Verzeichnis anlegen - Dateien hineinkopieren und fertig. Änderungen an der Registry sind nicht notwendig, und auch Konfigurationsdateien können im Prinzip einfach mitkopiert werden.
Die Software-Entwicklung als solche bietet ebenfalls deutlich mehr Möglichkeiten, denn .NET-Anwendungen können sich über mehrere Sprachen, mehrere Prozesse und mehrere Rechner verteilen. Der Source Level Debugger macht dabei alles mit: Egal ob ein Kontextwechsel zwischen Sprachen, Prozessen oder Rechnern stattfindet - es kann per Single-Step im Quellcode nach Fehlern gesucht werden.
Der Garbage Collector: Drastisch vereinfachtes Speicher-Management
Beim .NET-Framework wird die Speicherverwaltung durch die Laufzeitumgebung gehandhabt. Das wird alle C- und C++-Programmierer zunächst sehr erschrecken, aber der Schreck ist eher ungerechtfertigt. Die Laufzeitumgebung ist dabei nicht nur sehr effizient, sondern in vielen Fällen sogar schneller als die nativen Mechanismen zur Speicherverwaltung, die in C und C++ verwendet werden. Das deutlich angenehmere Programmieren, das der Garbage Collector ermöglicht, wiegt die Nachteile der geringeren Kontrolle mehr als auf - und wer in speziellen Fällen trotzdem nicht auf eigene Mechanismen verzichten will, wird nicht davon abgehalten, "unmanaged" C++-Code an den passenden Stellen zu verwenden.
Alles in allem bietet .NET nicht nur eine extrem komfortable Klassenbibliothek und dank des Garbage Collector ein völlig neues Programmiergefühl, sondern es macht in der Praxis auch wirklich Spaß, damit zu arbeiten. Für Anwender löst .NET mittelfristig das Versionsproblem mit DLLs - und Administratoren können deutlich mehr Einfluss darauf nehmen, welche Programme welche Funktionen ausüben dürfen oder nicht. (mha)
Das beschließt den ersten Teil unserer Reihe über Microsoft .NET. In loser Folge werden wir uns mit der Programmierung von .NET im Allgemeinen und der Programmierung von C# im Speziellen beschäftigen.