Poznámka
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Následující články ukazují různé způsoby "nativní interoperability" v .NET.
Existuje několik důvodů, proč byste chtěli využít nativní kód.
- Operační systémy přicházejí s velkým množstvím rozhraní API, které nejsou přítomné ve spravovaných knihovnách tříd. Základním příkladem pro tento scénář by byl přístup k funkcím správy hardwaru nebo operačního systému.
- Komunikace s dalšími komponentami, které mají nebo můžou vytvářet rozhraní ABI ve stylu C (nativní abI), jako je kód Java, který je vystavený prostřednictvím rozhraní JNI (Java Native Interface) nebo jakéhokoli jiného spravovaného jazyka, který by mohl vytvořit nativní komponentu.
- Ve Windows většina softwaru, který se instaluje, jako je například sada Microsoft Office, registruje komponenty modelu COM, které představují jejich programy, a umožňuje vývojářům automatizovat je nebo je používat. To také vyžaduje nativní interoperabilitu.
Předchozí seznam nepokrývá všechny potenciální situace a scénáře, ve kterých by vývojář chtěl/chtěl/potřeboval rozhraní s nativními komponentami. Knihovna tříd .NET například využívá nativní podporu interoperability k implementaci spravedlivého počtu jeho rozhraní API, jako je podpora konzoly a manipulace s nimi, přístup k systému souborů a další. Je ale důležité si uvědomit, že v případě potřeby existuje možnost.
Poznámka:
Většina příkladů v této části se zobrazí pro všechny tři podporované platformy pro .NET Core (Windows, Linux a macOS). U některých krátkých a ilustrativních příkladů se ale zobrazí jenom jedna ukázka, která používá názvy souborů a přípony Windows (to znamená "dll" pro knihovny). To neznamená, že tyto funkce nejsou k dispozici v Linuxu nebo macOS, bylo to provedeno jen kvůli pohodlí.