On Tuesday, 15 August 2017 at 07:01:34 UTC, Rainer Schuetze wrote:
On 14.08.2017 16:39, Johnson Jones wrote:
On Monday, 14 August 2017 at 06:36:22 UTC, Rainer Schuetze
wrote:
On 13.08.2017 23:28, Johnson Jones wrote:
One can prevent building the other projects using the
configuration manager. Seems to work fine.
One problem is that I cannot seem to get breakpoints to
work. Same issues as I mentioned before with visual D saying
the symbols haven't been loaded for the document. I do not
know if it's the cross debugging issue or Visual D's issue
though.
What configuration are you using? I recently switched to
"Debug COFF32" as it produced the slightly better experience
and doesn't need the cv2pdb build step. "Debug" should be
fine, too, though.
Didn't help. To try it out, simply follow the steps I
mentioned about creating a separate debug install
and add the build event(modify for your version of VS)
\visuald-0.45.1-rc2\bin\Debug\quick_install.bat & "C:\Program
Files (x86)\Microsoft Visual
Studio\2017\Enterprise\Common7\IDE\devenv.exe"
SomeDSolutionToOpenForTesting.sln /RootSuffix Exp
The quick_install.bat just copies the various build files to
the visual D debug install directory.
e.g.,
copy /Y "\visuald-0.45.1-rc2\bin\Debug COFF32\VisualD.dll"
"C:\Program Files (x86)\VisualD\Debug"
What this does, is after a successful build, is copy the
VisualD dll to the debug install version and loads up an
experimental version of visual studio which uses that version
if you updated it's hive, which I outlined above(takes about 3
mins to modify all the entries pointing to the original visual
D install dir).
After that, build visual D and it should update the debug
install, launch exp VS, open a D project and be ready for
testing.
Then go to the first VS and attach process to the second, add
BP's, such as on the backspace switch case, and then go in to
the exp VS and hit backspace, it should break, but it doesn't
and the BP's say there are no symbols loaded.
That's how I do it for VS2013 and VS2015 aswell (without the
complications of the private registry). I use the Visual D
debug output directory directly, so no copying necessary.
I tried it for VS2017 too, and it worked for me, too.
Ok, so, what I realized was that I was still using the release
version of visual D to try to attach to the debugged version. I
guess I should use the release version to attach to the debug
version and the exp debug version to attach to the another exp
debug version, or just install the debug version as default(I was
trying to avoid that since I use it for other projects right now).
I set it up and added C:\Program Files (x86)\VisualD to the
symbols search list but no luck. Seems VS is simply not loading
the pdb. (I've got it listed in several locations but it never
shows up under modules)
There is obviously a pdb file. I've copied it to the debug
install dir and added the debug dir as a symbols directory so
there is no reason why visual studio can't find it. I've also
tried different debuggers(mago, visual studio, etc).
Given that this looks eerily similar to the BP problem I've
experienced in the past with visual D doing normal projects(no
cross debugging), it makes me believe it is a bug in visual D.
Remember when I said I couldn't get any BP's for x64? You
fixed that, then I've had instances where I couldn't get any
for x86 after the fix.
Please note that even with the (private) registry patched, it
still loads Visual D twice, once from the debug directory, and
once from the installation folder (see the module list). I
suspect this happens because the global extension folder in
%VSInstallDir%\Common7\IDE\Extensions is still scanned.
Well, I tried a bunch of stuff and nothing seems to work. In the
modules list, VisualD.pdb is not even listed(vdextensions is but
for some path like C:\s\l\... which doesn't exist on my pc).
`dumpbin /headers`
Dump of file visualD.pdb
visualD.pdb : warning LNK4048: Invalid format file; ignored
I've tried launching the experimental VS which uses the debug
version to debug another experimental instance but it too has the
same problem. procmon shows that visualD.pdb isn't even searched
for(at least it's now showing up).
This is all with debug coff as there is no pdb in for the
standard debug.
Here's a link to the pdb.
https://ufile.io/eprlv
Maybe you can run dumpbin /headers on yours and see if errors out
or not. If not, then it is something in the generation of it on
my side(is it using cv2pdb(207,872 bytes?)).
Thanks.
