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