А>Для решения какой-нибудь задачи типа внедрения dll в адресное пространство чужого процесса или работа с хуками клавы\мыши куда приятнее пользоваться родным кодом, чем импортировать кучу функций.
С трудом представляю, как для задачи внедрения можно применить managed code. Разве что внедрить загрузчик, поднять там хост и далее загружать сборку с managed кодом. Только вот зачем все это?

А>Самое простое — сделать COM-объект Stuff, реализовать в нем все, что надо, и пользоваться через Interop (дает комовский реюз, помимо прочего).
Честно говоря, простота такого решения кажется обманчивой. Ничего кроме написания лишнего кода я хорошего в COMе не вижу, и развития его не предвидится. Реюз же хорош ровно в том случае, если изначально нужен COM-объект (скажем, для использования в legacy коде). Делать же новое приложение на COMе непонятно зачем надо.

А>Еще можно написать managed компоненту на MC++.
Компоненту -- в смысле класс? Да можно. Подходящее по затратам решение, если API сложное и на C# через pinvoke тяжело получается.

А>А нет ли способа смешивать в одном csproj'е код шарпа и код MC++
csproj -- это c# project file. Конечно, он не может содержать код на MC++.