WikiDer > .NET

.NET
Das .NET Framework sollte nicht mit dem Domänennamen verwechselt werden .gerade.
.GERADE
Logo
EntwicklerMicrosoft
Veröffentlicht16. Januar 2002
Letzte Version4.8.0 Build 3928
(25. Juli 2019)
StatusAktiv
BetriebssystemFenster
LizenzSowohl Closed-Source- als auch Open-Source-Lizenzen
Webseite[1]
Portal  Portalsymbol  Informatik

.GERADE (Aussage: Punkt net) ist ein Anwendungsrahmen für nahtlose Anwendungszusammenarbeit und Bibliotheken anders geschrieben Programmiersprachen. Es wurde entwickelt von Microsoft. .NET ist in der Öffentlichkeit vollständig beschrieben ECMAStandards und ist daher nicht exklusiv für Microsoft-Anwendungen. Das Gemeinsame Sprachinfrastruktur, der offizielle Name für .NET ist im ECMA-Standard 335 beschrieben, der neu entwickelten Sprache C# im ECMA-Standard 334.

Eigenschaften

.NET besteht aus einer großen Anzahl Klassen die der Entwickler beim Erstellen verwenden kann Programme, sowie ein Virtual Execution System (VES) und einige Compiler Umwandlung dieses Quellcodes in eine Zwischenschicht, die Microsoft-Zwischensprache (MSIL). Der MSIL-Code wird von der Common Language Runtime (CLR) bis Just-in-Time-Zusammenstellung in Maschinencode umgewandelt und ausgeführt.

Die .NET-Technologie ist eindeutig inspiriert von Java. Nachdem Microsoft die Java Virtual Machine für eine bessere Kompatibilität mit der Windows-Plattform unter Verletzung der Lizenzbedingungen von Sonne Mikrosysteme, dem Eigentümer von Java, der diese Erweiterungen schließlich gerichtlich sanktionieren musste, beschloss die Microsoft Corporation gemeinsam mit Hewlett-Packard und Intel Corporation, einen gemeinsamen Standard zu entwickeln, der als Basis für das .NET-Framework entstand. Dies kombiniert die Vorteile der Java-Prinzipien mit großer Austauschbarkeit mit den bereits bestehenden Windows-Programmierumgebungen, was es zu einem sehr interessanten Entwicklungsplattform macht einen Großteil der Software aus, die vor .NET existierte Visual Basic oder C wurde entwickelt.

Wie bei Java sind Programme in .NET nicht zusammengestellt bis um Maschinensprache sondern auf eine Zwischensprache (gemeinsame Zwischensprache oder CIL). Dies wird dann von einer Laufzeit-Engine (VES) ausgeführt. Vergleichen Sie dies mit dem Java virtuelle Maschine. Dieses Setup bietet eine Abstraktion der zugrunde liegenden Maschine (einschließlich Betriebssystem und Dienste sowie Datentypen) und macht viele verschiedene Programmiersprachen für die gleiche, garantierte Ausstattungsbasis ausgelegt werden können.

Die Microsoft-Implementierungen werden nur entwickelt für Fenster, aber es gibt auch Open-Source-Implementierungen von .NET verfügbar. Das wichtigste davon ist Mono, die speziell für die Erleichterung der Programmierung in .NET . eingerichtet wurde Linux unterstützen, und das gelingt ihr. Allerdings hinkt die Entwicklung hier und da den kontinuierlichen Erweiterungen der Microsoft-Implementierungen hinterher.

Ende 2014 kündigte Microsoft an, den Quellcode des .NET Framework teilweise als beschikbaar . zur Verfügung zu stellen Quelloffene Software.[1] Dies betrifft vor allem die Laufzeit und verwandte Kerntechnologien wie ASP.NET, den .NET-Compiler „Roslyn“, das .NET Micro Framework, .NET Rx und die Programmiersprachen Visual Basic und C#.[1] Windows Forms bleibt beispielsweise Closed Source.[1]

Microsoft wird sich auch stärker auf die Plattformunabhängigkeit konzentrieren, indem es die Unterstützung für das .NET Framework auf . erweitert Linux und Mac OS X.[2]

Das .NET Framework ist in Windows XP und Windows 2003 Server enthalten, steht aber auch für ältere Windows-Versionen zur Verfügung. Außerdem können verschiedene Implementierungen der ECMA-Standards heruntergeladen werden, einige davon mit Quellcode.

Geschichte

Die Architektur

Common Language Infrastructure (CLI)

sehen Gemeinsame Sprachinfrastruktur für den Hauptartikel zu diesem Thema.

Der Zweck der Common Language Infrastructure (CLI) besteht darin, eine sprachneutrale Plattform für die Anwendungsentwicklung und -ausführung bereitzustellen, einschließlich Funktionen für die Ausnahmebehandlung, Garbage Collection, Sicherheit und Interoperabilität. Durch die Implementierung von Schlüsselaspekten des .NET Frameworks im Rahmen der CLR wird diese Funktionalität nicht an eine einzelne Sprache gebunden, sondern steht über die vielen vom Framework unterstützten Sprachen zur Verfügung. Die CLI-Implementierung von Microsoft ist die Common Language Runtime, auch bekannt als CLR.

Baugruppen

Der CIL-Code befindet sich in den .NET-Assemblys. Wie in der Spezifikation beschrieben, werden Assemblys im Portable Executable (PE)-Format gespeichert, das auf der Windows-Plattform für alle DLL- und EXE-Dateien üblich ist. Die Assembly besteht aus einer oder mehreren Dateien, von denen eine das Manifest enthalten muss, das Metadaten für die Montage hat. Der vollständige Name einer Assembly (nicht zu verwechseln mit dem Dateinamen auf der Festplatte) enthält den einfachen Namen, die Version, die Kultur und das Token des öffentlichen Schlüssels. Der öffentliche Schlüsseltoken ist ein einzigartiges hash, die beim Assemblieren der Assembly generiert wird, so dass zwei Assemblys mit demselben öffentlichen Schlüssel aus Framework-Sicht garantiert identisch sind. Es kann auch ein privater Schlüssel angegeben werden, der nur dem Ersteller der Assembly bekannt ist und für eine starke Benennung verwendet werden kann und um sicherzustellen, dass die Assembly vom selben Autor stammt, wenn eine neue Version der Assembly erstellt wird (erforderlich, um die Globaler Assemblycache).

Sicherheit

.NET verfügt über einen eigenen Sicherheitsmechanismus mit zwei allgemeinen Funktionen: Codezugriffssicherheit (CAS) und Validierung/Verifizierung. Die Codezugriffssicherheit basiert auf Beweisen, die einer bestimmten Assembly zugeordnet sind. Die Quelle der Assembly ist ein typischer Beweispunkt (ob sie auf dem lokalen Computer installiert oder aus dem Intranet oder dem Internet heruntergeladen wurde). Code Access Security verwendet den Nachweis, um dem Code bestimmte Berechtigungen zu erteilen. Anderer Code erfordert möglicherweise, dass dem Aufrufcode eine bestimmte Erlaubnis erteilt wird. Die Abfrage veranlasst die CLR, einen Call-Stack-Walk durchzuführen: Jede Assembly jeder Methode in der Call-Stack wird auf erforderliche Berechtigungen überprüft, wenn die Assembly keine Berechtigungen hat, wird eine Sicherheitsausnahme ausgelöst.

Wenn eine Baugruppe geladen wird, führt die CLR mehrere Tests durch. Zwei dieser Tests sind Validierung und Verifizierung. Während der Validierung prüft die CLR, ob die Assembly gültige Metadaten und CIL-Code enthält und ob die internen Tabellen korrekt sind. Die Verifizierung ist nicht so genau. Der Verifizierungsmechanismus prüft, ob der Code etwas „Unsicheres“ tut. Der verwendete Algorithmus ist recht konservativ, weshalb "sicherer" Code manchmal nicht durchkommt. Unsicherer Code wird nur ausgeführt, wenn die Assembly über die Berechtigung zum Überspringen der Authentifizierung verfügt, die sich im Allgemeinen auf Code bezieht, der auf dem lokalen Computer installiert ist.

.NET Framework verwendet AppDomains als Mechanismus zum Isolieren von Code, der in einem Prozess ausgeführt wird. AppDomains können initialisiert und dann Programmiercode ein- und ausgesendet werden. Diese AppDomains können unabhängig voneinander arbeiten. Dies trägt dazu bei, die Fehlertoleranz der Anwendung zu erhöhen, sodass Fehler oder Abstürze in einer AppDomain sich nicht auf den Rest der Anwendung auswirken.

AppDomains können auch individuell mit unterschiedlichen Sicherheitsstufen konfiguriert werden. Dies kann die Anwendungssicherheit erhöhen, indem potenziell unsicherer Code isoliert wird. Der kleine Nachteil besteht darin, dass der Entwickler die Anwendung selbst in Subdomains aufteilen muss, da dies nicht von der CLR übernommen wird.

Klassenbibliotheken

Das .NET Framework enthält eine Reihe von Standardklassenbibliotheken. Eine Klassenbibliothek ist in einer Namensraumhierarchie organisiert. Die meisten integrierten APIs sind Teil des Microsoft-Namespace oder des System-Namespace. Diese Klassenbibliotheken implementieren viele gängige Funktionen wie das Lesen und Schreiben von Dateien, das grafische Rendering, die Datenbankinteraktion und die Manipulation von XML-Dokumenten. Die .NET-Klassenbibliotheken sind für alle von der CLI verwendeten Sprachen verfügbar. Die .NET Framework-Klassenbibliothek ist in zwei Teile unterteilt: die Basisklassenbibliothek und die Framework-Klassenbibliothek.

Die Base Class Library (BCL) enthält eine kleine Teilmenge der gesamten Klassenbibliothek und ist der Kern der Klassen, die als Basis-API der Common Language Runtime dienen. Die Klassen in mscorlib.dll und einige der Klassen in System.dll und System.Core.dll werden als Teil der BCL betrachtet. Die BCL-Klassen sind sowohl in .NET Framework als auch in seinen alternativen Implementierungen einschließlich .NET Compact Framework, Microsoft Silverlight und Mono verfügbar.

Die Framework-Klassenbibliothek (FCL) ist eine Obermenge der BCL-Klassen und bezieht sich auf die gesamte Klassenbibliothek, die in .NET Framework enthalten ist. Es enthält einen umfassenden Satz von Bibliotheken, einschließlich Windows Forms, ADO.NET, ASP.NET, Language Integrated Query, Windows Presentation Foundation und Windows Communication Foundation. Die FCL ist viel größer als Standardbibliotheken für Sprachen wie C und vergleichbar mit den Standardbibliotheken von Java.

Speicherverwaltung

Die .NET Framework Common Language Runtime befreit den Entwickler von der Speicherverwaltung (Zuweisung und Freigabe nach Abschluss); stattdessen übernimmt die CLR die Speicherverwaltung selbst. Der Speicher, der Instanzen von .NET-Klassen zugewiesen ist, ist zusammenhängend von der verwalteter Haufen, ein Speicherpool, der von der CLR verwaltet wird. Solange eine Referenz auf ein Objekt existiert, bei der es sich entweder um eine direkte Referenz oder eine Referenz durch einen Objektgraphen handelt, wird sie von der CLR als verwendet betrachtet. Fehlt ein Bezug zu einem Objekt, kann es nicht erreicht oder genutzt werden und wird zu „Müll“. Aber es ist immer noch Speicher zugewiesen. .NET Framework enthält einen Garbage Collector, der regelmäßig in einem separaten Thread vom Anwendungsthread ausgeführt wird. Dadurch werden alle nicht verwendeten Objekte aufgelistet und der ihnen zugewiesene Speicher freigegeben.

Der .NET Garbage Collector (GC) ist ein nicht-deterministischer, kompakter Mark-and-Swipe-Garbage Collector. Der GC wird nur ausgeführt, wenn eine bestimmte Menge an Arbeitsspeicher verwendet wird oder wenn ein neues Objekt erstellt werden muss und nicht genügend Speicherplatz auf dem verwalteten Heap vorhanden ist. Da es unmöglich ist, vorherzusagen, wann die Bedingungen für die Wiederverwendung von Speicher erreicht werden, wird der GC als nicht deterministisch bezeichnet. Jede .NET-Anwendung hat einen Satz von Roots, die auf Objekte im verwalteten Heap (verwaltete Objekte) verweisen. Diese enthalten Verweise auf statische Objekte und Objekte, die im aktuellen Gültigkeitsbereich als lokale Variablen oder Methodenparameter definiert sind, sowie auf Objekte, auf die von CPU-Registern verwiesen wird. Wenn der GC ausgeführt wird, hält er die Anwendung an und listet für jedes Objekt im Stamm rekursiv alle Objekte auf, die von diesem Stamm aus erreichbar sind, und markiert diese Objekte als erreichbar. Es verwendet .NETMetadaten und Reflexion die Objekte innerhalb eines Objekts zu entdecken und dann rekursiv durch sie zu gehen.

Anschließend durchläuft es alle Objekte auf dem Heap mittels Reflexion und testet diese auch auf Erreichbarkeit. Alle als unzugänglich markierten Objekte sind „Müll“. Dies ist die Markierungsphase. Da der von Müll verwendete Speicher keine Bedeutung hat, wird er als freier Speicherplatz angesehen, der wiederverwendet werden kann. Der GC könnte die Anwendung zu diesem Zeitpunkt stoppen und wieder aufnehmen. Dies würde jedoch dazu führen, dass der globale Heap nicht mehr aus einem Stück Freiraum besteht, sondern aus kleineren Stücken Freiraum, die von zugänglichen Objekten unterbrochen werden. Wenn eine Anwendung ein Objekt erstellen möchte, verfügt die CLR daher möglicherweise nicht über einen ausreichend großen Speicherblock, obwohl alle verfügbaren Speicherblöcke zusammen groß genug sind. Diese sogenannte Fragmentierung wird verhindert, weil der GC alle zugänglichen Objekte so verschiebt, dass sich auf dem verwalteten Heap ein einziger, ununterbrochener Block freier Speicherplatz befindet. Schließlich werden die Verweise auf die verschobenen Objekte mit der neuen Position gefüllt, wonach die Anwendung wieder aufgenommen wird.

Da ein GC die Anwendung unterbricht, sollte dieser Vorgang möglichst kurz sein, damit der Anwender davon möglichst wenig oder nichts mitbekommt. Dazu enthält der GC eine Optimierung, die dafür sorgt, dass nicht jedes Mal alle Objekte auf Zugänglichkeit geprüft werden. Objekten wird eine Generationsnummer zugewiesen: Generation 0 wird neuen Objekten zugewiesen; Objekte, die eine erste Garbage Collection überleben, werden zu Generation 1. Objekte der Generation 1, die eine nachfolgende Garbage Collection überleben, werden zu Objekten der Generation 2. Das .NET-Framework nummeriert Objekte bis zur Generation 2. Die Optimierung besteht darin, dass Objekte höherer Generation seltener GC unterzogen werden als Objekte niedrigerer Generation. Der GC stoppt, sobald genügend Speicher frei wird, um den Bedarf zu decken, der zum Start des GC geführt hat.

Programmiersprachen für die .NET-Plattform


Alternativen

An zwei alternativen Optionen wird gearbeitet Open Source.NET-Implementierungen, die auf anderen Plattformen installiert werden können, wie z Linux- und FreeBSD:

Siehe auch

Externe Links

.NET-Framework
Die Architektur:Common Language Runtime · Codezugriffssicherheit · Versammlung · Metadaten · COM-Interop · Gemeinsame Sprachinfrastruktur
CLI-Sprachen:EIN# · axum · boo · C# · COBOL.NET · F# · EisenLisp · EisenPython · EisenRuby · Eisenschema · J# · JScript .NET · Nemerle · Sauerstoff · P# · Phalanger · Reichweite · Visual Basic .NET · Windows PowerShell
Komponenten:ADO.NET (Entitäts-Framework · Datendienste) · ASP.NET (AJAX · MVC · Dynamische Daten) · Sprachintegrierte Abfrage · CardSpace · ClickOnce · Kommunikationsstiftung · Dynamische Sprachlaufzeit · Formen · Präsentationsstiftung · Fernsteuerung · Workflow-Grundlage · XAML · Parallele Erweiterungen · Managed Extensibility Framework
Andere Versionen:Mono · Kompaktes Framework · XNA-Framework · Mikro-Framework · portabel.NET · silbernes Licht · SSCLIA · dotGNU