C++ Executable Calling a C# Dll

[kenrus]

I am developing a command line application in native C++. This application will eventually need to use a dll that a co-worker is developing in C#.

I don't know much about C#, but I am reading everything that I can find and learning as much as I can. Lately I have been trying to dig up information on how to call C# dll's from non-managed, non .NET languages.

From what I have been reading, it seems like this is not possible without writing an intermediate C++ managed layer.

Does anyone have any experience in doing this?

Thanks for any information.

[Eli Gassert]

You can do a few things:
1) You can use C++/CLI to integrate in with .NET, thus being able to call the managed code directly from within C++ (though your executable is then tied directly to .NET)
2) You can expose the .NET ASsembly as a COM object and make a COM call from C++

[kenrus]

That isn't good news, but it is what I needed to know. Thanks.

[kenrus]

You can do a few things:
1) You can use C++/CLI to integrate in with .NET, thus being able to call the managed code directly from within C++ (though your executable is then tied directly to .NET)
2) You can expose the .NET ASsembly as a COM object and make a COM call from C++

1 more question.

Is C# the language of choice if we want our dll to be usable by as many customers as possible who use a never ending assortment of languages.

I am thinking - no - but I don't want my lack of knowledge of C# or my knowledge of C++ to influence my decision.

Thanks again.

[Eli Gassert]

Lower level languages will give you the most flexibility. C++ DLLs can be called directly from C# (as well as _many_ other languages) without any additional code; you set up an external reference (to be called with PInvoke) to the DLL and .NET takes care of marshalling the data. C++ COM DLLs give you a wrapper, so you're not making direct method calls. But the support for .NET is less than direct method calls in a DLL. The benefit is that a C++ COM object doesn't require the .NET runtime. Then you get to managed ASsemblies. .NET is "the next big thing" so more and more things are supporting it natively. When you are in a situation where you can't use .NET directly but you can use COM, .NET can generate a COM interface for you which will invoke your .NET assembly. The catch here is that you still (obviously) need the .NET runtime installed because the COM interface simply exposes .NET to COM.

Edit:
The lower level is more cumbersome to work with (generally speaking) and the higher level is easier. That might sound like an obvious answer, but a standard windows DLL is functional; just function calls, not classes or any of that jazz. Higher up, though, gets more OO but also requires more to be compatible.


Does that answer your question?

[kenrus]

Does that answer your question?

Yes, and thanks for taking the time to answer.