title: Native C++ use C# dll via proxy C++ managed dll
body: <p>This is rather convoluted, so bear with me. I have a 3rd party program (the "target") that is coded in Native (Win32 only) C++. As part of the target's design, it implements a dll-plugin system. Native DLLs, when placed in the "ext" directory of the program, are loaded by the target. The target then invokes four methods that each DLL provides (Initialize, SendHook, RecvHook, Terminate) as appropriate. As you may have guessed from the function names, the add-ins hook certain functions in the target. I do not have the source code to the target.</p>
  
  <p>One of the add-ins is old and buggy - not to mention confusing and rather ugly. It's written in Delphi (compiled as a win32 DLL, of course). Over the past few weeks, I've been enhancing and translating the add-in to C# (I'll call this the "extension"). It's now complete, so I've turned my attention to getting the target to load the extension (which is built as a class library).</p>
  
  <p>Obviously, the target (being native C++) cannot load the extension (managed C#) directly. So, after looking into it, it seems I simply need a "proxy" DLL (written in VC++ with CLR support) that will load my extension and then take care of passing method calls from the target to the extension.</p>
  
  <p>"Simple." Yeah, right. I'm now more confused than a chameleon in a bag of Skittles. I've seen stuff about using COM, which is decidedly what I need to avoid, both in terms of performance and process-memory rights as the extension will invoke some methods (passed by handle to the proxy). Also, I've seen stuff about tlb and #import directives. This doesn't seem like the right way to go, either.</p>
  
  <p>I came across this article <a href="https://sites.google.com/site/srinivasnzd/csincppviacpp-cli" rel="nofollow">https://sites.google.com/site/srinivasnzd/csincppviacpp-cli</a> which seems to be at last on the right track. Indeed, I can call my managed C# from the C++ proxy just fine. As a bonus, it <em>appears</em> (I haven't been able to test it with the actual target yet) that the <code>__declspec(dllexport)</code> functions can appropriately call their managed counterparts though the proxy. But now the questions have begun popping off.</p>
  
  <ul>
  <li>Can a purely native process load a CLR-enabled DLL? I've seen someone(s) talk about essentially making a static lib out of the CLR-enabled code and then linking that with a pure native code to from a "partial managed, partial native" proxy DLL. But at that point, the confusion started setting in and I wasn't sure the topic was even applicable to what I'm trying to do.</li>
  <li>How do I go about marshaling a DWORD address to an IntPtr (and then un-marshaling it to a function pointer on the C# side)</li>
  <li>I saw mentions of AppDomains. Is this something I need to worry about?</li>
  <li>I'm assuming my proxy DLL will need to have the managed extension DLL in the same folder to run. Do I need to do anything special to load it, or will the CLR and linker take care of that?</li>
  <li>In addition to the output DLL, I'm getting files with extensions of ".exp", ".ilk", and ".lib". I assume these are for static linking and I can just ignore them when I use the DLL?</li>
  </ul>