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
