Debugging Visual D using Visual D

Thu Aug 17 15:14:55 PDT 2017

On Thursday, 17 August 2017 at 21:18:35 UTC, Johnson Jones wrote:
> On Thursday, 17 August 2017 at 17:45:35 UTC, Rainer Schuetze 
> wrote:
>>
>>
>> On 17.08.2017 19:05, Johnson wrote:
>>> On Wednesday, 16 August 2017 at 19:35:19 UTC, Rainer Schuetze 
>>> wrote:
>>>>
>>>>
>>>> On 16.08.2017 21:18, Johnson Jones wrote:
>>>>> 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.
>>>>
>>>> The Visual D installer adds the extension to the VS 
>>>> installation ("c:\Program Files (x86)\Microsoft Visual 
>>>> Studio\2017\Community\Common7\IDE\Extensions\Rainer 
>>>> Schuetze\VisualD") so it is immediately available for all 
>>>> users and suffixes.
>>>>
>>>> You can move it to 
>>>> "%HOME%\AppData\Local\Microsoft\VisualStudio\15.0_<id>\Extensions\Rainer Schuetze\VisualD" to load it only with the version without suffix. With both the system wide extension and the one in the "Exp" folder, the extension from the user folder took precedence for me, though.
>>>>
>>>> If you run "devenv /RootSuffix Exp /Log" VS writes a log 
>>>> into 
>>>> "%APPDATA%\Roaming\Microsoft\VisualStudio\15.0_<id>Exp\ActivityLog.xml" that also lists detected extensions.
>>> 
>>> 
>>> I completely removed the `Extensions\Rainer Schuetze` 
>>> directories in all visual studio folders that I know of:
>>> 
>>> C:\Program Files (x86)\Microsoft Visual 
>>> Studio\2017\Enterprise\IDE\Extensions
>>> 
>>> C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469e
>>> C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469eExp
>>> 
>>> Running visual studio still loads Visual D. It seems that it 
>>> doesn't even use the visuald.pkgdef.
>>> 
>>> Obviously I have those entries in the registry. Which it 
>>> seems it pulls from and either doesn't use the extensions 
>>> folder at all on my system or is overridden by the registry 
>>> entries? If that's the case, how can it be worked around? If 
>>> not, what else might it be?
>>> 
>>> If visuald.pkgdef is suppose to be what visual studio uses to 
>>> load visual D as an extension, does it import that in to the 
>>> registry and then use the registry or does it always use the 
>>> pkgdef file?(which doesn't seem to be the case, as, again, 
>>> visual D is loading with visual studio without any of those 
>>> pkgdef's)
>>> 
>>> What I'm afraid of is that deleting the registry keys will 
>>> not do any good, they will just be re-imported by loading the 
>>> pkgdef(or not, in which case Visual D won't be found at all) 
>>> and then the main registry keys will be used for the Exp, 
>>> like it is now.
>>> 
>>> Basically visual studio is not loading the pkgdef files 
>>> either at all or only once, or every time but not allow them 
>>> to overwrite the registry keys, or something else is going on 
>>> that I can't seem to figure out.
>>> 
>>> 
>>
>> I think you are right that VS imports the settings from the 
>> pkgdef only once, then uses the registry only.
>>
>> Maybe try deleting the cache files in 
>> "%APPDATA%\Local\Microsoft\VisualStudio\15.0_<id>\Extensions".
>
> Ok, It seems to be caching. I deleted everything in the main 
> registry related to visualD and ran visual studio and it was 
> still there!
>
> Searched on line and came up with devenv updateconfiguration, 
> reran VS, and VisualD was no longer there! Ran experimental and 
> it's still there!
>
> Used the same process to remove it from Exp.
>
> So, this surely has to be caching, although I removed all the 
> cache files I could fine from both versions.
>
> As of this point there is nothing related to visualD in the 
> registry nor the VS folders as far as I can tell and both 
> versions are not finding visualD.
>
> I will copy the modified pkgdef file to the exp dir and run it: 
> Did nothing, Vi sual D didn't load! Copied the original pkgdef, 
> no go.
>
> Seems Visual studio is not using the pkgdef in
>
> C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469eExp\Extensions\Rainer Schuetze\VisualD
>
> I put the extensions folder in all the visual studio versions 
> in that base dir and it didn't help(so it's not using any 
> directory in 
> C:\Users\Main\AppData\Local\Microsoft\VisualStudio).
>
> Of course, at this point it means something is fubar'ed.
>
> I went ahead and installed latest VD so I could get some work 
> done. Seems like no problem.
>
>
> So either visual studio is not doing what it's suppose to or it 
> has more cache files laying around that I failed to delete, 
> unless you see something different?

[Just me going step by step for reference:

I should mention that after installing the latest, Visual D also 
gets installed in the Exp version ;/ so it "magically" propagated 
to it.

The evidence seems to point to visual studio simply loading 
visual D from the system registry and completely bypassing 
everything else. It doesn't even look at the pkgdef's(or looked 
at them once and installed them, then uses the registry 
thereafter).

Does the visualD installer install registry keys? or just the 
pkgdef file and then somehow informs VS and then VS does it?

My guess is that Visual D installs the registry keys, possibly 
wrong/old way, VS uses the registry always to load them for all 
versions. One can use pkgdefs but it won't do any good if the 
values exist in the registry because they seem to take precedence.

One thing I didn't do because I just thought of it was, after I 
removed all the registry data and cleared all the caches, was to 
go to extensions in visual studio and see if I had to enable 
them... maybe VS scans the pkgdef files and just presents them 
and one must enable them? So, it might have actually worked when 
I thought nothing was showing up.  I figured it would show up 
automatically but I might be wrong about that?

Let me try again: after deleting registry, running 
/updateconfiguration. VisualD still exists!!(the opposite of what 
happened last time) I didn't delete the default pkgdef file 
though. Doing that fixed and reclearing all the cache file fixed 
the problem and now visual D isn't showing up!

So, it seems that it first uses the registry then the pkgdef 
file. It seems like it doesn't import that in to the main 
registry since I rechecked, if that's correct then that is good. 
What it would say is that the visual D installer shouldn't be 
adding registry keys if it is.

Now, the test: Copying the pkgdef stuff to the exp install...

That time it showed up automatically in the exp install. I did 
use the new version so maybe the rc1 had a problem with the 
pkgdef or I screwed it up when I edited the first time... Anyways

What I have now is Visual D in Exp and not in normal. The only 
pkgdef is in the Exp apps dir.
]

Ok, So I think we've gotten somewhere.

1. Install Visual D.
2. Remove all registry entries related to it(not sure it this 
breaks icons and other stuff(or if it all is duplicated in the 
pkgdef file).
3. Move the pkgdef file from the program files visual studio 
install dir to the appdata local one for each version of VS. 
Modify them to point them to the VisualD versions one wants to 
use.
4. Run devenv /updateconfiguration on all versions of VS to 
modify and clear their cache files.

This should get them to be using the pkgdef files without using 
the main registry and shouldn't interfer with each other, the way 
it's suppose to be!

I've tried it this way 3 times and it seems to work.

I think you might try to modify the installer to not install reg 
keys and try to install the extensions in the appdata dir instead 
of program files, at least for v2017. That seems to be the 
cleanest way to do it. If someone wants to use a different 
version they just have to modify the appropriate package to point 
to it(a find/replace op on one file rather than having to copy a 
bunch of stuff).

It seems that having the same data in 3 places is quite confusing 
and doesn't give the desired results. Of course, it all might 
have just been some weird issue with my comp. A completely fresh 
install on a new system would be the best test.