Re-writing already available functionality to C++ may be to tedious and make little sense. Finding C++ replacement (or even re-writing) for codes already provided by the libraries bundled with .NET can also be very hard. All this can challenge the very feasibility of the projects.
The viable option can be using .NET but exporting some of the functionality to unmanaged to be used by a C++ project. As ad-xing expressed interest in such option, I'll provide some detail. Usually a regular way to do this is implementation of COM component on .NET side.
There are certain problems with COM. I'm not too surprised ARopo commented that even total re-writing the code in C++ could be a better option.
The technology is gradually becoming obsolete. Main problem is overhead. In particular, normally it requires registration of a component in the system registry -- one of the major sources of registry contamination. .NET and Microsoft are trying to go away from such things in favor of local approach to component dependency and versioning. Also, COM approach will hardly be available for Unix (with Mono or other product).
In view of all that, a direct export from managed assembly to the unmanaged executable would be quite attractive. But how to do this?
A better solution is using IL where such export is allowed. There is a utility which helps to do it automatically based on available .NET project.
This is the best method I tried:
"Unmanaged code can wrap managed methods" by Emilio Reale, 29 Aug 2004.
See also this:
"How to Automate Exporting .NET Function to Unmanaged Programs" by Selvin, 22 Nov 2006, and this:
"C# Project Template for Unmanaged Exports" by Robert Giesecke, Jan 11, 2010.
Also, it may be helpful to look in my other Answer on a similar topic I've posted a while ago:
loading C# DLL in MFC[
^] where you can find some matter on motivation of such approach and useful discussion.
Dealing with .NET to C++ interoperability requires good understanding of both. However, it's not so hard if exported methods are limited to the use of primitive types and the types known to default Marshall methods, such as string to PCHAR or PWCHAR, etc. Anyway, learning of all that matter should be faster than re-writing of a big library.
Further questions are welcome.
Good luck!
—SA
Submit an article or tip