Debugging Visual D using Visual D

[Johnson via Digitalmars-d-debugger]

On Wednesday, 16 August 2017 at 06:58:49 UTC, Rainer Schuetze 
wrote:
>
>
> On 16.08.2017 08:32, Rainer Schuetze wrote:
>> 
>> 
>> 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.
>
> I managed to load the Debug DLL into the "experimental" VS 
> without any (explicit) registry patching:
>
> 1. delete 
> HOME%\AppData\Local\Microsoft\VisualStudio\15.0_<id>Exp\privateregistry.bin to make sure to start from scratch
>
> 2. copy "c:\Program Files (x86)\Microsoft Visual 
> Studio\2017\Community\Common7\IDE\Extensions\Rainer 
> Schuetze\VisualD" to 
> "%HOME%\AppData\Local\Microsoft\VisualStudio\15.0_<id>Exp\Extensions\Rainer Schuetze\VisualD"
>
> 3. replace paths in Extensions\Rainer 
> Schuetze\VisualD\0.45\visuald.pkgdef to point to the debug DLL
>
> 4. start "devenv /RootSuffix Exp"
>
> 5. enable "Visual D" in the "Extensions and Updates..." dialog
>
> 6. restart VS
>
> This even doesn't load the DLL twice for me.

This isn't working for me, even though it looks like it should. 
Those values in the pkgdef are exactly the ones I replaced in the 
privateregistry hive, but it seems that for some reason it is not 
being used ;/ (since my changes are not propagating to it)

This should work as this is really no different that what I was 
doing except it is more of the correct way.  I'm not sure what's 
going on but I'll try and figure it out. I probably need to use a 
clean instance of VS

It seems I have something weird going on. I have

15.0
15.0_4d0b469e
15.0_4d0b469eExp
15.0Exp which is empty except for a path containing 
VSTemplateStore.pkgdef and I don't believe this existed 
yesterday. I think I just created it with the util I used as I 
was trying to reset the exp instance(which I thought was the 3rd 
one).

I'm not sure where the others came from but I'm going to create a 
new rootsuffix and try everything on that. I guess the 
15.0_4d0b469eExp is a _4d0b469eExp suffix and hence I'm not 
loading it ;/


Ok, I ran CreateExpInstance /create /VSInstance=15.0 
/RootSuffix=VisualDExp and it created a 15.0VisualDExp dir.

So, looks like the 15.0Exp was what I just created and it wasn't 
being used when I ran /RootSuffix=Exp.. which I guess, because it 
didn't exist, just used the original data.

I ran devenv.exe /RootStuffix VisualDExp

and it created

15.0_4d0b469eVisualDExp

So, something is funky. I guess 15.0_4d0b469e is the version. It 
loads, though, Visual D, so it is picking up the extensions from 
the original.

This seems to be a problem with Visual Studio ;/

Yeah, so, tried with a fresh exp copied all the stuff you 
mentioned, checked the files and same thing. I'm using enterprise 
on windows 10 creators so there might be bugs. It's clearly not 
loading the package changes I made so either it's bugged or it's 
loading them from a different place.

I'll try again tomorrow and see if things change ;/