这是颇为曲折，所以大家多多包涵。 我有一个在本地（仅Win32的）C ++编码的第三方程序（“目标”）。 作为目标的设计的一部分，它实现了一个DLL的插件系统。 机DLL，放置在节目的“EXT”目录时，由目标加载。 然后，目标调用四种方法，每个DLL提供（初始化，SendHook，RecvHook，终止），为适当。 正如你可能已经从函数名猜到了，加载项的目标挂钩某些功能。 我没有源代码到目标。
其中一个加载项是老车 - 更不用提混乱，比较难看。 这是写在Delphi（编译为一个Win32 DLL，当然）。 在过去的几个星期，我一直在加强和翻译附加到C＃（我称之为的“扩展”）。 它现在已经完成，所以我把我的注意力，以获得目标加载扩展（这是建立一个类库）。
显然，目标（即本地C ++）不能直接加载所述延伸部（管理C＃）。 因此，寻找到它之后，似乎我只是需要一个“代理” DLL（写在VC ++与CLR的支持），可以加载我的分机，然后采取从目标传递方法调用扩展的照顾。
“简单。” 是的，没错。 我现在比彩虹糖的袋子变色龙更加迷茫。 我看到的东西有关使用COM，这是决定性的什么，我需要避免的，无论是在性能和进程的存储器权利方面的扩展将调用一些方法（通过句柄传递到代理）。 另外，我已经看到了有关TLB和＃进口指令东西。 这似乎并不像正确的路要走，无论是。
我偶然发现这篇文章https://sites.google.com/site/srinivasnzd/csincppviacpp-cli这似乎是最后在正确的轨道上。 事实上，我可以调用从C ++代理就好了我的托管C＃。 作为奖励，它出现 （我一直无法与实际的目标，以测试它尚未）的__declspec(dllexport)函数可以适当地称他们的管理同行虽然代理。 但现在的问题已经开始突然离开。
- 一个纯粹的本机进程可以加载CLR启用的DLL？ 我见过一个人（一个或多个）谈论从根本上让静态库了启用CLR代码，然后链接与从“局部管理，部分本土”代理DLL一个纯粹的本地代码。 但在这一点上，混乱开始设定，我是不知道的话题甚至适用于我想要做的事。
- 我该如何去编组的DWORD地址，一个IntPtr（然后取消编组对C＃侧的函数指针）
- 我看到的AppDomain中提到。 这是我需要担心？
- 我假设我的代理DLL都需要在同一个文件夹中管理扩展DLL运行。 我需要做什么特别的加载它，或将CLR和连接器采取照顾？
- 除了输出DLL，我得到的文件与“.EXP”，“.ilk”，以及名为“.lib”的延伸。 我认为这些都是静态链接的，我可以不理会他们，当我使用的DLL？
