Współdziałanie natywne
W poniższych artykułach przedstawiono różne sposoby wykonywania "natywnej interoperacyjności" na platformie .NET.
Istnieje kilka powodów, dla których warto wywołać kod natywny:
- Systemy operacyjne mają dużą liczbę interfejsów API, które nie są obecne w bibliotekach klas zarządzanych. Doskonałym przykładem tego scenariusza jest dostęp do funkcji zarządzania sprzętem lub systemem operacyjnym.
- Komunikacja z innymi składnikami, które mają interfejsY ABI w stylu języka C (natywne interfejsy API), takie jak kod Java udostępniany za pośrednictwem interfejsu natywnego Java (JNI) lub dowolny inny język zarządzany, który może wygenerować składnik macierzysty.
- Na Windows większość instalowanego oprogramowania, takiego jak pakiet Microsoft Office, rejestruje składniki COM reprezentujące ich programy i umożliwiają deweloperom automatyzowanie ich lub korzystanie z nich. Wymaga to również natywnego współdziałania.
Poprzednia lista nie obejmuje wszystkich potencjalnych sytuacji i scenariuszy, w których deweloper chce/lubi/potrzebuje interfejsu z składnikami natywnymi. Biblioteka klas platformy .NET używa na przykład natywnej obsługi współdziałania, aby zaimplementować pewną liczbę interfejsów API, takich jak obsługa konsoli i manipulowanie nimi, dostęp do systemu plików i inne. Należy jednak pamiętać, że istnieje opcja w razie potrzeby.
Uwaga
Większość przykładów w tej sekcji zostanie przedstawionych dla wszystkich trzech obsługiwanych platform dla platform .NET Core (Windows, Linux i macOS). Jednak w przypadku niektórych krótkich i ilustracyjnych przykładów pokazano tylko jeden przykład, który używa Windows nazw plików i rozszerzeń (czyli "dll" dla bibliotek). Nie oznacza to, że te funkcje nie są dostępne w systemie Linux lub macOS, zrobiono to tylko dla wygody.