We Keep Coding

How can I import in C#, methods of a class that are passed as a parameter of a function in a unmanaged dll?

I have an external API that gives me a header file (API.h) a dll and several working examples, but they only work in C++. And I need to use some functions of the API (Connect (), Disconnect (), newuser (), etc ...), from an custom website. And I'm looking for alternatives .... to use the minimum code conversion, bridges, etc ...
For now all I see feasible, is to create a WCF web service or a console application. But C++ is a lot of complex for me. So I'm trying from C# or VB. But while trying to import the dll I find the following problem:
I have used the appropriate utility from "cmd", and I see that the dll file have only 2 functions (exported), that are defined in the .h like this:
1-typedef int (*APIVersion)(void); -> I import very easily with [dllimport "my.dll"] and returns an value.
2-typedef int (*APICreate) (int version, ClassUserInterface **var); -> This class ClassUserInterface (double pointer), is defined in the header file and contains as "public", all the functions I need. E.g. "virtual int __stdcall Connection (LPCSTR ipserver) = 0;" also some of these functions uses enums and structures defined in the header.
My goal is to utilize the functions of the ClassUserInterface class from C # or VB to continue with my tests.
Does anyone know how I can make these calls related to how consume the class?
The basic import [dllimport "my.dll"] I know how do it.
Best regards

Parameters are incorrect after passing from C# to unmanaged dll

Have been trying all day and searching various sources but can't find a solution. I am calling an imported unmanaged dll function from c#.
C++ class looks like:
class MyModule
{
public:
MYMODULEDLL_API int __cdecl Init(int);
...
Defined in C# like this:
[DllImport("MyModule_x64.dll", EntryPoint =
"?Init#MyModule##QEAAHH#Z", CallingConvention = CallingConvention.Cdecl)]
public static extern int Init(int len);
And calling like this:
Init(configFileName.Length);
I can see in the debugger that the proper function in the dll is being called, but the passed parameter is corrupted showing a completely different value than what was passed. This is happening for string parameters as well. Is there anyway to troubleshoot the marshalling of parameters between managed and unmanaged code?

You can`t use C++ classes using DLLImport or PINVOKE, because it is suitable only for C style functions.
If you want to use C++ class in C#, you need to go with C++/CLI. You can create an unmanaged dll in native C++ and then create a simple C++/CLI wrapper which calls methods from native dll. After that you can simply add a C++/CLI managed dll to the project and use it as C# class without any DllImports and PINVOKEs. It will be a very flexible soltuion which is easy to expand. On MSDN you can find examples how to use C++/CLI.

Call functions on an instantiated C++ class returned by a PInvoke to a C function

I have an unmanaged DLL that exports C style non-member functions for creating (say CreateObject) and destroying objects (DestroyObject). CreateObject returns a C++ class as a void*, which in the unmanaged code is cast to a known interface (defined only in a header file) and worked with. Is there a way to call methods on the IntPtr that is returned to me by CreateObject?
Dumpbin /EXPORT doesn't show me any methods of the C++ class, just the exported C functions (mentioned above).
I would like to avoid having to write C++ CLI code or a purely unmanaged DLL that simply exposes methods on this class as function wrappers if possible
This is Windows/MSVC only, so answers that restrict compatibility to Windows/MSVC are fine.
NOTE: I'm talking about invoking C++ methods on a void*/IntPtr returned by a C function - not P/Invoking the C functions.
Thanks!

If you are ruling out C++/CLI, and only have an IntPtr containing the address of the instance then you have few options remaining.
As I see it you are left with p/invoke. In order to call a method you'll need to export it from your unmanaged code. You'll also need to be careful about the calling convention. Commonly it will be __thiscall. When you write the p/invoke, you must explicitly add the this pointer as the first parameter.
This is fine so far as it goes. But you'll not be able to export virtual methods this way. You cannot call them using p/invoke.
Frankly though the cleanest and simplest way to do this interop is with our old friend, tried and tested COM. This very scenario is just what it was designed for. C++ classes are not designed for interop across compiler/language boundaries. That's what COM is for.

class in managed c++ called from c#

I have a class decalred inside managed c++ dll as
public class IPHelper
{
public:
static void CheckIP(LPWSTR pSocketName);
static void DebugMessage(const wchar_t *str, ...);
private:
static DWORD GetIPInformation(PSOCKET_RECORD &pInfo);
};
I compiled it successfully and add it as reference to my c# project.
I am able to use the namespace, however the class seems empty and I'm unable to call the functions inside it.
Any ideas?

That class is not managed, it is native. You need to call it a public ref class if you want to use it from managed code.

You're going to need to invoke it using the P/Invoke method. See this reference for more information.

As others have noted, that's a native C++ class. Assuming your project is CLR enabled, then you can easily write a simple C++ / CLI wrapper around it, which will allow you to use it in a managed context.
This is a quick overview of C++ / CLI which should get you started in the right direction.

That class seems to be a hybrid. You specified public class IPHelper, which is halfway what you want. You should specify it as public ref class IPHelper. However even so, it will still not interface well with managed classes, because of the parameter types it receives. For instance a wchar_t is not the same as a System::String^ (managed C++ way to declare strings). Similarly a LPWSTR is also not the same as a System::String^. As a side note, it would be best for you to write some utility methods to convert between .NET System::Strings and wchar_t and other native strings that you will most likely need. This is an excellent article on MSDN on how to convert between all the various string types.
Now I don't know if you want to expose this class directly to C#, or have this class in turn wrapped by a better managed wrapper than what you have here. But anyway you do it, the Managed C++ class's methods have to take .NET types in order to be directly used in C# code.

Call a function from C# .exe with unmanaged C++ .dll

So, I have an executable file that was made with C#, I don't have its source code but I have disassembled it with IDA, and it gave me a lot of object oriented assembly.
I've made an .exe file that injects a .dll into another .exe, and I've injected this new C++ DLL into the C# .exe, with no problems, the DLLMain is called and so...
But when I inject this DLL into a normal .exe file made with C++, I can call a function in the .exe with its memory address which I can take on IDA.
The problem is, that object oriented assembly doesn't have addresses on its function, even with the function names being disassembled.
So, is there any way I can call this function with my injected DLL on the C# .exe file?
If possible, is there a way I can use the namespace declared in the C# .exe file and all its functions and variables, even being private?
Sample disassembled code:
.namespace MyCSharpApp
{
.class public auto ansi Test extends [mscorlib]System.Object
{
.field public value class [Microsoft.Xna.Framework]Microsoft.Xna.Framework.Vector2 pos
.field public int32 foo
....

You are trying to do something tricky and I'm not perfectly clear on what it is. From your description you have at least four things:
Managed EXE
Managed DLL
Unmanaged EXE
Unmanaged DLL
some of which you have control over (i.e. source code for), and some of which don't.
You want to use a process you call "injecting" to change a module you don't have control over to call a module you do have control over. In order to do this you are using a tool that requires you to have an unmanaged entry point in the address space of the process.
If you are getting what you want with unmanaged modules, then all you need to do is write a new mixed-mode module (over which you obviously have control) to call the managed DLL that you don't control. Now you effective have an unmanaged DLL (for export purposes) and the problem of it being managed has gone away.
To call managed code from your new unmanaged wrapper module, you can use the techniques described in this introductory article:
An Overview of Managed/Unmanaged Code Interoperability
Basically you need a C++/CLI project that references your black-box managed DLL and calls it and exports an unmanaged entry point that you can "take the address of" for your injection. Searching will find you a whole lot more ideas.
Finally, can you call private methods in the managed DLL (over which you have no control) using this method? No, not directly. However, its a managed DLL so it must have some public entry points to have ever been useful to anybody and you can call those. If that's not enough, you can use reflection from C++/CLI to call private methods and access private members.

You'll need to use the unmanaged hosting/debugging APIs. If you could inject a managed DLL, this would be much easier, you could just use Reflection.