Interoperabilidade nativa
Os seguintes artigos mostram as várias formas de fazer "interoperabilidade nativa" em .NET.
Há algumas razões pelas quais gostaria de chamar para o código nativo:
- Os sistemas operativos vêm com um grande volume de APIs que não estão presentes nas bibliotecas de classes geridas. Um exemplo privilegiado para este cenário seria o acesso a funções de hardware ou gestão de sistemas operativos.
- Comunicar com outros componentes que têm ou podem produzir ABIs de estilo C (ABIs nativos), como o código Java que é exposto através da Interface Nativa de Java (JNI) ou qualquer outra língua gerida que possa produzir um componente nativo.
- No Windows, a maior parte do software que é instalado, como o Microsoft Office suite, regista componentes COM que representam os seus programas e permitem aos desenvolvedores automatizá-los ou usá-los. Isto também requer interoperabilidade nativa.
A lista anterior não cobre todas as situações e cenários potenciais em que o desenvolvedor quereria/gosto/necessidade de interagir com componentes nativos. A biblioteca de classes .NET, por exemplo, utiliza o suporte de interoperabilidade nativa para implementar um número justo das suas APIs, como suporte e manipulação de consolas, acesso ao sistema de ficheiros e outros. No entanto, é importante notar que há uma opção, se necessário.
Nota
A maioria dos exemplos nesta secção serão apresentados para as três plataformas suportadas para .NET Core (Windows, Linux e macOS). No entanto, para alguns exemplos curtos e ilustrativos, apenas uma amostra é mostrada que usa Windows filenames e extensões (isto é, "dll" para bibliotecas). Isto não significa que essas funcionalidades não estejam disponíveis no Linux ou no macOS, foi feito apenas por conveniência.