Jump to page: 1 2 3
Thread overview
August 13
So, just to let you know, I seemed to be able to setup Visual Studio so that I can debug Visual D(with visual D).

To do this:

Load the experimental hive:

https://blog.agchapman.com/updating-registry-settings-for-visual-studio-2017/

Load the privateregistry.bin file from %localappdata%\Microsoft\VisualStudio\15.0_[instanceid]{RootSuffix}\privateregistry.bin


Modify all visual D install dirs with a location one wants to use for the debugged version, there are quite a few. I simply made a sub-dir called debug and copied the original data to that location(and, of course, made a backup).

Create a way to copy the debug version of visual D to that directory(a build event, batch file, etc).

Then run visual studio with /RootSuffix Exp

https://msdn.microsoft.com/en-us/library/bb166560.aspx

It should load a new exp visual studio using the new visual D. Now one can copy the dll without issue since they are different versions being used.

The only thing left to do is have it automatically run visual studio on "start". There seems to be no csproj for visualD though so it can't be modified, I guess a post build event could be used.

Also, it seems that one can't disable building for a project. Visual D has several projects and I'm so used to building using F6 that I tend to rebuild the whole thing. Is it possible to get some way to disable building for a project in the solution?



August 13
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.




August 14

On 13.08.2017 23:14, Johnson Jones wrote:
> So, just to let you know, I seemed to be able to setup Visual Studio so that I can debug Visual D(with visual D).
> 
> To do this:
> 
> Load the experimental hive:
> 
> https://blog.agchapman.com/updating-registry-settings-for-visual-studio-2017/ 
> 
> 
> Load the privateregistry.bin file from %localappdata%\Microsoft\VisualStudio\15.0_[instanceid]{RootSuffix}\privateregistry.bin 
> 
> 
> 
> Modify all visual D install dirs with a location one wants to use for the debugged version, there are quite a few. I simply made a sub-dir called debug and copied the original data to that location(and, of course, made a backup).
> 
> Create a way to copy the debug version of visual D to that directory(a build event, batch file, etc).
> 
> Then run visual studio with /RootSuffix Exp
> 
> https://msdn.microsoft.com/en-us/library/bb166560.aspx
> 
> It should load a new exp visual studio using the new visual D. Now one can copy the dll without issue since they are different versions being used.

Thanks for figuring this out.

Maybe this can be automated with a combination of a registry import file prepared from the extensions' visuald.pkgdef and loading/unloading the private VS registry via "reg load/unload".

> 
> The only thing left to do is have it automatically run visual studio on "start". There seems to be no csproj for visualD though so it can't be modified, I guess a post build event could be used.
> 

I set Visual D as the startup project and "<VSPath>\devenv.exe" as the target executable to debug for this project.

> Also, it seems that one can't disable building for a project. Visual D has several projects and I'm so used to building using F6 that I tend to rebuild the whole thing. Is it possible to get some way to disable building for a project in the solution?
> 

I just use "Build startup project" to build. Building the whole solution is ok with C#, but usually no good with larger C++ or D projects.
August 14

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.
August 14
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.


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.




August 15

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.
August 15
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.
August 15

On 15.08.2017 19:31, Johnson wrote:
> 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.

dumpbin cannot display PDB files. You can use cvdump.exe from https://github.com/Microsoft/microsoft-pdb/tree/master/cvdump to do this. Your pdb file looks alright.

If you compile "Debug COFF32" conversion with cv2pdb should not be done, I guess it won't even be able to find any debug info.

The "Debug" configuration should create the PDB file with cv2pdb, but this might depend on the selected debug engine. mago understands the old CodeView information, so conversion is done only done for the VS debug engine (if "run cv2pdb" is configured to "if recommended for selected debug engine").

Whether you use the release or debug version of Visual D for the debugger devenv instance should not make a difference. You even don't need Visual D at all to use the debugger. IIRC only the expressions for the "Auto" window are supplied by Visual D.

Please double-check the module window. Is visuald.dll actually loaded from the path that you expect? Can you use explicit "Load Symbols" on it?

If I remember correctly, you only have VS2017 installed. I have some older versions of VS installed, too. Maybe there is still some component needed from older installations. I'll try to verify that...
August 16
Update:

When attaching I noticed that it was set to automatic(Managed) and switch it to native and now I do get a listing for VisualD.dll


	VisualD.dll	C:\Program Files (x86)\VisualD\VisualD.dll	N/A	Yes	Cannot find or open the PDB file.		149	0.45.1-rc2	12/31/1969 7:00 PM	10000000-1030E000	[18000] devenv.exe		


It seems to be loading the release version though and that is also presenting a problem.

I guess those registry hacks either got reverted or visual studio is not abiding by them.

Now I think I now what's going on. Maybe my original method of using the experimental version to load the debug version of Visual D won't work. Hence a slow and cumbersom process will have to be used of building Visual D, exiting, copying the files, loading it then attaching.

I'll try to see if something happened that is making the experimental visual studio load the installed visual D.

It might be what you said earlier about it still using it. Any ideas about that?

August 16
	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.

« First   ‹ Prev
1 2 3