Nilesh bhope Ответов: 2

На неуправляемом c++ &амп; в C++связывание


Я создал библиотеку Wrapper C++/CLI для вызова функции DLL 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.
	};
}


& amp; реализация cpp-файла

// Это основной DLL-файл.

#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);
}


Он хорошо работает и может вызывать PrintMessage, экспортированный из библиотеки dll C#.

Теперь я хочу добавить ссылку на библиотеку DLL TradeAPIWrapper в собственное приложение C++ и вызвать из него PrintMessage. Но когда я добавляю ссылку на проект TradeAPIWrapper, используя зависимости проекта в собственном проекте c++, он выдает ошибку System namespace not found. Я думаю, что родной проект c++ не идентифицирует dll C++/CLI. Как правильно добавить ссылку на dll C++/CLL в собственный проект C++ и вызвать функцию PrintMessage, выставленную в TradeAPIWrapper?

Что я уже пробовал:

Я пошел, хотя C++/CLI tutorials & не нашел решения для этого.

2 Ответов

Рейтинг:
2

Philippe Mori

Вы можете включать ссылки только в одном направлении.

Обычно, вероятно, можно было бы настроить его зависимости таким образом :

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


Похоже, что вы хотите сделать это там, где оболочка использует как родной C++, так и управляемый C#. Если это так, то вам нужно использовать обратный вызов mecanism. Это может быть интерфейс, объявленный в машинном коде, но реализованный оболочкой (которая затем может вызвать код C#).

В любом случае, у вас не может быть круговых ссылок.

В зависимости от сложности взаимодействий, какие технологии вы осваиваете и ваш существующий код, P/Invoke или COM могут быть возможными альтернативами. Каждый случай специфичен.

Единственная рекомендация, которую я бы сделал, - это избегать многоязычного приложения, если это можно сделать на одном языке за несколько дополнительных дней... так как это затрудняет разработку приложения, поскольку отладка, рефакторинг и IntelliSense не очень гладко пересекают языковые границы. Если это невозможно, то, по крайней мере, попытайтесь свести к минимуму количество зависимостей с помощью языкового переключателя. В прошлом, я сделал зависимостей, таких как C# ⬅ на C++/CLI и ⬅ языке C# ⬅ на C++/CLI и ⬅ C#, но он сделал ремонт сложнее.

Таким образом, я бы, вероятно, рассмотрел что-то вроде :
C# assembly ⬅ C# application
▲ 
C++/CLI ➡ C++ Native


где инъекция зависимостей будет использоваться для кода C++/CLI. Таким образом, C++/CLI будет реализовывать некоторый интерфейс из кода C#, но основное приложение не будет напрямую зависеть от него.

Однако я никогда не рефакторировал свое приложение таким образом... но я только преобразовал часть кода из C++/CLI в C#. Моя проблема заключалась в том, что в какой-то момент какой-то код нужно было переместить (так как я не использовал DI), и чтобы избежать еще большего перехода между языками, лучше всего было преобразовать код нескольких файлов (обычно я преобразовывал код C++/CLI в C#, используя в основном find and replace).


Рейтинг:
0

David A. Gray

Я даже не уверен, что ты сможешь это сделать. В любом случае, я подозреваю, что Вам повезет больше, если библиотека C# будет открыта через COM, а ваша библиотека C станет C++.