Native interoperability

The following articles show the various ways of doing "native interoperability" in .NET.

There are a few reasons why you'd want to call into native code:

• Operating systems come with a large volume of APIs that aren't present in the managed class libraries. A prime example for this scenario would be access to hardware or operating system management functions.
• Communicating with other components that have or can produce C-style ABIs (native ABIs), such as Java code that is exposed via Java Native Interface (JNI) or any other managed language that could produce a native component.
• On Windows, most of the software that gets installed, such as the Microsoft Office suite, registers COM components that represent their programs and allow developers to automate them or use them. This also requires native interoperability.

The previous list doesn't cover all of the potential situations and scenarios in which the developer would want/like/need to interface with native components. .NET class library, for instance, uses the native interoperability support to implement a fair number of its APIs, like console support and manipulation, file system access and others. However, it's important to note that there's an option if needed.

See also

• Platform Invoke (P/Invoke)
• Type marshalling
• Native interoperability best practices
• Disabled runtime marshalling