[alexey_ma]

joker99:

По тому что .....???

Маршаллинг.
http://rsdn.ru/article/dotnet/coopdll.xml
и http://rsdn.ru/article/dotnet/complusnet.xml
Про тоже самое есть и в MSDN.
При успользовании неуправляемого кода из фреймворка вы получите в результате недостатки обоих.

joker99:
Нормально жрёт. Никто не жалуется

Жалуются, и еще как. Есть клиенты работающие на Citrix. Там каждый лишний мегабайт пямяти или процент CPU это катастрофа
Скажу по секрету что у нас есть один клиент который категорически отказывайтся покупать версию нашей программы в которой часть компонент написана на C# - он требует только нативный код, никаких фреймворков.

Во, нашел. Из MSDN :

COM Interop and Platform Invoke
COM Interop and Platform Invoke expose native APIs to 
managed code in an almost transparent way; calling most 
native APIs typically requires no special code, though it 
may require a few mouse clicks. As you might expect, 
there is a cost associated with calling native code from 
managed code and vice versa. There are two components 
to this cost: a fixed cost associated with doing the 
transitions between native and managed code, and a 
variable cost associated with any marshalling of arguments
 and return values that might be required. The fixed
 contribution to the cost for both COM Interop and 
P/Invoke is small: typically less than 50 instructions. The 
cost of marshalling to and from managed types will depend
 on how different the representations are on either side of
 the boundary. Types that require a significant amount of 
transformation will be more expensive. For example, all 
strings in the CLR are Unicode strings. If you are calling a 
Win32 API via P/Invoke that expects an ANSI character 
array, every character in the string has to be narrowed. 
However if a managed integer array is being passed where 
a native integer array is expected, no marshalling is 
required.

Because there is a performance cost associated with calling
 native code, you should make sure that the cost is
 justified. If you are going to make a native call, make sure

 that the work that the native call does justifies the 
performance cost associated with making the call—keep 
methods "chunky" rather than "chatty." A good way to 
measure the cost of a native call is to measure the 
performance of a native method that takes no arguments
 and has no return value, and then measure the 
performance of the native method you wish to call. The 
difference will give you an indication of the marshalling 
cost.


HINT   Make "Chunky" COM Interop and P/Invoke calls as
 opposed to "Chatty" calls, and make sure that the cost of 
making the call is justified by the amount of work that the
 call does.
Note that there are no threading models associated with 
managed threads. When you are going to make a COM 
Interop call, you need to make sure that the thread that 
the call is going to be made on is initialized to the correct 
COM threading model. This is typically done using the 
MTAThreadAttribute and STAThreadAttribute (though it can
 also be done programmatically).