Dot Net
aus Wikipedia, der freien Enzyklopädie
| .NET Framework | |
|---|---|
 |
|
| Basisdaten | |
| Entwickler: | Microsoft |
| Aktuelle Version: | Version 3.0 (6. November 2006) |
| Betriebssystem: | Version 1.x: ab Windows NT 4.0 Version 2.x: ab Windows 98 Version 3.x: ab Windows XP Service Pack 2 |
| Kategorie: | Plattform |
| Lizenz: | Proprietäre Software |
| Deutschsprachig: | ja |
| Website: | http://www.microsoft.de/msdn/netframework/ |
.NET [ˈdɔtnɛt] ist eine Plattform für Programme, die mit unterstützenden Programmiersprachen entwickelt wurden. .NET ist eine Technologie, die verschiedene Betriebssystem-Funktionen zusammenfasst und an einem zentralen Punkt anbietet und soll veraltete Technologien und Vorgehensweisen der Programmierer, wie z.B. COM oder API-Aufrufe im Programmcode, ersetzen.
Microsoft entwickelte die Plattform als Umsetzung (Implementierung) des Common-Language-Infrastructure-Standards für Windows.
Sie besteht neben einer Laufzeitumgebung aus einer Sammlung (Framework) von Klassenbibliotheken (API) und aus angeschlossenen Diensten, die gemeinsam eine Basis für Eigenentwicklungen bieten.
[Bearbeiten] Entstehungsgeschichte
Die Motivation für die Initiative .NET ist aus ihrer Historie 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 adaptierte die von SUN entwickelte Java-Technologie und erweiterte sie nach den eigenen Bedürfnissen, was die Plattformunabhängigkeit von Java-Applikationen beeinträchtigte. 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.
Zu dem Wunsch nach einer konkurrenzfähigen Technik „gegen Java“ gesellte sich eine überfällig gewordene technische Innovation: Die technologische Basis der Windows-Programmierung, nämlich die Objekttechniken COM und DCOM, hatten ihre Grenzen erreicht. So entstand ein aus vermarktungsstrategischen Überlegungen und technischer Notwendigkeit motiviertes gemeinsames Projekt.
Eine Reihe der prominentesten externen Fachleute, die sich in der Windows-Welt einen Namen gemacht hatten, wurden zu Microsoft geholt, was sich an vielen Stellen in der technischen Qualität und Innovation niederschlug, aber auch die Akzeptanz in der Entwicklergemeinde erhöhte. So wurde zum Beispiel die neue .NET-Sprache C# federführend von Turbo-Pascal-Autor Anders Hejlsberg entwickelt. Die verschiedenen Teiltechnologien wurden in mehreren weitgehend unabhängigen Gruppen entwickelt, wodurch die Entwicklungsgeschwindigkeit wohl erhöht, die Homogenität der verschiedenen Bereiche aber verschlechtert oder verhindert wurde (siehe Ausblick).
- 2000, Juni – Bill Gates stellt erstmals die .NET-„Vision“ vor.
- 2000, Juli – Auf der Entwicklerkonferenz PDC gibt es erstmals CDs mit lauffähigen Vorabversionen des Frameworks und von Visual Studio .NET
- 2000, Oktober – C# und die CLI (siehe unten) werden (von MS, HP und Intel) bei der Europäischen Standardisierungsorganisation European Computer Manufacturers Association (ECMA) eingereicht, was für Microsoft einen ungewöhnlichen Schritt der Öffnung darstellt.
- 2002, Januar – .NET (V1.0) wird offiziell mit der zugehörigen Entwicklungsumgebung SDK (und Visual Studio .NET 2002) vorgestellt.
- 2001–2002 – Verwirrung: Im Zuge des Marketings wird nach Microsofts Gewohnheit versucht, alle anstehenden Neuentwicklungen unter einen, den .NET-Begriff, zu fassen, wodurch selbst Fachleute einschließlich Microsoft-Mitarbeiter nicht mehr verstehen, worum es eigentlich geht. Die Programmiertechnologie und Entwicklungsumgebung wird erstens in Verbindung gestellt zu konkreten Webdiensten, die Microsoft anbietet (Codename „Hailstorm“ wird zu „.Net My Services“ und später vom Marketing wieder von .NET entkoppelt). Auch die nächste Betriebssystem-Generation von Windows wird 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 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.
- 2005 Betaversionen von .NET V2.0 und Visual Studio 2005 erhältlich.
- 2005, 7. November: Release Visual Studio 2005 und .NET Framework 2.0. in den USA
- 2005, 19. Dezember: Deutsche Version des .NET Frameworks 2.0 verfügbar
- 2006, 6. Februar: Release Visual Studio 2005 in Deutschland
- 2006, 6. November: Final des .NET Frameworks 3.0 verfügbar
- Ende 2007: .NET Framework 3.5 mit Visual Studio Codename „Orcas“
- ca. 2009: .NET Framework 4.0 (Quelle: WebCast zur C++/CLI Serie 2006 von Bernd Marquardt)
[Bearbeiten] 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 die Verwendung einer (objektorientierten) virtuellen Maschine und der Framework Class Library (FCL) – einer gemeinsamen Klassenbibliothek – erreicht.
[Bearbeiten] CLR, CIL 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 und kann als Pendant zur Java Virtual Machine bei Java gesehen werden. Die VM führt den standardisierten Zwischencode der Common Intermediate Language (CIL) aus, das Pendant zum Bytecode bei Java. Die CIL hieß früher Microsoft Intermediate Language (MSIL), wurde aber im Rahmen der Standardisierung durch die ECMA umbenannt. Für die CIL wurde ein sprachübergreifendes System von objektbasierten Datentypen definiert, so dass auch in unterschiedlichen Sprachen geschriebene Programmteile auf gemeinsame Ressourcen zugreifen können. Was .NET von anderen auf Zwischencode basierenden Laufzeitumgebungen (zum Beispiel der Java Virtual Machine) signifikant unterscheidet, ist das von Beginn an im Gesamtkonzept berücksichtigte Nebeneinander mehrerer Programmiersprachen.
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 laufzeit-basiertes System, das unter anderem Programmierfehler vermindern helfen soll und gegen die traditionelle direkte Kompilierung in den Maschinencode des Zielsystems. Zusammen mit der Marktmacht von Java und dem Erfolg der sogenannten Skriptsprachen ist hiermit ein Trend zu identifizieren. Dieser stellt einen als historisch zu bezeichnenden Bruch mit der noch wenige Jahre zuvor, zumindest in der kommerziellen Softwareentwicklung, vorherrschenden Dominanz der direkt in Maschinencode kompilierenden Programmiersprachen (insbesondere C++ und C) dar. Anders ausgedrückt ist dies ein Schritt weg von der Performance zur Programmlaufzeit um jeden Preis und hin zur Erhöhung der Effizienz in der Programmentwicklung.
Mittels Reflection ist es insbesondere mit dem Emit()-Mechanismus möglich, zur Laufzeit Programmcode über ein Objektmodell zu generieren und es in-Memory in eine lauffähige Assembly zu überführen. Diese Technik wird unter anderem von ASP.NET genutzt sowie einigen anderen Mechanismen wie zum Beispiel der Geschwindigkeitsoptimierung regulärer Ausdrücke. Zudem ist es möglich zur Laufzeit Skriptcode dynamisch zu kompilieren und einzubinden.
[Bearbeiten] Managed und Unmanaged, Interoperabilität
In der .NET-Terminologie gelten alle Programme, die innerhalb der CLR laufen, also für .NET geschrieben wurden, als managed, alle anderen als unmanaged. Mit Hilfe der sogenannten Interop-Technik lassen sich insbesondere traditionelle (Microsoft-)COM-Programme mit .NET-Hüllen versehen und danach deren Klassen wie .NET-Klassen aufrufen. Umgekehrt lassen sich auch .NET-Klassen wie COM-Klassen aufrufen. Damit soll eine fließende Umstellung von Projekten auf .NET ermöglicht werden.
Bislang sind nur wenige Sprachen auf dem Markt, die sowohl managed als auch unmanaged Code in einer einzigen Programmdatei unterstützen. Zu ihnen gehören C++/CLI (Managed C++) sowie Delphi ab Version 8.
[Bearbeiten] Sicherheit
Eines der wichtigsten Konzepte ist das Sicherheitskonzept von .NET, das weit über das bisher in Windows verankerte oder etwa das von Java hinausgeht.
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 (zum Beispiel durch Programmviren) bis hin zu Schutzmechanismen, die den Ort der Herkunft bzw. Programmausführung (zum Beispiel 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, CLR, Datenbank und Webserver.
[Bearbeiten] Attribute
Eine programmiertechnisch interessante Neuerung von .NET ist die Einführung von Attributen, das heißt, 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 die Verteilung, Installation und Konfigurierung, für die Sicherheit, für Transaktionen und viele andere Anwendungen dem Code beschreibende Eigenschaften hinzugefügt werden.
Innerhalb einer Anwendung kann mit Hilfe der Reflection-API auf die Attribute einer Assembly und die in ihr enthaltenen Elemente zugegriffen werden.
Dieses Konzept wurde von Java in Form der Annotationen übernommen. Zum Beispiel wurde in der aktuellen Version des Standards für Enterprise Java Beans die Entwicklung von EJBs durch den Einsatz von Annotationen vereinfacht.
[Bearbeiten] Verteilte Programmierung und Web Services
Microsoft bietet hier nicht einen übergreifenden Ansatz, sondern gleich (mindestens) drei unterschiedliche, mit jeweils eigenen Vor- und Nachteilen: eine moderne Implementierung des neuen Industriestandards Web Services (manchmal auch „XML Web Services“ genannt), eine Struktur für verteilte Programme (im Wesentlichen im LAN, aber mit zunehmender Bedeutung auch für nicht kommerzielle Anwendungsgebiete im Internet), die .NET Remoting Services, und die .NET Enterprise Services. Letztere sollen eine Konkurrenztechnik zu der erfolgreichen J2EE werden, aber obwohl diesmal Microsoft Ende der 1990er Jahre mit dem MTS (Microsoft Transaction Server) eine weithin unbeachtete Innovation lieferte, reagierte Sun und bildete eine vergleichbare Technologie nach, und zwar kommerziell erfolgreich, so dass die Microsoft-Technologie in diesem umsatzstarken Unternehmensmarkt bislang noch keine Rolle spielt.
Die verschiedenen Strukturen innerhalb .NET (Substrukturen wie MS Queuing Services gar nicht alle unterschieden) sind sicherlich, trotz breiter Auswahl und technisch teilweise guter Ansätze, noch nicht der Weisheit letzter Schluss, hier hat auch schon der Microsoft-Chef (Bill Gates) Nachbesserung gefordert. Insbesondere die .NET Remoting Services sollten nur dann eingesetzt werden, wenn man über ihre Schwächen und Limitierungen genau Bescheid weiß. In Bezug auf Web Services bietet .NET jedoch eine der technisch führenden Implementierungen an.
Mit der Fertigstellung des .NET Frameworks 3.0, mit dem auch die Windows Communication Foundation (WCF) Einzug in das Framework gehalten hat, wurden die geforderten Nachbesserungen implementiert. Insbesondere im Bereich des .NET Remoting wurde die Sicherheit stark verbessert und der Aufwand für die Nutzung der Dienste verringert, so dass die WCF inzwischen tatsächlich Konkurrenzfähig geworden ist und eine echte Alternative zu Java im Bereich der verteilten Anwendungen darstellt.
[Bearbeiten] Sprachneutralität und gemischtsprachige Programmierung
Die Common Language Specification (CLS) definiert eine gemeinsame Untermenge Binärcode der CIL, 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. Von Microsoft zum Beispiel schon im Visual Studio mitgeliefert sind das, neben der von Microsoft für .NET eingeführten Sprache C#, die Sprachen C++, das proprietäre Visual Basic .NET (siehe auch Visual Basic) sowie J# (Aussprache: dschäi-scharp; eine Portierung von Microsofts veränderter Java-Implementierung) und abschließend – nicht zu verwechseln mit J# – JScript .NET.
Insbesondere das vereinheitlichte Typsystem (Common Type System), das eine gemeinsame Schnittmenge an Datentypen beschreibt, sorgt für ein reibungsloses Zusammenspiel beim Aufruf von in einer anderen Sprache geschriebenen Komponenten. Dies stellt einen wichtigen Fortschritt dar, da man unter Visual Basic 6 unter Umständen gezwungen war, Funktionen, die nicht in Visual Basic implementiert werden konnten, in Visual C++ zu programmieren. In diesem Fall gab es immer Schwierigkeiten bei der Zuordnung der Datentypen von Visual Basic zu den entsprechenden Datentypen unter C++. Auch bei der Programmierung von COM-Komponenten in C++ musste man als Programmierer mit einem eingeschränkten Satz von Datentypen, die zur Automation benutzt werden konnten, auskommen. Außerdem wurden Strings unter C++ und Visual Basic 6 intern unterschiedlich gespeichert, was die Programmierung erschwerte.
Die Vorteile der Unterstützung gemischtsprachiger Programmierung von .NET sind nicht unumstritten, weil sich die Gesamtwartbarkeit durch den Einsatz mehrerer Sprachen prinzipbedingt verschlechtert. Insofern ist dies nicht unbedingt ein Vorteil gegenüber zum Beispiel Java. Aber insbesondere überall dort, wo bisher schon Visual Basic und C++ aufgrund ihrer spezifischen Vorteile gemischt eingesetzt wurden, ist wie beschrieben durch .NET ein wesentlicher Fortschritt erreicht worden.
Neben den von Microsoft für die .NET-Plattform angepassten Sprachen C#, Visual Basic .NET und C++/CLI (Managed C++) werden weitere .NET-Sprachen von Drittanbietern zur Verfügung gestellt (zum Beispiel Delphi von Borland, aber auch exotische Sprachen wie APL von Dyalog).
Es ist möglich, Programmiersprachen von Drittherstellern in Visual Studio.NET einzubinden, was die Entwicklung einer eigenen Integrierten Entwicklungsumgebung zwar erspart, jedoch auch Kunden dazu zwingt, sich dieses relativ teure Produkt zu kaufen. Dieses Feature ist eher für den Entwickler gedacht, der andere Programmiersprachen, als die in Visual Studio.NET bereits integrierten, nur nebensächlich nutzen möchte.
Fast unerwartet scheint der Anklang der .NET-Technologie bei Anbietern marktenger Programmiersprachen oder in Forschung und Lehre. 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.
[Bearbeiten] Plattformunabhängigkeit
Die angestrebte Plattformunabhängigkeit ist unter .NET theoretisch vollständig gegeben, aber da der Hersteller Microsoft die .NET-Plattform nur für seine eigene Produktlinie Windows anbietet, ist sie in der Praxis kaum vorhanden. 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. Das Mono-Projekt gilt als freie .NET-Alternative.
Seit Herbst 2004 stehen endgültige Versionen dieses Projektes zur Verfügung. Obwohl nicht alle Komponenten von .NET innerhalb dieses Projektes vorhanden sind, ist mit einer hohen Verbreitung auf Windows-fremden Systemen zu rechnen. Daneben wird noch im Rahmen des dotGNU-Projekts an einer Portable.NET genannten Laufzeitumgebung gearbeitet.
[Bearbeiten] Laufzeitumgebung
Managed code wird wie oben erwähnt von der Laufzeitumgebung Common Language Runtime (CLR) verwaltet. Diese virtuelle Maschine übernimmt die Anforderung und Freigabe von Speicher und anderen Ressourcen (Automatische Speicherbereinigung, engl. garbage collection) und stellt sicher, dass geschützte Speicherbereiche nicht direkt angesprochen oder überschrieben werden können. Wie oben unter Sicherheit beschrieben, können auch Zugriffe auf Dienste, Dateisystem-Funktionen oder Geräte überwacht und, sofern sie gegen Sicherheitsrichtlinien verstoßen, von der CLR abgelehnt werden.
[Bearbeiten] Ausführungsgeschwindigkeit
Für den Erfolg von .NET war und ist es wichtig, die Entwicklergemeinde von C++ für .NET zu gewinnen. Daher war Geschwindigkeit bei .NET von Anfang an ein wesentliches Designziel.
Durch verschiedene Techniken wird versucht, den negativen Einfluss der CLR auf die Ausführungsgeschwindigkeit möglichst klein zu halten. Zum Beispiel wurden analog zu Java so genannte JIT-Compiler eingeführt, die einen Mittelweg zwischen Interpretation und Kompilierung 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 Klassenmengen reduzieren.
(Ein JIT-Compiler ist in der Lage, den Befehlssatz des Prozessors, auf dem das Programm ausgeführt wird, optimal auszunutzen, was bei Programmen, die schon während ihrer Erstellung in Maschinensprache kompiliert werden, nur mit der Erstellung einer (potentiellen) Vielzahl von verschiedenen Versionen möglich ist.)
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 Automatische Speicherbereinigung, die automatische Freigabe nicht mehr benötigten Speichers und anderer Ressourcen. Zu beachten ist hierbei, dass die Freigabe nicht direkt erfolgt, sondern die Automatische Speicherbereinigung 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.
.NET wird inzwischen auch bei performancekritischen Anwendungen, wie z.B. Computerspielen, Animationsprogrammen, Konstruktionsprogrammen und ähnlichen, hochaufwendigen Anwendungen genutzt, da aktuelle Systeme durch ihre höhere Geschwindigkeit einen Mehrverlust an Performance, wegen des Einsatzes von .NET, ausgleichen.
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 dass die diesbezüglichen Vorteile durch obige Verfahren deren Nachteile in der Regel aufwiegen. Im Allgemeinen wird dabei von einer asymmetrischen Verteilung ausgegangen, dass zum Beispiel 90 Prozent einer durchschnittlichen Anwendung problemlos „managed“, das heißt, auch mit Automatischer Speicherbereinigung ausgeführt werden können, und lediglich 10 Prozent (z.B. einzelne Funktionen oder Klassen) optimiert werden müssen.
Dabei hat sich – analog zu den Diskussionen „Assembler: ja oder nein“ – gezeigt, dass oftmals durch Optimierung zugrunde liegender Algorithmen und Datenstrukturen eine wesentlich höhere Ausführungsgeschwindigkeit 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 Ausführungsgeschwindigkeit im Zusammenspiel mit Automatischer Speicherbereinigung optimiert werden.
[Bearbeiten] 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 zum Beispiel das Formatieren von Text, das Verschicken von E-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).
[Bearbeiten] Verfügbarkeit und Werkzeuge
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 (IDE) in Form des Microsoft Visual Studio .NET. Speziell für Einsteiger und Studenten gibt es die kostenlosen Microsoft Visual Studio Express Editions mit Einschränkungen gegenüber der teureren Standard- oder Professional-Varianten. Eine ebenfalls kostenfreie IDE für .Net (und Mono) unter Windows findet man im Open-Source-Projekt SharpDevelop.
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. .NET ist erst ab Windows 98 einsetzbar, 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 - so verbleibt die Plattformunabhängigkeit in der Liste der Möglichkeiten von .NET. Allerdings existieren die bereits erwähnten Open-Source-Projekte, die .NET auch für andere Plattformen (zum Beispiel Linux) verfügbar machen, wenn sie auch nicht den vollen Funktionsumfang des .NET-Frameworks unter Windows bieten können.
Für Handhelds und Mobiltelefone, die unter Windows CE bzw. Windows Mobile laufen, existiert eine abgespeckte Version der .NET-Laufzeitumgebung in Form des .NET Compact Frameworks. Es lässt sich aber nur unter Verwendung des kostenpflichtigen Visual Studio .NET 2003 oder neuer für diese Plattform entwickeln.
Im September 2006 stellte Microsoft zusätzlich das .NET Micro Framework vor. Es stellt eine abgespeckte Version des .Net Frameworks, speziell für Embedded-Geräte, dar. Je nach Plattform soll das Framework zwischen 512 KByte und 1 MByte auf dem Gerät beanspruchen und lässt sich direkt aus dem Flash-Speicher oder dem ROM starten. In diesem Falle arbeitet das Micro Framework als Betriebssystem, es kann aber auch auf ein vorhandenes Windows-Betriebssystem aufsetzen.
[Bearbeiten] Technische Einzelheiten
[Bearbeiten] Programmausführung
Der Compiler für .NET-Sprachen erzeugt keinen Maschinencode, der direkt vom Betriebssystem ausgeführt werden kann. Stattdessen wird ein Zwischencode, die sogenannte Common Intermediate Language (CIL) erzeugt. Dieser besteht aus Befehlen, die auf der Stack-basierten virtuellen Maschine (VM) ausgeführt werden. Die resultierenden Programme haben, wie andere Programme unter Windows, eine .„exe“-Erweiterung. Dies wird durch eine kleine Routine am Anfang des Programmes ermöglicht, die die virtuelle Maschine startet, welche wiederum den Zwischencode ausführt.
Wenn das Programm ausgeführt wird, übersetzt ein JIT-Compiler, der in der Laufzeitumgebung Common Language Runtime (CLR) enthalten ist, den Zwischencode in Maschinencode, der dann vom Prozessor direkt ausgeführt werden kann.
Da Code aus allen .NET-Sprachen in dieselbe Zwischensprache übersetzt wird, können Funktionen und Klassenbibliotheken, die in verschiedenen .NET-Sprachen geschrieben sind, problemlos gemeinsam in einem Programm verwendet werden.
[Bearbeiten] Assemblies
Übersetzte Programmklassen werden als ausführbare Programme in so genannten Assemblies zusammengefasst und bereitgestellt (vergleichbar mit Jar-Dateien in Java). Diese haben typischerweise die altbekannten Endungen .exe oder .dll, sind intern jedoch völlig anders strukturiert. Insbesondere sind im so genannten Manifest alle notwendigen Metadaten aufgeführt, so dass für reine .NET-Programme in der Regel die gewohnte, aber aufwändige und fehlerträchtige Registrierung wegfällt (Ausnahme zum Beispiel COM+/Enterprise Services).
Assemblies können entweder privat, gemeinsam (shared) oder global sein. Private Assemblies befinden sich in demselben Programmverzeichnis wie die auszuführende Anwendung. Daher wird angenommen, dass die Version des Assemblies kompatibel zur Anwendung ist und daher nicht von der CLR geprüft wird.
Ein gemeinsames (shared) Assembly kann sich in einem Verzeichnis befinden, auf das von mehreren Anwendungen zugegriffen wird. Daher wird für ein gemeinsames Assembly ein so genannter Strong Name benötigt. Ein Strong Name besteht aus dem Dateinamen des Assemblies, seiner Version, der Kultur und einem kryptografischen Schlüssel. Durch eine Konfigurationsdatei, die sich in dem Verzeichnis der Anwendung befindet, kann der Anwendung die Lage des Assemblies angegeben werden. Ein Strong Name kann mit Hilfe des Werkzeugs sn erzeugt werden.
Ein globales Assembly wird im globalen Assembly-Zwischenspeicher (Global Assembly Cache (GAC)) gespeichert. Mit Hilfe des Werkzeugs gacutil können Assemblies dem GAC hinzugefügt werden. Innerhalb des GAC können Assemblies mit unterschiedlichen Versionen und Kulturen gespeichert werden. Mit Hilfe von Konfigurationsdateien kann festgelegt werden, welche Versionen eines Assemblies von der Anwendung benutzt werden sollen. Erfolgt keine Angabe, so wird nur die Version benutzt, die bei der Erstellung der Anwendung benutzt wurde. Wenn diese Version nicht vorhanden ist, dann wird beim Start der Anwendung eine Fehlermeldung ausgegeben.
Aktuelle Windows-Versionen besitzen eine Explorer-Erweiterung, die eine aussagekräftige Anzeige des Inhalts des GAC im Windows Explorer ermöglicht.
[Bearbeiten] Unterstützte Sprachen und Compiler
Liste von Programmiersprachen und Compilern, die .NET unterstützen.
[Bearbeiten] Literatur
- Holger Schwichtenberg: Microsoft .NET 2.0 Crashkurs. Microsoft Press, Unterschleißheim 2006. ISBN 3860639870
- Andreas Kühnel: Visual C# 2005. Galileo Computing, Bonn 2006. ISBN 3-89842-586-X (online volltext)
[Bearbeiten] Weblinks
- Microsoft MSDN Developer Center – .NET Framework
- Alternative Implementierungen: Mono, DotGNU
- Codezone.de - Communityseite zu .NET
