On 16.08.2017 04:49, Johnson wrote:
VisualD.dll C:\Program Files (x86)\VisualD\Debug\VisualD.dll
N/A Yes Symbols loaded. C:\Program Files
(x86)\VisualD\Debug\VisualD.pdb 229 0.45.1-rc2 12/31/1969 7:00
PM 13FB0000-143C0000* [8972] devenv.exe
VisualD.dll C:\Program Files (x86)\VisualD\VisualD.dll N/A
Yes Cannot find or open the PDB file. 271 0.45.1-rc2
12/31/1969 7:00 PM 18D40000-1904E000* [8972] devenv.exe
I was finally able to get it to work. Something is wonky. I think it's
when I use a normal VS side by side with the experimental that the
experimental can't find the symbols and somehow the registry changes I
made got reset.
So far it is working(I can hit BP's) but it's still basically the same
scenario in that I have to completely shut down VS in order to reload
visualD. Before I could automate because the normal visual studio
instance could stay open... but it seems like it screws up the debugging
symbols and such.
I could try to use another, different exp instance(different registry)
but I feel the same problem might occur.
But I guess it's better than nothing.
Good to hear it (kind of) works now. VS2015 also resets the
configuration rather often, so it's good to automate the patching.
I don't have troubles with exchanging the debug DLL while having the
normal VS instance running. Maybe you have experimented with registry
changes that now cause the debug DLL to be loaded there, too?
Reinstalling Visual D should help in that case (though that will trigger
rebuilding the user configuration).
I've tried to figure out why both DLLs are actually loaded (it has been
bugging me before, too), but could not find the cause yet.
