.Net-Framework

.NET (gesprochen dott-nett) ist ein Satz von Softwaretechnologien des Softwareherstellers Microsoft, der als Gegenpol zu Sun Microsystems Java eingeführt wurde, und neben einer virtuellen Laufzeitumgebung aus einem Rahmenwerk (Framework) von Klassenbibliotheken (API) und Diensten besteht, die als Basis für Eigenentwicklungen dienen. Einfach gesprochen handelt es sich also um eine umfangreiche Programmierumgebung, die eine neue Generation von Programmen und damit auch der Programmierung einläuten soll. Praktisch keine der verwendeten Technologien ist völlig neu, aber in der Gesamtheit ist .NET (auch Kritiker können dies zumindest für die "Microsoft Welt" kaum leugnen) eine Innovation.

Entstehung und Historie

Historisch gesehen ist die Motivation für diese Initiative am ehesten verständlich. Durch die immer weitere Verbreitung der plattformunabhängigen Programmiersprache Java Ende der 1990er Jahre, sah Microsoft seine Dominanz im Bereich der PC-Kerntechnologien in Gefahr. Zudem war es Microsoft bis dahin nicht gelungen, im lukrativen Markt für mobile Kleingeräte Fuß zu fassen.

Microsoft übernahm die von Sun entwickelte Java-Technologie für sich und erweiterte sie nach den eigenen Bedürfnissen, worunter die Plattformunabhängigkeit litt. Als Sun dies unter anderem durch Gerichtsverfügung unterband, wechselte Microsoft die Strategie. Um eine vollständige Unabhängigkeit von anderen zu erreichen, sollte die .NET-Plattform von Grund auf neu entwickelt werden.

Da gleichzeitig anerkanntermassen die technologische Basis der Windows-Programmierung, nämlich die Objekttechnologien COM und DCOM ihre Grenzen erreicht hatten, addierte sich der vom Marketing getriebene Wunsch nach einer konkurrenzfähigen Technologie "gegen" Java und nicht zuletzt Linux mit technisch notwendiger (bis hin zu stellenweise "technikverliebter") Innovation zu einem gemeinsamen Projekt.

Eher untypisch für Microsoft wurden nämlich auch eine Reihe der prominentesten externen Fachleute, die sich in der Windows Welt einen Namen gemacht hatten, zu Microsoft geholt, was sich an vielen Stellen in der technischer Qualität und Innovation niederschlug und auch die Akzeptanz in der Entwicklergemeinde erhöhte. So wurde die neue .NET Sprache C# federführend von dem Turbo Pascal Erfinder Anders_Hejlsberg entwickelt. Die verschiedenen Teiltechnologien wurden in mehreren weitgehend unabhängigen Gruppen entwickelt, wodurch die Entwicklungsgeschwindigkeit wohl erhöht, die Durchgängigkeit des Konzepts an vielen Stellen aber verschlechtert oder verhindert wurde.

2000, Juni - Bill Gates stellte erstmals die .NET "Vision", zunächst unter dem Codenamen "Whistler

2000, Juli - Auf der Entwicklerkonferenz PDC gab es erstmals CDs mit lauffähigen Vorabversionen des Frameworks und von Visual Studio .NET

2000, Oktober - C# und die [CLI] (s.u.) wurden (von MS, HP und Intel) bei der Europäischen Standardisierungorganisation European Computer Manufacturers Association ECMA eingereicht, was für Microsoft einen ungewöhnlichen Schritt der Öffnung darstellte.

2002, Januar - .NET (V1.0) wurde offiziell mit der zugehörigen Entwicklungsumgebung SDK (und Visual Studio 2002) vorgestellt.

2001-2002 Verwirrung: Im Zuge des Marketings wurde nach Microsofts Gewohnheit versucht, alle anstehenden Neuentwicklungen unter einen, den .NET Begriff zu fassen, wodurch selbst Fachleute inkl. Microsoft Mitarbeitern nicht mehr verstanden, worum es eigentlich ging. Die Programmiertechnologie und Entwicklungsumgebung wurde erstens in Verbindung gestellt zu konkreten Webdiensten, die Microsoft anbot (Codename "Hailstorm" wurde zu ".Net My Services" und später vom Marketing wieder von .NET entkoppelt). Auch die nächste Betriebssystem Generation von Windows wurde als Bestandteil von .NET angekündigt. Interessant ist hier die Begriffs-Historie beim Server:
- 2000, Januar: Codename "Whistler Server"
- 2001, 30. April: Windows 2002 Server
- 2001, 19. Juni: Windows .NET Server
- 2002, 27. August: Windows .NET Server 2003
- 2003, 9. Januar: Windows Server 2003 (wieder ohne .NET)

2003 Vorstellung von .NET 1.1 und Visual Studio 2003 mit im wesentlichen geringfügigen Verbesserungen und Erweiterungen.

2004 Obwohl technisch schon einige Jahre alt, steht der Marktanteil an .NET Programmen steht immer noch in keinem Verhältnis zur Aufmerksamkeit in Medien und Entwicklergemeinde. Insbesondere auch Microsoft selbst hat keine, in der Breite bekannten, komplett mit .NET programmierten Anwendungen veröffentlicht, was sicherlich auch Zeit und Aufwand demonstriert, die technische Umstellungen benötigen.

2004 Betaversionen von .NET V2.0 und Visual Studio 2005 erhältlich.

Ausblick:

Für 2005 ist die nächste Version, .NET V2.0 und Visual Studio 2005 angekündigt, die neben starken Erweiterungen der Klassenbibliothek einige Vereinfachungen des Programmiermodells mit sich bringen soll.

2006-2007 Nachfolgetechnologien als Bestandteil des Windows XP Nachfolgers mit Codenamen "Longhorn" sollen die Redundanzen in aktuellen .NET Teiltechnologien beseitigen, insbesondere die APIs zur Web- und Windows-Oberflächenprogrammierung vereinheitlichen und ein einheitliches Konzept für verteilte und insbesondere Serviceorientierte Architekturen bereitstellen und damit das weithehend unstrukturierte Nebenher von "Web Services", ".NET Enterprise Services" und ".NET Remoting Services" beseitigen.

Konzept

Die .NET-Plattform stellt mit der Common Language Infrastructure (CLI) eine Basis zur Ausführung von Programmen, die mit unterschiedlichen Programmiersprachen erstellt wurden, her. Dies wird durch und die Verwendung einer (objektorientierten) virtuellen Maschine und die Framework Class Library (FCL) - eine gemeinsame Klassenbibliothek erreicht.

Runtime (CLR), MSIL, Garbage Collection und Reflection

Die Common Language Runtime (CLR) ist die virtuelle Maschine (VM)von .NET und stellt somit die Laufzeitumgebung für verschiedene an .NET angepasste Hochsprachen zur Verfügung. Die VM führt den standardisierten Bytecode der Microsoft Intermediate Language (MSIL), aus. Hierfür wurde ein sprachübergreifendes System von objektbasierten Datentypen definiert, so dass auch in unterschiedlichen Sprachen geschriebene Programmteile auf gemeinsame Ressourcen zugreifen können. Dies unterscheidet .NET von anderen auf Bytecode basierenden Laufzeitumgebungen (z.B. Java Virtual Machine), so genannten virtuellen Maschinen.

Das Besondere an der CLR ist weniger die technische Innovation als vielmehr die strategische und (langfristig vielleicht folgenreichste) Entscheidung des Marktführers Microsoft für ein runtime-basiertes System, welches u.a. Programmierfehler vermindern hilft und gegen traditionelle reine Compilierung (in Maschinencode). Einer der ältesten Streitpunkte der Programmiererzunft scheint damit (vorläufig) durch die vereinigte Marktmacht von Java und Microsoft/.NET entschieden. Insbesondere Garbage Collection sowie die Analyse und Veränderung von Programmen per Programm (wie in Java Reflection genannt), sind Mechanismen, die noch keinen Eingang in die meisten kommerziellen Softwareprojekte außerhalb der Java-Welt gefunden hatten.

Performance

Die Entwicklergemeinde von C/C++ für C# zu gewinnen, ist nicht zuletzt nötig, um .NET zum Erfolg zu verhelfen. [Performance] war bei .NET und insbesondere C# von Anfang an deswegen ein wesentliches Designkriterium. Dies ist ein wesentlicher Unterschied zu Java. Dort war und ist eines der obersten Designziele die Plattformunabhängigkeit, welches zumindest historisch die Performance als Ziel in den Hintergrund rücken ließ. (Damit soll jedoch kein Geschwindigkeitsvergleich zwischen beiden angestellt werden, der erstens noch viel umstrittener ist, als der oben erwähnte Punkt, und zweitens sicher je nach Projektdetails und (auch zukünftiger) Sprachgeneration verschieden ausfallen wird.)

managed und unmanaged, Interoperabilität

In der .NET Sprache gelten alle Programme, die innerhalb der CLR laufen, also für .NET geschrieben wurden, als managed, alle anderen, insbesondere ältere Programme, damit quasi abwertend, als unmanaged. Mit Hilfe der sogenannten "Interop" Technik, lassen sich insbesondere traditionelle (Microsoft) COM Programme mit .NET Hüllen (sog. Wrappern) versehen, und danach deren Klassen wie .NET Klasse aufrufen, als auch umgekehrt .NET Klassen wie COM Klassen aufrufen. Damit soll eine fließende Umstellung von Projekten auf .NET ermöglicht werden.

Die bisher einzige Sprache, mit der man sowohl managed als auch unmanaged Code in einer einzigen Programmdatei mischen kann, ist C++ Managed C++.

Sicherheit

Eines der vermutlich wichtigsten Konzepte ist das Sicherheitskonzept von .NET, welches weit über das bisher in Windows verankerte oder etwa das von Java hinaus geht. Es ist denkbar, dass dieses Sicherheitskonzept mittelfristig zunehmend das wesentliche Entscheidungsmerkmal kommerzieller und sicherheitskritischer Anwendungen allgemein zugunsten von .NET etwa gegenüber traditioneller C++ oder VB Programmierung sein wird.

Das Sicherheitskonzept von .NET fängt an bei Mechanismen, die die Identität des Programmherstellers gewährleisten sollen (Authentizität, geht über Mechanismen zum Schutz der Programme vor Veränderung (z.B. vor Programmviren) bis hin zu Schutzmechanismen, die den Ort der Herkunft bzw. Programmausführung (z.B. Internet) einbeziehen. Es gibt technisch betrachtet sowohl ein codebasiertes (Code-based-Security) als auch ein nutzerbasiertes Role-based-Security Sicherheitsmodell. Spezialisten stoßen allerdings insbesondere bei der Web- und Datenbankprogrammierung unter .NET auf bis zu ein halbes Dutzend alternativer und ergänzender Sicherheitsmodelle von Betriebssystem, Runtime, Datenbank und Webserver.

Assemblies

Übersetzte Programmklassen werden als ausführbare Programme in so genannten Assemblies zusammengefasst und bereitgestellt (vgl. mit Packages/Paketen in Java). Diese haben typischerweise die altbekannten Endungen .exe oder .dll, sind intern jedoch völlig anders strukturiert. Insbesondere sind im sogenannten Manifest alle notwendigen Metadaten aufgeführt, so dass für reine .NET Programme in der Regel die gewohnte, aber aufwendige und fehlerträchtige Registrierung (siehe Registry), wegfällt (Ausnahme z.B. COM+/Enterprise Services).

Attribute

Eine, wenn auch zunächst rein programmiertechnisch interessante, Neuerung von .NET ist die Einführung von Attributen, d.h. als solche gekennzeichnete Metadaten als Bestandteil der Programmiersprache. Beispielsweise können im Rahmen der komponentenbasierten Programmierung Komponenteneigenschaften ausgedrückt werden, es können für das Deployment und die Sicherheit, für Transaktionen und viele andere Anwendungen dem Code beschreibende Eigenschaften hinzugefügt werden, usw. Aufgrund des überzeugenden Konzepts wird hier Java von .NET abgucken, woran man sehen kann, dass ein sich gegenseitig befruchtender technischer Wettbewerb zum Nutzen der Kunden in Gang ist.

Verteilte Programmierung und Web Services

Konzepte der verteilten Programmierung ... wird fortgesetzt --Philip Erdös 03:29, 27. Jul 2004 (CEST)

Sprachneutralität und Gemischtsprachige Programmierung

Die Common Language Specification (CLS) definiert eine gemeinsame Untermenge Binärcode der MSIL, der von der virtuellen Laufzeitumgebung (VM) in den Maschinencode der Zielmaschine übersetzt und ausgeführt werden kann. Somit ist es möglich, .NET mit verschiedenen, an die CLR angepassten Sprachen zu programmieren. Beispielsweise sind das, neben der von Microsoft für .NET eingeführten Sprache C#, die Sprachen C++, das proprietäre Visual Basic .NET und das proprietäre J# (Aussprache: dschäi-scharp; eine Portierung von Microsofts Java-Implementierung). Eine Beispielliste

Insbesondere das Common Type System, welches eine gemeinsame Schnitttmenge an Datentypen beschreibt, sorgt etwa für eine reibungslose Parameterübergabe beim Aufruf von Funktionen einer anderen Sprache.

Während viele Stimmen verständlicherweise in der gemischtsprachigen Programmierung für sich keinen Vorteil sehen, wird jedoch umgekehrt ein Vorteil daraus, wenn man historisch die durch komponentenbasierte Programmierung eingetretene Mischung von Visual Basic und C++ auf der Microsoft Plattform COM/DCOM betrachtet. Immerhin ist Visual Basic die am häufigsten verwendete Programmiersprache der Welt, so dass sowohl die verbesserte Kooperation zwischen C#, Visual Basic .NET (und Managed C++) als auch die verbesserten und durch .NET vereinheitlichten Möglichkeiten zur objektorientierten Programmierung in Visual Basic .NET alleine einen Schritt nach vorne in der durchschnittlich zu erwartenden Softwarequalität darstellen.

Weitere .NET-Sprachen werden von Drittanbietern zur Verfügung gestellt (z.B. Delphi von Borland).

Fast unerwartet scheint der Anklang der .NET Technologie bei Anbietern marktenger Programmiersprachen oder in Forschung und Lehre. Für eine beispielhafte Übersicht vieler Projekte zu .NET Programmiersprachen sei verwiesen auf [1].

Offensichtlich ist gerade für solche Programmiersprachen die zusätzliche Funktionalität einer umfangreichen (wenn auch zunächst für das marktführende Betriebssystem optimierten) Klassenbibliothek interessant und produktivitätsfördernd.

Plattformunabhängigkeit

Die angestrebte Plattformunabhängigkeit ist unter .NET bisher kaum gegeben, da der Hersteller Microsoft die .NET-Plattform nur für seine eigene Produktlinie Windows anbietet. Eine Laufzeitumgebung (CLR, VM) für das Betriebssystem Linux (und deren Derivate) steht aber, dank CLS, in Form des Open-Source-Projektes Mono zur Verfügung, das vom Hersteller Ximian initiiert wurde. Da sich dieses Projekt aber noch in der Entwicklung befindet (Stand: September 2003) und nicht alle Komponenten von .NET zur Verfügung stehen, ist mit einer hohen Verbreitung auf Windows-fremden Systemen nicht zu rechnen. Daneben wird noch im Rahmen des dotGNU-Projekts an einer Portable.NET genannten Laufzeitumgebung gearbeitet.

Wegen der fehlenden Betriebssystem-Unterstützung von Windows-fremden Systemen seitens Microsoft, fehlender (freier) Entwicklungsumgebungen, fehlender Normierung der Klassenbibliothek sowie lizenzrechtlicher Probleme kann man Plattformunabhängigkeit in der Praxis deshalb nicht attestieren. Unter dem Aspekt der plattformübergreifenden Verfügbarkeit dominieren hier auch weiterhin Java-Programme, Umsetzungen mit Sprachen wie Perl und PHP - sowie maschinennahe Produkte, die typischerweise mit Sprachen wie C und C++ erstellt werden.

Laufzeitumgebung

"Managed code" wird wie oben erwähnt von der Laufzeitumgebung Common Language Runtime (CLR) verwaltet. Diese virtuelle Maschine (VM) übernimmt die Anforderung und Freigabe von Speicher und anderen Ressourcen (Garbage-Collection) und stellt sicher, dass geschützte Speicherbereiche nicht direkt angesprochen oder überschrieben werden können. Auch Zugriffe auf Dienste, Dateisystem-Funktionen oder Geräte werden kontrolliert und können, sofern sie gegen Sicherheitsrichtlinien verstoßen, von der CLR abgelehnt werden (Sandbox-Prinzip).

Geschwindigkeit

Durch verschiedene Techniken wird versucht, den negativen Einfluss der Runtime auf die Programmgeschwindigkeit möglichst klein zu halten. Z.B. wurden analog zu Java sogenannte "Just-in-time"-Compiler eingeführt, die einen Mittelweg zwischen Interpretation und Compilierung gehen. Des weiteren kann man mit .NET als Neuerung auch Programme in bereits kompiliertem Maschinencode vorinstallieren, wodurch sich insbesondere (und nur) die erstmaligen Ladezeiten bei Programmen mit größeren Klassen- und Objektmengen reduzieren.

Die automatische Ressourcenverwaltung und die verbesserte Sicherheit haben dennoch auch ihren Preis - die Ausführung von managed code hat einen erhöhten Bedarf an Ressourcen und benötigt geringfügig mehr Zeit. Außerdem sind die Antwortzeiten auf Programm-Ereignisse wesentlich schwieriger zu kalkulieren und zum Teil deutlich größer, was die Anwendbarkeit für Echtzeitaufgaben stark einschränkt.

Ein Grund hierfür ist die "Garbage-Collection" (englisch für Müllsammlung bzw. Müllabfuhr), die automatische Freigabe nicht mehr benötigten Speichers und anderer Ressourcen. Zu beachten ist hierbei, dass die Freigabe nicht direkt erfolgt, sondern der Garbage-Collector der CLR über den Zeitpunkt entscheidet. Während dies einerseits, durch die Zusammenfassung der Freigabeoperationen, die Ausführungsdauer von Programmläufen verringern kann, können andererseits die Antwortzeiten auf Ereignisse dadurch in Mitleidenschaft gezogen werden. Durch die zeitverzögerte Freigabe entsteht auch ein erhöhter Ressourcenbedarf. Dies ist natürlich besonders für kleinere Maschinen nachteilig, und stellt deshalb, im Hinblick auf die Marktausrichtung zu mobilen Kleingeräten, ein Problem dar. Prinzipiell ist aber beispielsweise in C# für zeitkritische Teile die Garbage-Collection ausschaltbar (Schlüsselwort unsafe) oder eine eigene Freigabeverwaltung für Ressourcen aller Art programmierbar (dispose, GC.SuppressFinalize).

Auf der einen Seite wird deswegen die Meinung vertreten, dass weiterhin eine große Anzahl von außerhalb der CLR betriebene Anwendungen benötigt werden wird, wenn es um die Erstellung laufzeitkritischer Anwendungen geht (Animation, Simulation, Bildverarbeitung, direkte Zugriffe auf Dateisysteme und Geräte, Treiberprogrammierung, 3D-Spieleprogrammierung, KI-Anwendungen, sicherheitsrelevante Anwendungen wie Anlagensteuerungen, usw.). Dies hat das VM-basierte .NET auch mit Systemen wie der Java-Plattform gemeinsam.

Auf der anderen Seite steht die Meinung, dass durchschnittliche Qualität und Effizienz der traditionellen Softwareentwicklung zu wünschen übrig ließen und lassen, und das die diesbezüglichen Vorteile durch obige Verfahren deren Nachteile in der Regel aufwiegen. Im allgemeinen wird dabei von einer asymmetrischen Verteilung ausgegangen, dass z.B. 90 % einer durchschnittlichen Anwendung problemlos "managed", d.h. auch mit Garbage-Collection ausgeführt werden können, und lediglich 10% (dann einzelner Funktionen oder Klassen) optimiert werden müssen. Dabei hat sich, analog zu den Diskussionen "Assembler- ja oder nein", gezeigt, dass oftmals durch Optimierung zugrundeliegender Algorithmen und Datenstrukturen eine wesentlich höhere Performance als durch die Entscheidung für oder gegen eine Programmiersprache oder Programmiertechnik erzielt werden kann. Und gerade für derlei ständige Optimierungen bewährt sich eine zuverlässige automatische Speicherverwaltung oft über Jahre, bevor man hier die Grenzen erreicht hat. Nicht zuletzt können Programme auch in Hinblick auf die Performance mit Garbage Collection optimiert werden. Manche Programme erzielen sogar ohne Optimierung mit Garbage Collection um Faktoren höhere Geschwindigkeiten als ohne' (letztere etwa mit traditioneller C Speicherallokierung). Des weiteren wurden speziell für objektorientierte Programmierung bei C# und Java gegenüber C++ auch oftmals Geschwindigkeitsvorteile gezeigt.

Klassenbibliothek

Die Framework Class Library (FCL) umfasst einige Tausend Klassen, die in so genannte Namensräume (Namespaces) unterteilt sind. Die Klassen erfüllen Aufgaben wie z.B. das Formatieren von Text, das Verschicken von Mails, aber auch das Generieren von Code. Die Unterteilung in Namensräume dient dazu, die große Menge an Informationen übersichtlicher zu gestalten. Beispielsweise befinden sich Klassen zum Generieren von Code in dem Namensraum System.Reflection.Emit.

Die Dokumentation der Klassen liefert der Hersteller in seinem "Software Development Kit" (SDK) mit (siehe unten).

Verfügbarkeit

Der Hersteller Microsoft bietet .NET in verschiedenen Formen an. Als reine Laufzeitumgebung samt benötigter Klassenbibliotheken (Framework), als kostenloses SDK für Entwickler, als kostenpflichtige integrierte Entwicklungsumgebung (Integrated Development Environment, IDE) in Form des "Microsoft Visual Studio .NET".

Seit "Windows Server 2003" bietet Microsoft darüber hinaus Server-Betriebssysteme an, die eine bereits integrierte .NET Laufzeitumgebung bereitstellen. Bei Vorversionen muss die Laufzeitumgebung manuell installiert werden, sofern sie zu einer unterstützten Windows-Variante gehört. Unter Windows 3.1 ist .NET nicht lauffähig, auf Windows 95/98/Me/NT jeweils nur mit bestimmten Einschränkungen, die Programmierung von Webanwendungen (ASP.NET) etwa läuft nur ab Windows 2000. Auf Nicht-Windows-Systemen wird .NET von Microsoft offiziell nicht unterstützt - ist also nur in der Theorie plattformunabhängig. Allerdings existieren die bereits erwähnten Open-Source-Projekte, die .NET auch für andere Plattformen (z.B. Linux) eingeschränkt verfügbar machen. Für Handhelds und Mobiltelefone, die unter Windows CE bzw. Windows Mobile 2003 laufen, existiert eine abgespeckte Version der .NET-Laufzeitumgebung in Form des Compact Frameworks. Es läßt sich aber nur unter Verwendung des kostenpflichtigen Visual Studio .NET 2003 oder neuer für diese Plattform entwickeln. Mit Visual Studio 2005 sind für Privatanwender kostenlose Einfachversionen erhältlich (ab Juli 2004 in Vorabversion).

In Arbeit