原生C ++& C ++ / CLI链接 [英] Native C++ & C++/CLI linking

查看:60
本文介绍了原生C ++& C ++ / CLI链接的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我创建了Wrapper C ++ / CLI库来调用C#DLL函数。



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

// 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.
	};
}





&实现cpp文件



//这是主要的DLL文件。





& Implementing cpp file

// This is the main DLL file.

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





效果很好&可以调用从C#dll导出的PrintMessage。



现在我想将TradeAPIWrapper dll的引用添加到本机C ++应用程序&从中调用PrintMessage。但是当我在本机c ++项目中使用项目依赖项添加TradeAPIWrapper项目的引用时,它会给出错误系统名称空间未找到。我认为本机c ++项目不识别C ++ / CLI DLL。如何在本机C ++项目中正确添加C ++ / CLL dll引用&调用TradeAPIWrapper中公开的PrintMessage函数?



我尝试过:



我已经通过C ++ / CLI教程&没有找到解决方案。



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.

推荐答案

我不确定你甚至可以做到这一点。在任何情况下,如果C#库通过COM公开,我怀疑你会好运,你的C库就变成了C ++。
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++.


你只能在一个方向包含引用。 />


通常,人们可能会设置它的依赖关系:

You can only include references in one direction.

Usually, one would probably setup its dependencies like that :
Native C++
    ▲   
C++/CLI wrapper
    ▲
C# assembly





看来你想要在哪里做包装器使用本机C ++和托管C#。如果是这样,那么你需要使用回调机制。它可能是在本机代码中声明的接口,但是由包装器实现(然后可以调用C#代码)。



在任何情况下,都不能有循环引用。



根据交互的复杂程度,您掌握的技术和现有代码,P / Invoke或COM可能是替代方案。每个案例都是具体的。



我唯一的建议就是避免使用多语言应用程序,如果可以在一些额外的时间内用一种语言完成...因为它可以由于调试,重构和智能感知在语言边界上不是很平滑,因此难以开发应用程序。如果不可能,那么至少尝试使用语言切换最小化依赖项的数量。在过去,我已经完成了C#⬅C++ / CLI⬅C#⬅C ++ / CLI⬅C#等依赖项,但它使维护更加困难。



因此,我会可能会考虑如下:



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





其中依赖注入将用于C ++ / CLI代码。这样,C ++ / CLI会从C#代码实现一些接口,但主应用程序不会直接依赖它。



但是,我从来没有以这种方式重构我的应用程序...但我只将部分代码从C ++ / CLI转换为C#。我的问题是,在某些时候,需要移动一些代码(因为我没有使用DI)并避免在语言之间进行更多转换,最好转换一些文件的代码(通常,我已经转换了C ++ / CLI代码到C#主要使用查找和替换。)



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).


这篇关于原生C ++& C ++ / CLI链接的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆