Debugging Visual D using Visual D

[Rainer Schuetze via Digitalmars-d-debugger]

On 20.08.2017 20:32, Johnson Jones wrote:
> On Friday, 18 August 2017 at 06:37:44 UTC, Rainer Schuetze wrote:
>>
> 
>>
>> Glad you figured it out. I had to enable Visual D in the extension 
>> manager when using the local pkgdef.
>>
>> Visual D installs for all users, so I think just installing into the 
>> users AppData is not an option. VS 2017 doesn't seem to inspect the 
>> "All Users" folders.
>>
>> The installer is not supposed to write to the system registry for 
>> VS2017 related components. I see some bad entries for mago and two 
>> entries for marshalling some data, though, but they don't seem to have 
>> an impact on extension detection (IIRC they are needed during build).
> 
> It writes a few clsID's I think. about 2 or 3, let me check...
> 
> Computer\HKEY_CLASSES_ROOT\TypeLib\{002a2de9-8bb6-484d-9903-7e4ad4084715}
> C:\Program Files (x86)\VisualD\vdserver.tlb
> 
> 
> Computer\HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{002A2DE9-8BB6-484D-980E-7E4AD4084715} 
> C:\Program Files (x86)\VisualD\visuald.dll

These are the ones referred to above that might be used during building.

> 
> 
> Computer\HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{002a2de9-8bb6-484d-aa05-7e4ad4084715} 
> C:\Program Files (x86)\VisualD\DParser\DParserCOMServer.exe

This one is needed to start the semantic engine as a local COM server.

> 
> Computer\HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{97348AC0-2B6B-4B99-A245-4C7E2C09D403} 
> 
> C:\Program Files (x86)\VisualD\Mago\MagoNatDE.dll
> 
> Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\MagoDebugger

In theory Mago is not a VS debug engine, but a system wide COM component 
that can be used by other debugger frontends, too. I haven't seen 
another application using it, though.

> 
> Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VisualD
> 
> 
> I also had to reinstall VisualD because for x64 the debugger would not 
> run. That probably came from me deleting one of those directories(the 
> ones referring to mago I guess).
> 
> So, I'm not sure if some of those keys are interfering with getting 
> isolation between the VS versions or what, but it seems that Visual 
> Studio load the registry version first before the extension package and 
> also then caches it. This makes it impossible to actually use the 
> isolated visual D even when everything is setup right as far as the 
> pkgdef's.
> 
> 
> 

IMO all of these registry keys should have no influence on extension 
loading.