Teilen über

Native Interoperabilität

In den folgenden Artikeln werden die verschiedenen Möglichkeiten zum Ausführen von "nativer Interoperabilität" in .NET gezeigt.

Es gibt ein paar Gründe, warum Sie nativen Code aufrufen möchten:

  • Betriebssysteme enthalten eine große Anzahl von APIs, die in den verwalteten Klassenbibliotheken nicht vorhanden sind. Ein erstklassiges Beispiel für dieses Szenario wäre der Zugriff auf Hardware- oder Betriebssystemverwaltungsfunktionen.
  • Kommunikation mit anderen Komponenten, die C-Style ABIs (native ABIs) aufweisen oder erzeugen können, z. B. Java-Code, der über Java Native Interface (JNI) verfügbar gemacht wird, oder eine andere verwaltete Sprache, die eine systemeigene Komponente erzeugen könnte.
  • Unter Windows registriert der Großteil der software, die installiert wird, z. B. die Microsoft Office-Suite, COM-Komponenten, die ihre Programme darstellen, und ermöglicht Es Entwicklern, sie zu automatisieren oder zu verwenden. Dies erfordert auch systemeigene Interoperabilität.

In der vorherigen Liste werden nicht alle potenziellen Situationen und Szenarien behandelt, in denen der Entwickler eine Schnittstelle mit systemeigenen Komponenten wünschen/möchten/benötigen. Die .NET-Klassenbibliothek verwendet beispielsweise die systemeigene Interoperabilitätsunterstützung, um eine faire Anzahl seiner APIs zu implementieren, z. B. Konsolenunterstützung und -manipulation, Dateisystemzugriff und andere. Es ist jedoch wichtig zu beachten, dass bei Bedarf eine Option vorhanden ist.

Hinweis

Die meisten Beispiele in diesem Abschnitt werden für alle drei unterstützten Plattformen für .NET Core (Windows, Linux und macOS) vorgestellt. Bei einigen kurzen und illustrativen Beispielen wird jedoch nur ein Beispiel gezeigt, das Windows-Dateinamen und Erweiterungen verwendet (d. a. "dll" für Bibliotheken). Dies bedeutet nicht, dass diese Features unter Linux oder macOS nicht verfügbar sind, sondern nur aus Gründen der Einfachheit.

Siehe auch