Debugging Visual D using Visual D

Wed Aug 16 12:18:51 PDT 2017

On Wednesday, 16 August 2017 at 17:54:39 UTC, Rainer Schuetze 
wrote:
>
>
> On 16.08.2017 16:48, Johnson wrote:
>> 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 ;/
>> 
>
> Starting with VS2017, it's supposed to be possible to have 
> different copies of VS installed. I guess the additional hex 
> value after 15.0 is represents each of these different 
> installations.
>
> I don't run "CreateExpInstance", I just start "devenv 
> /RootSuffix Exp" (or another suffix) which creates 
> 15.0_ade21380Exp for me. There is no 15.0 folder on my AppData 
> directories.
>

That's what I thought too, I have  15.0 folder that is empty. I 
had to install some pre-15 stuff to get some old stuff to compile 
and not sure if that was created from it or what. I only used 
CreateExpInstance today to try to start from scratch.  Again, I'm 
not sure what is going on but it seems like your method should 
work so I think it's on my end.  I think with a clean Exp install 
there should be no VisualD but there is, so somehow it is pulling 
in basically the non-exp setup instead of starting fresh.  I'll 
have look in to that to see if it's a known issue or if it's 
something else.

What's strange is that with your changes, privateregistry seems 
to use them... but it still loads the old(I think) visualD 
because when I try the debug the BP's are not hit and the module 
shows the original visualD directory.

It's most likely an issue with my setup. I might have to try to 
install on a virtual machine and see if the same behavior occurs 
or not. I'll double check things to make sure I didn't miss 
anything just in case.