Please see my comment to the question; it's not clear what exactly do you mean by C++.
However, here is the idea: once you use C# anyway, you should also use C++/CLI
even if all or most of the C++ code is native. You can create a
mixed-mode C++ project (managed + unmanaged) and use managed part for, in particular, using other .NET assemblies. Your mixed-mode project will create an executable model, which, from the CLI point of view, can be used as a regular CLI assembly, for example, referenced by other assemblies. But, as your question is concerned, this might be not your goal. It simply allows you to use C# code. Even if you need to use it in unmanaged part of the project, you can wrap your managed "ref" class using C# assembly in unmanaged code and use in other unmanaged code.
(It is inherently difficult to use a CLI assembly in unmanaged code in any other way. (The opposite problem, using unmanaged code in CLI is easy enough.) The usual approach is using COM component, but why contaminate the installation and your code, as well as system registry, with obsolete technology which you don't need in .NET or unmanaged code?
Actually, there is a different way using the fact that IL actually allows to be exported to unmanaged, but this is also more difficult; please see my past answers:
loading C# DLL in MFC[^],
How can I use a dll created in Visual Basic 2008 in Visual Basic 6.0[^],
Call Managed DLL written in C# from Unmanged Code VC++[^],
API's in .Net: Managed or UnManaged Code[^].So, using C++/CLI, possibly in a mixed-mode project is the best way to solve such problem as soon as C++ is involved.
See also:
http://en.wikipedia.org/wiki/C%2B%2B/CLI[
^],
http://www.ecma-international.org/publications/standards/Ecma-372.htm[
^],
http://www.gotw.ca/publications/C++CLIRationale.pdf[
^].
—SA
Submit an article or tip