Debugging D DLL from C# app with C linkage for native Unity 5 plugin

[Thalamus via Digitalmars-d-learn]

On Wednesday, 30 March 2016 at 07:38:07 UTC, Benjamin Thaut wrote:
> On Tuesday, 29 March 2016 at 23:41:28 UTC, Thalamus wrote:
>>
>> dmd <obj files omitted for brevity> dllmain.d dll.def -w -wi 
>> -g -map -ofLogic.dll <res and lib files omitted for brevity> 
>> -m64 -debug -shared
>>
>> Anyone know what I should try next? Am I missing something 
>> simple? :)
>>
>> thanks!
>> Thalamus
>
> You should be using "-gc" instead of "-g" when building 64-bit 
> D programs that should be debugged with visual studio. 
> Otherwise the visual studio debugger might get confused over 
> some of the symbol names. (Because they contain '.')

Thanks Benjamin! I changed over to -gc.

I spent another couple of hours on this and finally figured it 
out. As it turns out, it wasn't necessary to change Just My Code. 
Enabling Mixed Mode debugging didn't work, but that's what set me 
down the path where I was able to find the answer.

Unity is an odd duck in a lot of ways. They use Mono to provide 
cross-platform portability, and that decision led them to use 
their own custom subset of .NET 3.5. Although I had eliminated 
Unity and Mono from the repro, I had accidentally left that 
subset on the C# EXE.

Because of this, VS uses a different managed code debugger (v3.5, 
v3.0, v2.0 instead of v4.6, v4.5, v4.0). This version doesn't 
play nicely with the Native debugger. By default, VS determines 
the debuggers to use automatically. So in this scenario, if you 
launch the EXE and then attach, it only loads the managed 
debugger (without telling you). If you select the old Managed and 
the Native debuggers in the Attach to Process dialog's Attach to: 
drop down list, an "Interop debugging is not supported" error 
pops up when you click Attach. (This is the same error you get if 
you select "Enable native code debugging" on the C# EXE's Debug 
property page.)

The solution is to select only Native or the older Managed 
debugger, but never both. That means that you can't hit F5 to 
launch the EXE in debug mode and then step through native code, 
which is inconvenient. But for my purposes debugging through 
Unity, attaching to an already running process is the only 
scenario I really need to work anyway. The C# layer is a very 
thin interop and marshaling layer between the C++ (hopefully soon 
D) core and Unity, so 99% of the time I'll need to debug only the 
native code anyway. The transition between the two is the only 
thing that can't be stepped through, and there isn't a whole lot 
to that.

As it turns out, I never saw this with the C++ version of the 
core logic because there were no C# projects in the solution, so 
VS automatically chose the Native one without my knowledge.

Hope this helps someone else in the future!

thanks,
Gene