Debugging Visual D using Visual D

Wed Aug 16 10:54:39 PDT 2017

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.

I'm on Win10.0.14393 (pre-creator), VS 2017 community.