Interoperabilità nativa

Gli articoli seguenti illustrano i vari modi per eseguire l'interoperabilità nativa in .NET.

Esistono alcuni motivi per cui si vuole chiamare il codice nativo:

• I sistemi operativi sono dotati di un volume elevato di API che non sono presenti nelle librerie di classi gestite. Un esempio principale per questo scenario è l'accesso alle funzioni di gestione hardware o del sistema operativo.
• Comunicazione con altri componenti che hanno o possono produrre ABI di tipo C (ABI native), ad esempio codice Java esposto tramite Java Native Interface (JNI) o qualsiasi altro linguaggio gestito che potrebbe produrre un componente nativo.
• In Windows, la maggior parte del software che viene installato, ad esempio la famiglia di prodotti Microsoft Office, registra i componenti COM che rappresentano i programmi e consente agli sviluppatori di automatizzarli o usarli. Ciò richiede anche l'interoperabilità nativa.

L'elenco precedente non copre tutte le potenziali situazioni e scenari in cui lo sviluppatore vuole/vuole/vuole/deve interfacciarsi con i componenti nativi. La libreria di classi .NET, ad esempio, usa il supporto per l'interoperabilità nativa per implementare un numero equo di API, ad esempio il supporto e la manipolazione della console, l'accesso al file system e altri. Tuttavia, è importante notare che è disponibile un'opzione, se necessario.

Annotazioni

La maggior parte degli esempi di questa sezione verrà presentata per tutte e tre le piattaforme supportate per .NET Core (Windows, Linux e macOS). Tuttavia, per alcuni esempi brevi e illustrativi, viene mostrato un solo esempio che usa i nomi file e le estensioni di Windows ( ovvero "dll" per le librerie). Ciò non significa che queste funzionalità non sono disponibili in Linux o macOS, ma solo per praticità.

Vedere anche

• Platform Invoke (P/Invoke)
• Marshalling dei tipi
• Procedure consigliate di interoperabilità nativa
• Marshalling di runtime disabilitato