Native Code Interoperability

for RuBoard

Although the .NET Framework comes with a rich set of functionality, a tremendous amount of legacy code still exists. Organizations have spent millions and millions of dollars to create applications, libraries, and COM components . Rather than trying to force everyone to start from scratch, the .NET Framework was designed from the beginning to offer interoperability with existing native code.

Native code interoperability comes in two basic flavors in the runtime ”COM component interoperability (known as COM interop) and calling methods in native DLLs (known as Platform Invoke, or PInvoke). COM interop enables classic COM objects to be treated just like managed objects. Since classic COM objects already have some level of metadata information through IDL definitions, the translation to using them in managed code is rather transparent. Also, managed types can be treated as classic COM objects, making COM interoperability a two-way street. The most difficult challenge with COM interop is to properly marshal data between managed and native environments. The same difficulty in marshaling data is also true for PInvoke calls. However, in both cases, many types are automatically marshaled by the .NET Framework.

One serious problem with native code interoperability is that it is not possible to apply the same security rules to native code that can be applied to managed code. Type safety cannot be guaranteed with native code, so you can't be certain what will happen when you call a certain method via COM interop or PInvoke. Because of this, only highly trusted managed code should be allowed to call native COM objects or functions via PInvoke.

for RuBoard