Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Systemeigene Code-Interoperabilität ist eine Technologie, mit der Sie auf nicht verwaltete Bibliotheken aus verwaltetem Code zugreifen oder verwaltete Bibliotheken für nicht verwalteten Code verfügbar machen können (die entgegengesetzte Richtung).
Während die Interoperabilität von nativem Code in Nativen-AOT- und Nicht-AOT-Bereitstellungen ähnlich funktioniert, gibt es einige Besonderheiten, die sich bei der Veröffentlichung als natives AOT unterscheiden.
Direkte P/Invoke-Aufrufe
Die P/Invoke-Aufrufe in AOT-kompilierten Binärdateien werden standardmäßig zur Laufzeit verzögert gebunden, um die Kompatibilität zu verbessern. Sie können den AOT-Compiler so konfigurieren, dass direkte Aufrufe für ausgewählte P/Invoke-Methoden generiert werden, die während des Starts durch das dynamische Ladeprogramm gebunden sind, das im Betriebssystem verfügbar ist. Die nicht verwalteten Bibliotheken und Einstiegspunkte, auf die über direkte Aufrufe verwiesen wird, müssen immer zur Laufzeit verfügbar sein, andernfalls kann die systemeigene Binärdatei nicht gestartet werden.
Die Vorteile direkter P/Invoke-Aufrufe sind:
- Sie haben eine bessere konstante Zustandsleistung.
- Sie ermöglichen es, die nicht verwalteten Abhängigkeiten statisch zu verknüpfen.
Sie können die direkte P/Invoke-Generierung mithilfe <DirectPInvoke> von Elementen in der Projektdatei konfigurieren. Der Elementname kann entweder <Modulname> sein, wodurch direkte Aufrufe für alle Einstiegspunkte im Modul oder <modulname!entrypointname> möglich sind, wodurch nur ein direkter Aufruf für das jeweilige Modul und den Einstiegspunkt möglich ist.
Um eine Liste der Einstiegspunkte in einer externen Datei anzugeben, verwenden Sie <DirectPInvokeList> Elemente in der Projektdatei. Eine Liste ist nützlich, wenn die Anzahl der direkten P/Invoke-Aufrufe groß ist und nicht praktikabel ist, diese mithilfe einzelner <DirectPInvoke> Elemente anzugeben. Die Datei kann leere Zeilen und Kommentare enthalten, beginnend mit #.
Beispiele
<ItemGroup>
<!-- Generate direct PInvoke calls for everything in __Internal -->
<!-- This option replicates Mono AOT behavior that generates direct PInvoke calls for __Internal -->
<DirectPInvoke Include="__Internal" />
<!-- Generate direct PInvoke calls for everything in libc (also matches libc.so on Linux or libc.dylib on macOS) -->
<DirectPInvoke Include="libc" />
<!-- Generate direct PInvoke calls for Sleep in kernel32 (also matches kernel32.dll on Windows) -->
<DirectPInvoke Include="kernel32!Sleep" />
<!-- Generate direct PInvoke for all APIs listed in DirectXAPIs.txt -->
<DirectPInvokeList Include="DirectXAPIs.txt" />
</ItemGroup>
Unter Windows verwendet Native AOT eine vorab aufgefüllte Liste mit direkten P/Invoke-Methoden, die in allen unterstützten Versionen von Windows verfügbar sind.
Warnung
Da direkte P/Invoke-Methoden vom dynamischen Ladeprogramm des Betriebssystems und nicht von der nativen AOT-Laufzeitbibliothek aufgelöst werden, respektieren direkte P/Invoke-Methoden nicht die DefaultDllImportSearchPathsAttribute. Die Bibliothekssuchreihenfolge folgt den vom Betriebssystem definierten regeln für das dynamische Ladeprogramm. Einige Betriebssysteme und Ladeprogramme bieten Möglichkeiten, das dynamische Laden über Linker-Flags (z. B. /DEPENDENTLOADFLAG auf Windows oder -rpath auf Linux) zu steuern. Weitere Informationen zum Angeben von Linkerkennzeichnungen finden Sie im Abschnitt "Verknüpfen" .
Verlinkung
Wenn Sie eine statische Verknüpfung mit einer nicht verwalteten Bibliothek herstellen möchten, müssen Sie <NativeLibrary Include="filename" /> angeben, die unter Windows auf eine .lib-Datei und unter Unix-ähnlichen Systemen auf eine .a-Datei verweist.
Beispiele
<ItemGroup>
<!-- Generate direct PInvokes for Dependency -->
<DirectPInvoke Include="Dependency" />
<!-- Specify library to link against -->
<NativeLibrary Include="Dependency.lib" Condition="$(RuntimeIdentifier.StartsWith('win'))" />
<NativeLibrary Include="Dependency.a" Condition="!$(RuntimeIdentifier.StartsWith('win'))" />
</ItemGroup>
Verwenden Sie das Element <LinkerArg>, um zusätzliche Flags für den nativen Linker anzugeben.
Beispiele
<ItemGroup>
<!-- link.exe is used as the linker on Windows -->
<LinkerArg Include="/DEPENDENTLOADFLAG:0x800" Condition="$(RuntimeIdentifier.StartsWith('win'))" />
<!-- Native AOT invokes clang/gcc as the linker, so arguments need to be prefixed with "-Wl," -->
<LinkerArg Include="-Wl,-rpath,'/bin/'" Condition="$(RuntimeIdentifier.StartsWith('linux'))" />
</ItemGroup>
Native Exporte
Der native AOT-Compiler exportiert Methoden, die mit UnmanagedCallersOnlyAttribute annotiert sind, mit einer nicht leeren EntryPoint-Eigenschaft als öffentliche C-Einstiegspunkte. Dadurch können die kompilierten AOT-Module dynamisch oder statisch mit externen Programmen verknüpft werden. Es werden nur Methoden berücksichtigt, die in der veröffentlichten Assembly markiert UnmanagedCallersOnly sind. Methoden in Projektverweisen oder NuGet-Paketen werden nicht exportiert.
Weitere Informationen finden Sie im NativeLibrary-Beispiel.