As we have already seen, static or dynamic linking is not as difficult as it may seem, as long as we are dealing with native code, but what happens when we, for example, decide to use code written in Assembly with a program written in C#, which is a managed environment and is not run by the processor itself, but rather by a sort of a virtual machine? Many are afraid of mixing native modules and managed ones. Using native modules compiled from Assembly sources with managed code may seem to be even more frightening or even impossible. However, as we have seen earlier, there is no difference between modules initially written in Assembly and those written in other languages on the binary level. When it comes to managed code like, for example C#, things are just a bit more complex than linking to native object files or using a DLL/SO. The following does not apply to managed C++ code, in which case you may simply follow the steps discussed earlier in this chapter, in order to link a native object to managed code, as managed C++ is the only language supported by Visual Studio that provides such capability.

In the case of C#, however, we are limited to DLL/SO as C# is a pure managed environment without the ability to digest native code in the form of an object file. In such a case, there is a need for a sort of a shim code, an adapter. In our example, we will use a simple class, which imports our core's functionality from crypto_wxx.dll on Windows or from libcrypto_xx.so on Linux and exposes it through its methods to the rest of the code.

There is a common misbelief that the .NET platform is Windows-specific. Alas, this is too common. However, .NET platform is, in reality, almost as portable as Java and supports quite a selection of platforms. However, we will concentrate on Windows (32/64-bits) and Linux (32/64-bits).