Native C++ & C++/CLI linking

Question

4.00/5 (1 vote)

See more:

I have created Wrapper C++/CLI library to call C# DLL function.

C#

// TradeAPIWrapper.h

#pragma once

using namespace System;

extern "C" __declspec(dllexport) void PrintMesssage(BSTR message);

namespace TradeAPIWrapper {

	public ref class Class1
	{
		// TODO: Add your methods for this class here.
	};
}

& Implementing cpp file

// This is the main DLL file.

C++

#include "stdafx.h"

#include "TradeAPIWrapper.h"

void PrintMesssage(BSTR message)
{
	HMODULE lib = LoadLibrary(L"TradeAPI.dll");

	//Create the function
	typedef void(*FNPTR)(BSTR message);
	FNPTR myfunc = (FNPTR)GetProcAddress(lib, "PrintMesssage");
	myfunc(message);
}

It works well & can call PrintMessage exported from C# dll.

Now I want to add reference of TradeAPIWrapper dll into native C++ app & call PrintMessage from it. But when I add reference of TradeAPIWrapper project using project dependencies in native c++ project, It is giving error System namespace not found. I think native c++ project is not identifying C++/CLI dll. How to properly add C++/CLL dll reference in native C++ project & call PrintMessage function exposed in TradeAPIWrapper?

What I have tried:

I have gone though C++/CLI tutorials & not found solution for this.

Posted 3-Nov-16 20:27pm

Nilesh bhope

Updated 11-Nov-16 10:03am

Add a Solution

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

David A. Gray · Answer 1 · 2016-11-10T20:20:00

Solution 1

I'm not sure you can even do that. In any case, I suspect you'll have better luck if the C# library is exposed through COM, and your C library becomes C++.

Posted 10-Nov-16 20:20pm

David A. Gray

Philippe Mori · Answer 2 · 2016-11-11T10:03:00

You can only include references in one direction.

Usually, one would probably setup its dependencies like that :

Native C++
    ▲   
C++/CLI wrapper
    ▲
C# assembly

It seems that you want to do it where the wrapper use both native C++ and managed C#. If so, then you need to use a callback mecanism. It might be an interface declared in native code but implemented by the wrapper (which can then call the C# code).

In any case, you cannot have circular references.

Depending on the complexity of the interactions, what technologies you master and your existing code, P/Invoke or COM might be possible alternatives. Each case is specific.

The only recommandation, I would have is to avoid multi-language application if it can be done in one language in a few extra days... as it make it harder to develop an application since debugging, refactoring and IntelliSense are not very smooth across language boundaries. If not possible, then at least try to minimize the number of dependencies with a language switch. In the past, I have done dependencies like C# ⬅ C++/CLI ⬅ C# ⬅ C++/CLI ⬅ C# but it has made the maintenance harder.

Thus, I would probably consider something like :

C# assembly ⬅ C# application
▲ 
C++/CLI ➡ C++ Native

where dependency injection would be used for C++/CLI code. That way, C++/CLI would implement some interface from C# code but the main application would not directly depends on it.

However, I never have refactor my application that way... but I have only converted part of the code from C++/CLI to C#. My problem was that at some point, some code need to be moved (as I was not using DI) and to avoid having even more transition between language, it was best to convert the code of a few files (usually, I have converted C++/CLI code to C# using mainly find and replace).