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.
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.
Breakpoints in viewfilter.d still point to the debug DLL and work for
me, though.
