.NET
aus Wikipedia, der freien Enzyklopädie
| Gesichtet | ||
Das ist die letzte gesichtete Version,
(zeige alle), freigegeben am 8. Mai 2008.
|
| .NET Framework | |
|---|---|
 |
|
| Basisdaten | |
| Entwickler: | Microsoft |
| Aktuelle Version: | Version 3.5 (16. November 2007) |
| 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/.../ |
.NET [ˈdɔtnɛt] ist eine von Microsoft entwickelte Softwareplattform. Diese umfasst eine Laufzeitumgebung, eine für Programmierer bestimmte Sammlung von Klassenbibliotheken (API), und angeschlossene Dienstprogramme (Services). Die Plattform ist derzeit in ihrem vollen Umfang nur für Windows verfügbar. Anwendungen für .NET laufen dank Projekten wie dem Mono-Projekt auch teilweise auf unixoiden Betriebssystemen.
Die Plattform soll die bisherigen Vorgehensweisen der Windows-Programmierer sowie veraltete Technologien wie COM ersetzen und eine flexiblere Möglichkeit bieten, auf Betriebssystemfunktionen zuzugreifen und sich untereinander auszutauschen. Dadurch ist .NET auch für den Einsatz auf unterschiedlichen Geräteplattformen, wie Handys oder PDAs, geeignet.
Seit dem 17. Januar 2008 ist der Quelltext des Frameworks zum Debugging für Entwickler verfügbar.
[Bearbeiten] Konzept
Die .NET-Plattform ist die Umsetzung des Common-Language-Infrastructure -Standards (CLI) und stellt mit diesem eine Basis zur Ausführung von Programmen, die mit unterschiedlichen Programmiersprachen erstellt wurden, her. Basisbestandteile sind die (objektorientierten) Laufzeitumgebung CLR ( Common Language Runtime ), die Base Class Library oder kurz BCL genannte Klassenbibliothek sowie diverse Tools z.B. zur Rechteverwaltung.
[Bearbeiten] CLR, CIL und Reflection
Die Common Language Runtime (CLR) ist die Laufzeitumgebung von .NET und stellt somit den Interpreter für den standardisierten Zwischencode, der Common Intermediate Language (CIL). Die CIL hieß früher Microsoft Intermediate Language (MSIL), wurde aber im Rahmen der Standardisierung durch die ECMA umbenannt. Für sie wurde ein sprachübergreifendes System von objektbasierten Datentypen definiert, so dass alle Hochsprachen, die sich CLI-Standard ( Common Language Infrastructure ) halten, in gültigen CIL-Bytecode kompiliert werden können.
Im Gegensatz zu Java, einer Technologie, die .NET am ähnlichsten ist, wurde .NET von Anfang an für den Betrieb mit mehreren Programmiersprachen entwickelt. Allerdings wurde im Gegensatz zu Java kein großer Wert auf Plattformunabhängigkeit gelegt.
[Bearbeiten] Strategie, Nutzen und Trends
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. Es soll unter anderem helfen, Programmierfehler zu vermindern. Gleichzeitig entschied sich Microsoft gegen die traditionelle, bisher angewandte 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 vorherrschenden Dominanz der direktkompilierenden Programmiersprachen (insbesondere C++ und C) dar. Damit entfernt sich die Softwareentwicklung insgesamt von dem Augenmerk auf Performance, die angesichts einer immer schneller werdenden Rechengeschwindigkeit immer unwichtiger wird. Vielmehr bemüht man sich nun um mehr Effizienz in der Programmentwicklung.
Mittels Reflection ist es möglich, zur Laufzeit Programmcode über ein Objektmodell zu generieren und es direkt im Speicher in lauffähigen Code 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 übersetzen und auszuführen.
[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-Kapseln (sogenannten "Wrappern") versehen und danach deren Programmfunktionen wie "normale" .NET-Programmfunktionen aufrufen. Umgekehrt lassen sich auch .NET-Funktionen wie COM-Funktionen aufrufen. Damit soll eine fließende Umstellung von Software-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: gekennzeichnete Metadaten als Bestandteil der Programmiersprache. Beispielsweise können im Rahmen der komponentenbasierten Programmierung Komponenteneigenschaften ausgedrückt werden. Für die Verteilung, Installation und Konfiguration, für die Sicherheit, für Transaktionen und viele andere Programme können dem Code beschreibende Eigenschaften hinzugefügt werden.
Innerhalb einer Anwendung kann mit Hilfe der Reflexion (siehe oben) auf die Attribute eines .NET-Programms, Assembly genannt, und die in ihr enthaltenen Elemente zugegriffen werden.
Dieses Konzept wurde später u.a. in Java übernommen, wo es in Form sogenannter Annotations verwirklicht ist.
[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 LAN, aber mit zunehmender Bedeutung auch für nicht kommerzielle Anwendungsgebiete im Internet
- die .NET Remoting Services
- die .NET Enterprise Services
Letztere sollen eine Konkurrenztechnik zu der erfolgreichen J2EE werden.
Die verschiedenen Strukturen innerhalb von .NET 2.0 sind trotz breiter Auswahl und technisch teilweise guter Ansätze, nicht ausgereift. Insbesondere die .NET Remoting Services sollten nur dann eingesetzt werden, wenn man über ihre Schwächen und Einschränkungen 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.
[Bearbeiten] Sprachneutralität und gemischtsprachige Programmierung
Die Common Language Specification (CLS) definiert als eine gemeinsame Untermenge den 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. Die Wartbarkeit eines Projektes, welches in mehreren Sprachen implementiert wurde, ist geringer als bei der Entwicklung mit nur einer Sprache.
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).
Die für .NET bereitgestellte IDE von Microsoft, das Visual Studio.NET, bietet die Möglichkeit, Sprachen von Drittanbietern einzubinden. Damit hat man dann die Möglichkeit weitere Sprachen in das eigene Projekt einzubinden und ggf. deren Funktionalität zu nutzen. Dass die Entwicklung in einer konsistenten Entwicklungsumgebung stattfindet und es nicht für jede Sprache eine eigene gibt, ist zusätzlich von Vorteil.
[Bearbeiten] Plattformunabhängigkeit
Die angestrebte Plattformunabhängigkeit ist unter .NET grundsätzlich möglich, Microsoft selbst hatte 2002 für die erste Version von .NET eine abgespeckte (und nicht mehr aktuelle) .NET-Variante namens Shared Source CLI ( Codename Rotor ) für Mac und FreeBSD zur Verfügung gestellt, Open-Source-Projekte haben sich einer Implementierung auf Grundlage des ECMA-Standards angenommen.
Die beiden wohl am weitesten entwickelten Projekte sind Mono, das vom Hersteller Ximian initiiert wurde, und das dotGNU-Projekt, welches an einer Portable.NET genannten Laufzeitumgebung arbeitet.
Beide Implementierungen sind jedoch noch nicht auf dem Entwicklungsstand des heutigen .NET. Beispielsweise ist die für Programme mit einer graphischen Oberfläche wichtige .NET Windows Forms Bibliothek bei Mono und auch bei dotGNU noch im April 2008 nicht fertig verfügbar - das von Microsoft unterstützte Zeichenprogramm Paint.NET kann beispielsweise somit nur auf Windowssystemen ab Windows 2000 verwendet werden. Bei Mono stellt als Alternative für Benutzeroberflächen Gtk# und qyoto ( Bindings für Qt) zur Verfügung, auch wenn die Windows.Forms-Bibliothek inzwischen fast vollständig implementiert ist. Einige .Net-Programme nutzen jedoch Betriebssystemressourcen der Win32-API oder von COM-Bibliotheken und sind damit schwer zu migrieren.
[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 Code, als sogenanntes natives Image installieren. Das wirkt sich insbesondere auf die erstmaligen Ladezeiten bei Programmen mit größeren Klassenmengen aus. Des weiteren kann der Speicherbedarf reduziert werden, wenn mehrere Programme dieselbe Assembly nutzen bzw. das Programm mehrfach gestartet wird (Terminalserver), da die nativen Images im Gegensatz zu JIT-Code zwischen den Programmen via shared memory geteilt werden. Der Performancegewinn durch native Images muss durch sorgfältiges Profiling analysiert werden. Der Einsatz von nativen Images erfordert weitere Planungsschritte bei der Entwicklung der Software, z. B. eine sorgfältige Auswahl der DLL-Basisadresse der Assemblies um eine Relokation der DLLs zu verhindern. Des weiteren müssen die Assemblies auch im GAC installiert werden, um anhand der Identität die Integrität des Images garantieren zu können. Wird das nicht beachtet, führt die Relokation bzw. die Identitätsprüfung der Assembly zu weiteren Ausführungszeiten, die den Vorteil der nativen Images wieder zunichte machen.
Die automatische Ressourcenverwaltung und die verbesserte Sicherheit haben dennoch ihren Preis – die Ausführung von managed code hat einen erhöhten Ressourcenbedarf und benötigt 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 dafür ist die Automatische Speicherbereinigung, die automatische Freigabe nicht mehr benötigten Speichers und anderer Ressourcen. Im Regelfall entscheidet der Garbage Collector, wann der Speicher aufgeräumt werden soll. Es ist aber möglich, dass der Entwickler den Zeitpunkt der Speicherbereinigung selbst festlegen kann. 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. 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 Programmen, z. B. Computerspielen (z. B. mit dem XNA Framework), Animationsprogrammen, Konstruktionsprogrammen und ähnlichen, hochaufwendigen Programmen genutzt, da viele Programmierer der Meinung sind, dass aktuelle Systeme durch ihre höhere Geschwindigkeit den durch den Einsatz von .NET bedingten Performanceverlust ausgleichen.
Auf der anderen Seite steht die Meinung, dass die Qualität und Effizienz der traditionellen Softwareentwicklung zu wünschen übrig 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 zur Diskussion „Assembler ja oder nein“ – gezeigt, dass oftmals durch Optimierung zugrunde liegender Algorithmen und Datenstrukturen eine wesentlich höhere Ausführungsgeschwindigkeit erzielt werden kann, als durch die Entscheidung für oder gegen eine Programmiersprache oder Programmiertechnik. 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 sogenannte Namensräume (Namespaces) unterteilt sind. Die Klassen erfüllen Aufgaben wie 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 den 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 bereits eine .NET-Laufzeitumgebung integriert haben. Bei Vorversionen muss diese manuell installiert werden, sofern die betreffende Windows-Variante unterstützt wird. .NET ist erst ab Windows 98 einsetzbar, die Programmierung von Webanwendungen (ASP.NET) etwa läuft nur ab Windows 2000. In Windows Vista ist .NET ein Kernbestandteil des Systems. 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. Das 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 sogenannten 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 sogenannten 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 Verzeichnis wie das auszuführende Programm. Daher wird angenommen, dass die Version des Assemblies kompatibel zum Programm ist und daher nicht von der CLR geprüft wird.
Ein gemeinsames (shared) Assembly kann sich in einem Verzeichnis befinden, auf das von mehreren Programmen 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 des Programmes 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 nicht vorhanden ist, wird beim Start des Programmes 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] .NET 3.0 und Vista
In der dritten Version umfasst das .NET Framework alles aus der Version 2.0. Hinzugekommen sind Funktionalitäten, die vor allem unter Windows Vista zum Einsatz kommen sollen. Dazu gehören im Wesentlichen die Windows Presentation Foundation (WPF, vormals WinFX genannt), die Windows Communication Foundation (WCF), die Windows Workflow Foundation (WF) und der Windows CardSpace.
Seit dem 6. November 2006 ist das .NET Framework 3.0 für Windows XP ab Service Pack 2 und für Windows Server 2003 verfügbar, um Entwicklern rechtzeitig die Entwicklung und Portierung von Programmen nach Vista zu ermöglichen. In Vista selbst ist es bereits integriert.
Silverlight (vormals WPF/E) enthält eine stark verkleinerte Untermenge des .NET Frameworks und soll im Wesentlichen Webbrowser befähigen, reichhaltige Internetanwendungen auf Basis der WPF anzuzeigen. Normale Programme auf Basis der WPF sind ebenfalls „webfähig“, benötigen aber das vollständige .NET 3.0, welches derzeit nur für Windows verfügbar ist. Silverlight jedoch soll auch für Mac OS, ältere PCs mit Windows sowie Linux bereitgestellt werden.
Für die Vorab-Demonstration des neuen .NET Frameworks präsentierte Microsoft den Foto-Dienst Microsoft Max. Mit Herausgabe der endgültigen Version wurde der Dienst eingestellt.
[Bearbeiten] Entstehungsgeschichte
Die Entwicklung der .NET-Plattform war einerseits notwendig, um die in die Jahre gekommenen Technologien von Windows durch neue Technologien zu ersetzen, jedoch andererseits das Ergebnis des Rechtsstreits von Microsoft mit Sun über Java. 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. Zudem war es Microsoft bis zur Erfindung von .NET nicht gelungen, im lukrativen Markt für mobile Kleingeräte Fuß zu fassen.
Es hatten sich zudem mit der Zeit verschiedene, zueinander inkompatible Softwaresysteme für Windows entwickelt. Die drei für Windows meistverwendeten Programmiersprachen C++, Visual Basic sowie die Microsoft-Implementierung einer Java-Syntax, J++, waren zueinander nicht kompatibel und die Zusammenarbeit über verschiedene Brücken erwies sich als sehr mühsam.
[Bearbeiten] Strings und ANSI/Unicode
Die Datentypen für Strings waren nicht binärkompatibel zueinander. Wollte man Strings über zwei Softwaresysteme hinwegschreiben, so musste man Laufzeiteinbußen wegen Konvertierungsfunktionen hinnehmen. Verschärfend kam die Koexistenz von ANSI und Unicode hinzu. Viele Programme unterstützten kein Unicode oder wurden dafür noch nicht ausgerüstet.
[Bearbeiten] Speicherverwaltung
Jede Entwicklungsplattform besaß ein eigenes System für die Verwaltung des Speichers. J++ und Visual Basic besaßen eine automatische Speicherverwaltung, das heißt der Programmierer überließ (weitgehend) dem System die Verwaltung des Speichers. Visual C++ hingegen besaß keine Speicherverwaltung, hier musste ein Programmierer selbst Hand anlegen.
[Bearbeiten] Offenlegung des Quellcodes
Am 17. Januar 2008 veröffentlichte Microsoft den Quelltext des Frameworks unter der restriktiven Microsoft Reference License. Zu diesem Schritt entschloss sich Microsoft bereits im Oktober 2007, als Sun Microsystems ihr Produkt Java unter der GNU GPL mit eigenen Zusatzklauseln zur Verfügung stellte.
Im Gegensatz zu Java stehen die Quelltexte des .NET Frameworks jedoch nicht unter einer freien Lizenz - es ist nicht erlaubt, den Quellcode zu modifizieren oder in andere Projekte zu integrieren. Microsoft gestattet lediglich die Einsicht des Quellcodes zur Unterstützung des Debugging-Prozesses in Projekten. Dank der Veröffentlichung des Quelltextes lassen sich in IT-Projekten im Fehlerfall zumindest präzisere Workarounds schreiben.
[Bearbeiten] Verhältnis zu Mono
Teile der Open-Source-Community[1] sehen in der Offenlegung unter der restriktiven Lizenz eine Gefahr für das Projekt Mono, welches .NET-Anwendungen unter Linux teilweise verfügbar macht. Microsoft hatte 2007 noch behauptet, das Projekt würde Quellcode aus dem .NET-Framework enthalten. Da das Framework und Mono gleichermaßen .NET implementieren, befürchtet man nun zwangsweise starke Ähnlichkeiten im Quellcode.
Durch das umstrittene Patentabkommen zwischen Microsoft und Novell[2] (dem Projektträger von Mono) werden Befürchtungen nichtig, Microsoft könnte das Projekt wegen Lizenzverstößen verklagen. Das Patentabkommen schützt derzeitig sowohl die Community unter Novell, als auch Microsoft vor gegenseitigen Patentansprüchen.
[Bearbeiten] Chronik der .NET-Entwicklung
| Jahr | Ereignisse |
|---|---|
| 2000 |
|
| 2002 |
|
| 2003 |
Vorstellung von .NET 1.1 und Visual Studio 2003 mit im Wesentlichen geringfügigen Verbesserungen und Erweiterungen. |
| 2005 |
|
| 2006 |
|
| 2007 |
|
| 2008 |
|
[Bearbeiten] Unterstützte Sprachen und Compiler
[Bearbeiten] Einzelnachweise
- ↑ Microsofts Open Source Trap (engl.)
- ↑ Dr.Oliver Diedrich: "Microsoft und Novell kooperieren" auf heise.de, 2007
[Bearbeiten] Literatur
- Holger Schwichtenberg: Microsoft .NET 2.0 Crashkurs. Microsoft Press, Unterschleißheim 2006. ISBN 3-86063-987-0
- Holger Schwichtenberg: Microsoft .NET 3.0 Crashkurs. Microsoft Press, Unterschleißheim 2007. ISBN 3-86645-501-1
- Jürgen Kotz, Rouven Haban, Simon Steckermeier: .NET 3.0. WPF, WCF und WF - ein Überblick. Addison-Wesley, München Februar 2007. ISBN 3-8273-2493-9
[Bearbeiten] Weblinks
- Microsoft MSDN Developer Center – .NET Framework
- Alternative Implementierungen: Mono, DotGNU
- Deutschsprachiges Magazin rund um das .NET Framework
