Freigeben über

.NET-Glossar

  • Artikel

Dieses Glossar erklärt Begriffe und Akronyme, die häufig in der .NET-Dokumentation auftauchen.

AOT

Ahead-of-Time-Compiler

Ähnlich wie bei JIT übersetzt dieser Compiler ebenfalls IL in Computercode. Im Gegensatz zur JIT-Kompilierung erfolgt die AOT-Kompilierung, bevor die Anwendung ausgeführt wird und wird von einem anderen Computer aus ausgeführt. Da AOT-Toolketten nicht während der Laufzeit kompiliert werden, muss die Zeit, die für das Kompilieren aufgewendet wird, nicht minimiert werden. Das bedeutet, dass mehr Zeit in die Optimierung investiert werden kann. Da die gesamte Anwendung den Kontext der AOT darstellt, führt der AOT-Compiler auch modulübergreifende Verknüpfungen und die Analyse des gesamten Programms aus. Das bedeutet, dass allen Verweisen gefolgt und eine einzige ausführbare Datei generiert wird.

Siehe CoreRT und .NET Native.

App-Modell

Hierbei handelt es sich um eine Workload-spezifische API. Im Folgenden finden Sie einige Beispiele:

  • .NET Aspire
  • ASP.NET
  • ASP.NET-Web-API
  • Entity Framework (EF)
  • Windows Presentation Foundation (WPF)
  • Windows Communication Foundation (WCF)
  • Windows Workflow Foundation (WF)
  • Windows Forms (WinForms)

ASP.NET

Die ursprüngliche ASP.NET Implementierung, die im Lieferumfang von .NET Framework enthalten ist, auch bekannt als ASP.NET 4.x und ASP.NET Framework.

Manchmal dient ASP.NET als Oberbegriff, der sich auf das ursprüngliche ASP.NET und auf ASP.NET Core bezieht. Die Bedeutung, die der Begriff in einer bestimmten Instanz trägt, wird durch den Kontext bestimmt. Beziehen Sie sich auf ASP.NET 4.x, wenn Sie klarstellen möchten, dass Sie ASP.NET nicht für beide Implementierungen verwenden.

Siehe ASP.NET-Dokumentation.

ASP.NET Core

Hierbei handelt es sich um eine plattformübergreifende, leistungsstarke Open-Source-Implementierung von ASP.NET.

Siehe ASP.NET Core-Dokumentation.

Assembly

Eine DLL- oder EXE-Datei mit einer Sammlung von APIs, die von Apps oder anderen Assemblys aufgerufen werden können.

Eine Assembly enthält Typen wie Schnittstellen, Klassen, Strukturen, Enumerationen und Delegaten. Assemblys im Ordner bin eines Projekts werden manchmal als Binärdateien bezeichnet. Siehe auch Bibliotheken.

BCL

Basisklassenbibliothek

Eine Reihe von Bibliotheken, die die Namespaces System.* (und in beschränktem Umfang Microsoft.*) umfassen. Bei der BCL handelt es sich um ein allgemeines Framework auf niedriger Ebene, auf dem Anwendungsframeworks auf höherer Ebene, z.B. ASP.NET Core, basieren.

Der Quellcode der BCL für .NET ist im .NET-Laufzeit-Repository enthalten. Die meisten Basisklassenbibliothek APIs sind auch im .NET Framework verfügbar, der Quellcode ist also eine Kopie des .NET Framework BCL Quellcodes.

Die folgenden Begriffe beziehen sich häufig auf dieselbe Sammlung von APIs, auf die sich die BCL bezieht:

CLR

Common Language Runtime

Die genaue Bedeutung hängt vom Kontext ab. Common Language Runtime bezieht sich in der Regel auf die Laufzeit von .NET Framework oder auf die Laufzeit von .NET.

Die CLR verarbeitet die Speicherbelegung und -verwaltung. Bei der CLR handelt es sich auch um einen virtuellen Computer, der nicht nur Apps ausführt, sondern auch mithilfe eines JIT-Compilers dynamisch Code generiert und kompiliert.

Die CLR-Implementierung für .NET Framework ist nur für Windows vorgesehen.

Die CLR-Implementierung für .NET (auch als Core CLR bezeichnet) basiert auf derselben Codebasis wie .NET Framework CLR. Ursprünglich war die Core-CLR die Runtime von Silverlight und für die Ausführung auf mehreren Plattformen konzipiert, insbesondere Windows und Mac OS X. Sie ist weiterhin eine plattformübergreifende Runtime, die nun viele Linux-Distributionen unterstützt.

Weitere Informationen finden Sie unter Runtime.

Core-CLR

Die Common Language Runtime für .NET.

Weitere Informationen finden Sie unter CLR.

CoreRT

Im Gegensatz zu CLR handelt es sich bei CoreRT nicht um einen virtuellen Computer. Das bedeutet, dass die Funktionen zum dynamischen Generieren und Ausführen von Code nicht enthalten sind, da keine JIT-Kompilierung enthalten ist. Es ist jedoch ein GC enthalten sowie die Möglichkeit zur Identifikation und Reflektion des Laufzeittyps (RTTI). Das Typsystem wurde jedoch so entwickelt, dass keine Metadaten für die Reflektion erforderlich sind. Dies ermöglicht eine AOT-Toolkette, die die Verknüpfung zu überflüssigen Metadaten aufheben und (was noch wichtiger ist) Code identifizieren kann, der von der App nicht verwendet wird. CoreRT befindet sich in der Entwicklung.

Weitere Informationen finden Sie unter Einführung in CoreRT und .NET Runtime Lab.

plattformübergreifend

Die Möglichkeit, eine Anwendung zu entwickeln und auszuführen, die unter vielen verschiedenen Betriebssystemen wie Linux, Windows und iOS verwendet werden kann, ohne dass für jedes Betriebssystem Code neu geschrieben werden muss. Dies ermöglicht die Wiederverwendung von Code und Konsistenz zwischen Anwendungen auf verschiedenen Plattformen.

Weitere Informationen finden Sie unter Plattform.

Umgebung

Jede Laufzeitsoftware und alle Entwicklungstools und Communityressourcen, die zum Erstellen und Ausführen von Anwendungen für eine bestimmte Technologie verwendet werden.

Der Begriff „.NET-Umgebung“ unterscheidet sich von ähnlichen Begriffen wie „.NET-Stapel“ durch seine Einbindung von Apps und Bibliotheken, die von Drittanbietern stammen. Hier ein Beispiel in einem Satz:

  • „Der .NET Standard soll die .NET-Umgebung vereinheitlichen.“

Framework

Allgemein handelt es sich dabei um eine umfassende Sammlung von APIs, die die Entwicklung und Bereitstellung von Anwendungen erleichtert, die auf einer bestimmten Technologie basieren. Allgemein sind ASP.NET Core und Windows Forms Beispiele für Anwendungsframeworks. Die Wörter „Bibliothek“ und „Framework“ werden häufig synonym verwendet.

Das Wort „Framework“ hat in den folgenden Begriffen verschiedene Bedeutungen:

Manchmal bezieht sich „Framework“ auf eine Implementierung von .NET.

Frameworkbibliotheken

Die Bedeutung hängt vom Kontext ab. Verweisen Sie möglicherweise auf die Frameworkbibliotheken für .NET, in diesem Fall bezieht sie sich auf die gleichen Bibliotheken, auf die BCL verweist. Es kann auch auf die ASP.NET Core Framework-Bibliotheken verweisen, die auf der BCL aufbauen und zusätzliche APIs für Web-Apps bereitstellen.

GC

Garbage Collector

Der Garbage Collector ist eine Implementierung der automatischen Speicherverwaltung. Der GC gibt Arbeitsspeicher frei, der durch Objekte belegt ist, die nicht mehr verwendet werden.

Siehe Garbage Collection.

IL

Zwischensprache

.NET-Sprachen auf höherer Ebene, z.B. C#, werden zu einem hardwareunabhängigen Anweisungssatz kompiliert, der als Zwischensprache (Intermediate Language, IL) bezeichnet wird. IL wird manchmal als MSIL (Microsoft IL) oder CIL (Common IL) bezeichnet.

JIT

Just-In-Time-Compiler

Ähnlich wie bei AOT übersetzt dieser Compiler IL in einen Computercode, den der Prozessor versteht. Im Gegensatz zu AOT erfolgt die JIT-Kompilierung bei Bedarf und wird vom selben Computer aus ausgeführt, auf dem auch der Code ausgeführt werden soll. Da die JIT-Kompilierung während der Ausführung der Anwendung stattfindet, ist die Kompilierzeit Teil der Laufzeit. Daher müssen JIT-Compiler eine Balance zwischen der Zeit, die in die Optimierung des Codes investiert werden kann, und den Ersparnissen, die der resultierende Code erzeugt, finden. Ein JIT kennt jedoch die tatsächliche Hardware und befreit die Entwickler davon, verschiedene Implementierungen bereitzustellen.

Implementierung von .NET

Eine Implementierung von .NET umfasst:

  • Mindestens eine Runtime. Beispiele: CLR und CoreRT.
  • Eine Klassenbibliothek, die eine Version von .NET Standard implementiert und zusätzliche APIs enthalten kann. Beispiele: die BCLs für .NET Framework und .NET.
  • Optional mindestens ein Anwendungsframework. Beispiele: ASP.NET, Windows Forms und WPF sind in .NET Framework und .NET enthalten.
  • Optional Entwicklungstools. Einige Entwicklungstools werden zwischen mehreren Implementierungen freigegeben.

Beispiele für .NET-Implementierungen:

Weitere Informationen finden Sie unter .NET-Implementierungen.

Bibliothek

Eine Sammlung von APIs, die durch Apps oder andere Bibliotheken aufgerufen werden können. Eine .NET-Bibliothek besteht aus einer oder mehreren Assemblys.

Die Wörter „Bibliothek“ und Framework werden häufig synonym verwendet.

Mono

Eine plattformübergreifende .NET-Implementierung, die verwendet wird, wenn eine kleine Laufzeit erforderlich ist. Es ist die Laufzeit, die Xamarin-Anwendungen unter Android, Mac, iOS, tvOS und watchOS unterstützt und sich hauptsächlich auf Apps konzentriert, die einen kleinen Speicherbedarf erfordern.

Außerdem unterstützt Mono alle derzeit veröffentlichten Versionen des .NET Standards.

In der Vergangenheit hat Mono die größere API des .NET Framework implementiert und einige der beliebtesten Funktionen unter Unix emuliert. Es wird manchmal verwendet, um .NET-Anwendungen auszuführen, die auf diesen Funktionen auf Unix basieren.

Mono wird in der Regel mit einem Just-In-Time-Compiler verwendet. Es enthält aber auch einen vollständigen statischen Compiler (Ahead-of-time-Kompilierung), der auf Plattformen wie iOS verwendet wird.

Weitere Informationen finden Sie in der Mono-Dokumentation:

Natives AOT

Ein Bereitstellungsmodus, in dem die App eigenständig ist und zum Zeitpunkt der Veröffentlichung in systemeigenen Code kompiliert wird. Native AOT-Apps verwenden zur Laufzeit keinen JIT-Compiler. Sie können auf Computern ausgeführt werden, auf denen .NET-Runtime nicht installiert ist.

Weitere Informationen finden Sie unter Bereitstellung von nativem AOT.

.NET

.NET hat zwei Bedeutungen, und das, was beabsichtigt ist, hängt vom Kontext ab:

  • .NET kann als Dachbegriff für .NET Standard und alle .NET-Implementierungen und -Workloads verwendet werden.
  • .NET bezieht sich häufiger auf die plattformübergreifende, leistungsstarke Open-Source-Implementierung von .NET, die als .NET Core bezeichnet wurde. Sie kann auch als .NET 5 (und .NET Core) und höhere Versionen oder nur .NET 5+ bezeichnet werden.

Die erste Bedeutung ist beispielsweise in Ausdrücken wie "Implementierungen von .NET" vorgesehen. Die zweite Bedeutung ist in Namen wie .NET SDK und .NET CLI vorgesehen. Wenn kein Kontext vorliegt, der die erste Bedeutung angibt, gehen Sie davon aus, dass die zweite Bedeutung beabsichtigt ist.

Frühere Versionen von .NET werden als .NET Core 1 bis 3.1 bezeichnet. Die Versionsnummern überspringen 4, und die Version, die auf 3.1 folgt, wird als .NET 5 bezeichnet, wobei "Core" aus dem Namen gelöscht wird. Das Ablegen von "Core" wurde durchgeführt, um hervorzuheben, dass diese Implementierung von .NET der für alle neue Entwicklung empfohlene ist. Das Überspringen von Version 4 wurde durchgeführt, um zu vermeiden, dass diese neuere Implementierung von .NET mit der älteren Implementierung, die als .NET Framework bezeichnet wird, verwirrend ist. Die aktuelle Version von .NET Framework ist 4.8.1.

.NET ist immer vollständig großgeschrieben; die Schreibweise ".Net" wird nie verwendet.

Siehe .NET-Dokumentation.

.NET CLI

Eine plattformübergreifende Toolkette für die Entwicklung von Anwendungen und Bibliotheken für .NET. Auch bekannt als .NET Core CLI.

Weitere Informationen finden Sie unter .NET-CLI.

.NET Core

Weitere Informationen finden Sie unter .NET.

.NET Framework

Eine Implementierung von .NET, die nur unter Windows ausgeführt werden kann. Diese Implementierung enthält die Common Language Runtime (CLR), die Basisklassenbibliothek (BCL) und Bibliotheken für Anwendungsframeworks wie ASP.NET, Windows Forms und WPF.

Siehe Leitfaden für .NET Framework.

.NET systemeigen

Hierbei handelt es sich um eine Compiler-Toolkette, die nativen Code im Voraus (Ahead-of-Time, AOT) erzeugt, anstelle von „rechtzeitig“ (Just-In-Time, JIT).

Die Kompilierung erfolgt auf dem Computer des Entwicklers und funktioniert ähnlich wie ein C++-Compiler und -Linker. Nicht verwendeter Code wird entfernt und es wird mehr Zeit in die Optimierung des Codes investiert. Es wird Code aus den Bibliotheken extrahiert und in die ausführbare Datei eingefügt. Das Ergebnis ist ein einzelnes Modul, das die gesamte App darstellt.

UWP ist das Anwendungsframework, das von .NET Native unterstützt wird.

Weitere Informationen finden Sie unter .NET Native Dokumentation.

.NET SDK

Eine Reihe von Bibliotheken und Tools, mit denen Entwickler Anwendungen und Bibliotheken für .NET erstellen können. Auch bekannt als .NET Core SDK.

Darin enthalten sind die .NET-CLI zum Erstellen von Apps, die .NET-Bibliotheken und -Runtime zum Erstellen und Ausführen von Apps und die ausführbare dotnet-Datei (dotnet.exe), durch die CLI-Befehle und Anwendungen ausgeführt werden.

Weitere Informationen finden Sie in der Übersicht über .NET SDK.

.NET Standard

Eine formale Spezifikation von .NET-APIs, die für die verschiedenen .NET-Implementierungen verfügbar sind.

Die .NET Standard Spezifikation wird manchmal als „Bibliothek“ bezeichnet. Da eine Bibliothek API-Implementierungen enthält und nicht nur Spezifikationen (Schnittstellen), ist es irreführend, .NET Standard als „Bibliothek“ zu bezeichnen.

Siehe .NET Standard.

NGen

Native Imagegenerierung

Sie können sich diese Technologie als einen persistenten JIT-Compiler vorstellen. Normalerweise wird der Code auf dem Computer kompiliert, auf dem er ausgeführt wird. Die Kompilierung findet jedoch normalerweise während der Installation statt.

package

Ein NuGet-Paket – oder einfach ein Paket – meint eine ZIP-Datei mit mindestens einer gleichnamigen Assembly und zusätzlichen Metadaten, z. B. der Autorenname.

Die datei .zip hat eine nupkg-Erweiterung und kann Ressourcen enthalten, z . B. .dll Dateien und .xml Dateien, für die Verwendung mit mehreren Zielframeworks und -versionen. Bei der Installation in einer App oder Bibliothek werden die entsprechenden Ressourcen basierend auf dem Zielframework ausgeführt, das von der App oder Bibliothek angegeben wurde. Die Ressourcen, die die Schnittstelle definieren, befinden sich im Ordner ref, und die Ressourcen, die die Implementierung definieren, befinden sich im Ordner lib.

platform

Ein Betriebssystem (z.B. Windows, macOS, Linux, iOS und Android) und die Hardware, auf dem dieses ausgeführt wird.

Hier sind Beispiele für die Verwendung in Sätzen:

  • „.NET Core ist eine plattformübergreifende Implementierung von .NET.“
  • „PCL-Profile stehen für Microsoft-Plattformen, während .NET Standard plattformagnostisch ist.“

In der Legacydokumentation zu .NET wird manchmal der Begriff „.NET-Plattform“ für eine Implementierung von .NET oder den .NET-Stapel, einschließlich aller Implementierungen, verwendet. Beide dieser Verwendungsmöglichkeiten werden häufig mit der primären Bedeutung (Betriebssystem/Hardware) verwechselt. Daher werden diese Verwendungen nach Möglichkeit vermieden.

„Plattform“ hat im Begriff „Entwicklerplattform“ eine andere Bedeutung, die sich auf Software bezieht, die Tools und Bibliotheken zum Erstellen und Ausführen von Apps bereitstellt. .NET ist eine plattformübergreifende Open-Source-Entwicklerplattform, mit der Sie eine Vielzahl von Apps erstellen können.

POCO

Ein POCO – oder ein einfaches altes Klassen-/CLR-Objekt – ist eine .NET-Datenstruktur, die nur öffentliche Eigenschaften oder Felder enthält. Ein POCO sollte keine anderen Member enthalten, z. B.:

  • methods
  • events
  • Delegaten

Diese Objekte werden hauptsächlich als Datenübertragungsobjekte (DTOs) verwendet. Ein reines POCO erbt kein anderes Objekt oder implementiert eine Schnittstelle. Es ist üblich, dass POCOs bei der Serialisierung verwendet werden.

Laufzeit

Im Allgemeinen handelt es sich hierbei um die Ausführungsumgebung für ein verwaltetes Programm. Das Betriebssystem ist Teil der Laufzeitumgebung, gehört jedoch nicht zur .NET-Runtime. Im Folgenden finden Sie einige Beispiele für .NET-Runtimes, die diese Bedeutung haben:

  • Common Language Runtime (CLR)
  • .NET Native (für UWP)
  • Mono Runtime

Das Wort „Runtime“ hat in einigen Kontexten verschiedene Bedeutungen:

  • .NET-Runtime auf der .NET 5-Downloadseite

    Sie können die .NET-Runtime oder andere Runtimes wie die ASP.NET Core-Runtime herunterladen. Runtime steht in diesem Fall für die Komponenten, die auf einem Computer installiert werden müssen, um eine frameworkabhängige App auf dem Computer ausführen zu können. Die .NET-Runtime umfasst die CLR und das freigegebene .NET Framework, das die BCL bereitstellt.

  • .NET-Runtimebibliotheken

    Dies bezieht sich auf die gleichen Bibliotheken, auf die sich die BCL bezieht. Andere Runtimes (z. B. ASP.NET Core-Runtime) verfügen jedoch über unterschiedliche freigegebene Frameworks mit zusätzlichen Bibliotheken, die auf der BCL basieren.

  • Runtimebezeichner (RID)

    Runtime bezieht sich in diesem Fall auf die Betriebssystemplattform und die CPU-Architektur, auf der eine .NET-App ausgeführt wird (z. B. linux-x64).

  • Wie in den folgenden Beispielen bezieht sich „Runtime“ manchmal auf die Implementierung von .NET:

    • „Die verschiedenen .NET-Runtimes implementieren bestimmte Versionen von .NET Standard. … Jede Version der .NET-Runtime kündigt die höchste Version von .NET Standard an, die sie unterstützt ...“
    • „Bibliotheken, die auf mehreren Runtimes ausgeführt werden sollen, sollten dieses Framework als Ziel haben.“ (bezogen auf .NET Standard)

Freigegebenes Framework

Die Bedeutung hängt vom Kontext ab. Das freigegebene .NET-Framework bezieht sich auf die Bibliotheken in der .NET-Runtime. In diesem Fall bezieht sich das freigegebene Framework für .NET auf dieselben Bibliotheken, auf die BCL verweist.

Es gibt noch andere freigegebene Frameworks. Das freigegebene ASP.NET Core-Framework bezieht sich auf die Bibliotheken in der ASP.NET Core-Runtime, die die BCL und zusätzliche APIs für die Verwendung durch Web-Apps enthält.

Für frameworkabhängige Apps besteht das freigegebene Framework aus Bibliotheken, die in Assemblys enthalten sind, die wiederum in einem Ordner auf dem die App ausführenden Computer installiert sind. Für eigenständige Apps sind die freigegebenen Frameworkassemblys in der App enthalten.

Weitere Informationen finden Sie unter Fundierte Einblicke in .NET Core-Primitiven, Teil 2: Freigegebenes Framework.

Stapel

Eine Reihe von Programmiertechnologien, die zusammen verwendet werden, um Anwendungen zu erstellen und auszuführen.

Mit dem „.NET-Stapel“ sind .NET Standard und alle .NET-Implementierungen gemeint. Der Ausdruck ".NET-Stapel" kann auf eine Implementierung von .NET verweisen.

Zielframework

Die Sammlung von APIs, auf der eine .NET-App oder -Bibliothek basiert.

Eine App oder Bibliothek kann eine bestimmte Version von .NET Standard (beispielsweise .NET Standard 2.0) anzielen. Dabei handelt es sich um eine Spezifikation für eine standardisierte Reihe von APIs für alle .NET-Implementierungen. Eine App oder Bibliothek kann auch eine Version einer bestimmten .NET-Implementierung anzielen. In diesem Fall erhält diese Zugriff auf die implementierungsspezifischen APIs. Beispielsweise erhält eine App, die Xamarin iOS anzieht, Zugriff auf die von Xamarin bereitgestellten iOS-API-Wrapper.

Für einige Zielframeworks (z . B. .NET Framework) werden die verfügbaren APIs durch die Assemblys definiert, die eine .NET-Implementierung auf einem System installiert, die Anwendungsframework-APIs (z. B. ASP.NET, WinForms) enthalten kann. Bei paketbasierten Zielframeworks (beispielsweise .NET Standard und .NET Core) definieren jene Pakete die Framework-APIs, die in der App oder der Bibliothek installiert sind.

Siehe Zielframeworks.

TFM

Zielframeworkmoniker

Ein standardisiertes Tokenformat zur Angabe des Zielframeworks einer .NET-App oder -Bibliothek. Auf Zielframeworks wird üblicherweise durch einen kurzen Namen verwiesen, z.B. net462. Langform-TFMs (z .NETFramework,Version=4.6.2. B. ) sind vorhanden, werden jedoch nicht in der Regel verwendet, um ein Zielframework anzugeben.

Siehe Zielframeworks.

UWP

Universelle Windows-Plattform

Eine Implementierung von .NET, mit der Sie touchfähige Windows-Apps und Software für das Internet der Dinge (IoT) erstellen. Es wurde entwickelt, um die verschiedenen Gerätetypen zu vereinheitlichen, auf die Sie abzielen möchten, einschließlich PCs, Tablets, Smartphones und sogar der Xbox. Die UWP bietet viele Dienste, z.B. einen zentralen App Store, eine Ausführungsumgebung (AppContainer) und mehrere Windows-APIs, die anstelle von Win32 (WinRT) verwendet werden. Apps können in C++, C#, Visual Basic und JavaScript geschrieben werden. Bei Verwendung von C# und Visual Basic werden die .NET-APIs von .NET bereitgestellt.

workload

Hierbei handelt es sich um einen App-Typen, der erstellt wird. Eine Workload ist allgemeiner als ein App-Modell. Beispielsweise ist oben auf jeder .NET-Dokumentationsseite, einschließlich dieser Seite, eine Dropdownliste für Workloads, mit der Sie zur Dokumentation für Web, Mobile, Cloud, Cloud native und Desktop wechseln können.

In manchen Kontexten bezieht sich Workload auf eine Featuresammlung in Visual Studio, die Sie installieren können, um einen bestimmten App-Typen zu unterstützen. Ein Beispiel finden Sie unter Konfigurieren von Visual Studio-Workloads.

Siehe auch