Systeemeigen code-interoperabiliteit met systeemeigen AOT

Systeemeigen code-interoperabiliteit is een technologie waarmee u toegang hebt tot niet-beheerde bibliotheken vanuit beheerde code of beheerde bibliotheken beschikbaar kunt maken voor onbeheerde code (de tegenovergestelde richting).

Hoewel systeemeigen code-interoperabiliteit op dezelfde manier werkt in systeemeigen AOT- en niet-AOT-implementaties, zijn er enkele specifieke kenmerken die verschillen bij het publiceren als systeemeigen AOT.

Directe P/Invoke-aanroepen

De P/Invoke-aanroepen in AOT-gecompileerde binaire bestanden worden standaard op een luie manier bij runtime gebonden, voor betere compatibiliteit. U kunt de AOT-compiler configureren om directe aanroepen te genereren voor geselecteerde P/Invoke-methoden die tijdens het opstarten zijn gebonden door het dynamische laadprogramma dat bij het besturingssysteem wordt geleverd. De niet-beheerde bibliotheken en toegangspunten waarnaar wordt verwezen via directe aanroepen, moeten altijd beschikbaar zijn tijdens runtime, anders kan het systeemeigen binaire bestand niet worden gestart.

De voordelen van directe P/Invoke-aanroepen zijn:

• Ze hebben betere stabiele statusprestaties.
• Ze maken het mogelijk om de niet-beheerde afhankelijkheden statisch te koppelen.

U kunt de directe generatie P/Invoke configureren met behulp van <DirectPInvoke> items in het projectbestand. De itemnaam kan modulenaam< zijn>, die directe aanroepen voor alle toegangspunten in de module mogelijk maakt, of <modulenaam!entrypointname>, waardoor alleen een directe aanroep voor de specifieke module en het toegangspunt mogelijk is.

Als u een lijst met toegangspunten in een extern bestand wilt opgeven, gebruikt u <DirectPInvokeList>-items in het projectbestand. Een lijst is handig wanneer het aantal directe P/Invoke-aanroepen groot is en het is onpraktisch om deze op te geven met behulp van afzonderlijke <DirectPInvoke> items. Het bestand kan lege regels en opmerkingen bevatten die beginnen met #.

Voorbeelden:

<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>

In Windows maakt Systeemeigen AOT gebruik van een vooraf ingevulde lijst met directe P/Invoke-methoden die beschikbaar zijn in alle ondersteunde versies van Windows.

Koppelen

Als u statisch een koppeling wilt maken met een of meer niet-beheerde bibliotheken, moet u voor elke bibliotheek <NativeLibrary Include="filename" /> opgeven dat verwijst naar een .lib-bestand op Windows en een .a-bestand op Unix-achtige systemen.

Voorbeelden:

<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>

Als de opgegeven systeemeigen bibliotheek afhankelijk is van andere statische bibliotheken, dan moeten ook NativeLibrary-items worden toegevoegd voor elk van de transitieve afhankelijkheden, anders mislukt de systeemeigen linker vanwege ontbrekende symbolen.

Platformconventies worden gevolgd als het gaat om de indeling van NativeLibrary vermeldingen. De onderliggende systeemeigen linker kan standaardbibliotheekpaden doorzoeken of geroote bestandspaden toestaan.

Als u extra vlaggen wilt opgeven voor de systeemeigen linker, gebruikt u het <LinkerArg> item.

Voorbeelden:

<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>

Oorspronkelijke exports

De systeemeigen AOT-compiler exporteert methoden die zijn geannoteerd met UnmanagedCallersOnlyAttribute met een niet-lege EntryPoint eigenschap als openbare C-invoerpunten. Hierdoor kunnen de gecompileerde AOT-modules dynamisch of statisch worden gekoppeld aan externe programma's. Alleen methoden die zijn gemarkeerd UnmanagedCallersOnly in de gepubliceerde assembly, worden overwogen. Methoden in projectverwijzingen of NuGet-pakketten worden niet geëxporteerd. Zie NativeLibrary-voorbeeld voor meer informatie.

Methoden die zijn geannoteerd met UnmanagedCallersOnly voeren geen marshalling uit en waarvoor blittable parameters en retourtypen zijn vereist. Vanaf .NET 11 genereert Native AOT, wanneer runtime-marshalling is ingeschakeld, InvalidProgramException als een niet-beheerde aanroeper een dergelijke methode aanroept met een niet-blittable handtekening, zoals een bool retourtype of een char parameter. De uitzondering zorgt ervoor dat het proces wordt beëindigd (onmiddellijk mislukt) en kan niet worden opgevangen om te herstellen van de ongeldige handtekening. Gebruik blittable-equivalenten of schakel runtime-marshalling uit in de assembly die de methode declareert voor ondersteunde niet-beheerde typen. Zie voor meer informatie Systeemeigen AOT weigert niet-blittable UnmanagedCallersOnly-handtekeningen.