www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.debugger - Debugging Visual D using Visual D

reply Johnson Jones <JJ Dynomite.com> writes:
So, just to let you know, I seemed to be able to setup Visual 
Studio so that I can debug Visual D(with visual D).

To do this:

Load the experimental hive:

https://blog.agchapman.com/updating-registry-settings-for-visual-studio-2017/

Load the privateregistry.bin file from 
%localappdata%\Microsoft\VisualStudio\15.0_[instanceid]{RootSuffix}\privateregistry.bin


Modify all visual D install dirs with a location one wants to use 
for the debugged version, there are quite a few. I simply made a 
sub-dir called debug and copied the original data to that 
location(and, of course, made a backup).

Create a way to copy the debug version of visual D to that 
directory(a build event, batch file, etc).

Then run visual studio with /RootSuffix Exp

https://msdn.microsoft.com/en-us/library/bb166560.aspx

It should load a new exp visual studio using the new visual D. 
Now one can copy the dll without issue since they are different 
versions being used.

The only thing left to do is have it automatically run visual 
studio on "start". There seems to be no csproj for visualD though 
so it can't be modified, I guess a post build event could be used.

Also, it seems that one can't disable building for a project. 
Visual D has several projects and I'm so used to building using 
F6 that I tend to rebuild the whole thing. Is it possible to get 
some way to disable building for a project in the solution?
Aug 13 2017
next sibling parent reply Johnson Jones <JJ Dynomite.com> writes:
One can prevent building the other projects using the 
configuration manager. Seems to work fine.

One problem is that I cannot seem to get breakpoints to work. 
Same issues as I mentioned before with visual D saying the 
symbols haven't been loaded for the document. I do not know if 
it's the cross debugging issue or Visual D's issue though.
Aug 13 2017
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 13.08.2017 23:28, Johnson Jones wrote:

 One can prevent building the other projects using the configuration 
 manager. Seems to work fine.
 
 One problem is that I cannot seem to get breakpoints to work. Same 
 issues as I mentioned before with visual D saying the symbols haven't 
 been loaded for the document. I do not know if it's the cross debugging 
 issue or Visual D's issue though.
 
 


What configuration are you using? I recently switched to "Debug COFF32" 
as it produced the slightly better experience and doesn't need the 
cv2pdb build step. "Debug" should be fine, too, though.
Aug 13 2017
parent reply Johnson Jones <JJ Dynomite.com> writes:
On Monday, 14 August 2017 at 06:36:22 UTC, Rainer Schuetze wrote:

 On 13.08.2017 23:28, Johnson Jones wrote:

 One can prevent building the other projects using the 
 configuration manager. Seems to work fine.
 
 One problem is that I cannot seem to get breakpoints to work. 
 Same issues as I mentioned before with visual D saying the 
 symbols haven't been loaded for the document. I do not know if 
 it's the cross debugging issue or Visual D's issue though.
 
 


 What configuration are you using? I recently switched to "Debug 
 COFF32" as it produced the slightly better experience and 
 doesn't need the cv2pdb build step. "Debug" should be fine, 
 too, though.



Didn't help. To try it out, simply follow the steps I mentioned 
about creating a separate debug install

and add the build event(modify for your version of VS)

\visuald-0.45.1-rc2\bin\Debug\quick_install.bat & "C:\Program 
Files (x86)\Microsoft Visual 
Studio\2017\Enterprise\Common7\IDE\devenv.exe" 
SomeDSolutionToOpenForTesting.sln /RootSuffix Exp

The quick_install.bat just copies the various build files to the 
visual D debug install directory.

e.g.,

copy /Y "\visuald-0.45.1-rc2\bin\Debug COFF32\VisualD.dll" 
"C:\Program Files (x86)\VisualD\Debug"

What this does, is after a successful build, is copy the VisualD 
dll to the debug install version and loads up an experimental 
version of visual studio which uses that version if you updated 
it's hive, which I outlined above(takes about 3 mins to modify 
all the entries pointing to the original visual D install dir).

After that, build visual D and it should update the debug 
install, launch exp VS, open a D project and be ready for testing.

Then go to the first VS and attach process to the second, add 
BP's, such as on the backspace switch case, and then go in to the 
exp VS and hit backspace, it should break, but it doesn't and the 
BP's say there are no symbols loaded.


There is obviously a pdb file. I've copied it to the debug 
install dir and added the debug dir as a symbols directory so 
there is no reason why visual studio can't find it. I've also 
tried different debuggers(mago, visual studio, etc).

Given that this looks eerily similar to the BP problem I've 
experienced in the past with visual D doing normal projects(no 
cross debugging), it makes me believe it is a bug in visual D. 
Remember when I said I couldn't get any BP's for x64? You fixed 
that, then I've had instances where I couldn't get any for x86 
after the fix.
Aug 14 2017
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 14.08.2017 16:39, Johnson Jones wrote:

 On Monday, 14 August 2017 at 06:36:22 UTC, Rainer Schuetze wrote:

 On 13.08.2017 23:28, Johnson Jones wrote:

 One can prevent building the other projects using the configuration 
 manager. Seems to work fine.

 One problem is that I cannot seem to get breakpoints to work. Same 
 issues as I mentioned before with visual D saying the symbols haven't 
 been loaded for the document. I do not know if it's the cross 
 debugging issue or Visual D's issue though.


 What configuration are you using? I recently switched to "Debug 
 COFF32" as it produced the slightly better experience and doesn't need 
 the cv2pdb build step. "Debug" should be fine, too, though.


 
 
 Didn't help. To try it out, simply follow the steps I mentioned about 
 creating a separate debug install
 
 and add the build event(modify for your version of VS)
 
 \visuald-0.45.1-rc2\bin\Debug\quick_install.bat & "C:\Program Files 
 (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\devenv.exe" 
 SomeDSolutionToOpenForTesting.sln /RootSuffix Exp
 
 The quick_install.bat just copies the various build files to the visual 
 D debug install directory.
 
 e.g.,
 
 copy /Y "\visuald-0.45.1-rc2\bin\Debug COFF32\VisualD.dll" "C:\Program 
 Files (x86)\VisualD\Debug"
 
 What this does, is after a successful build, is copy the VisualD dll to 
 the debug install version and loads up an experimental version of visual 
 studio which uses that version if you updated it's hive, which I 
 outlined above(takes about 3 mins to modify all the entries pointing to 
 the original visual D install dir).
 
 After that, build visual D and it should update the debug install, 
 launch exp VS, open a D project and be ready for testing.
 
 Then go to the first VS and attach process to the second, add BP's, such 
 as on the backspace switch case, and then go in to the exp VS and hit 
 backspace, it should break, but it doesn't and the BP's say there are no 
 symbols loaded.


That's how I do it for VS2013 and VS2015 aswell (without the 
complications of the private registry). I use the Visual D debug output 
directory directly, so no copying necessary.

I tried it for VS2017 too, and it worked for me, too.


 
 
 There is obviously a pdb file. I've copied it to the debug install dir 
 and added the debug dir as a symbols directory so there is no reason why 
 visual studio can't find it. I've also tried different debuggers(mago, 
 visual studio, etc).
 
 Given that this looks eerily similar to the BP problem I've experienced 
 in the past with visual D doing normal projects(no cross debugging), it 
 makes me believe it is a bug in visual D. Remember when I said I 
 couldn't get any BP's for x64? You fixed that, then I've had instances 
 where I couldn't get any for x86 after the fix.
 


Please note that even with the (private) registry patched, it still 
loads Visual D twice, once from the debug directory, and once from the 
installation folder (see the module list). I suspect this happens 
because the global extension folder in 
%VSInstallDir%\Common7\IDE\Extensions is still scanned.

Breakpoints in viewfilter.d still point to the debug DLL and work for 
me, though.
Aug 15 2017
parent reply Johnson <Johnson Johnson.com> writes:
On Tuesday, 15 August 2017 at 07:01:34 UTC, Rainer Schuetze wrote:

 On 14.08.2017 16:39, Johnson Jones wrote:

 On Monday, 14 August 2017 at 06:36:22 UTC, Rainer Schuetze 
 wrote:

 On 13.08.2017 23:28, Johnson Jones wrote:

 One can prevent building the other projects using the 
 configuration manager. Seems to work fine.

 One problem is that I cannot seem to get breakpoints to 
 work. Same issues as I mentioned before with visual D saying 
 the symbols haven't been loaded for the document. I do not 
 know if it's the cross debugging issue or Visual D's issue 
 though.


 What configuration are you using? I recently switched to 
 "Debug COFF32" as it produced the slightly better experience 
 and doesn't need the cv2pdb build step. "Debug" should be 
 fine, too, though.


 
 
 Didn't help. To try it out, simply follow the steps I 
 mentioned about creating a separate debug install
 
 and add the build event(modify for your version of VS)
 
 \visuald-0.45.1-rc2\bin\Debug\quick_install.bat & "C:\Program 
 Files (x86)\Microsoft Visual 
 Studio\2017\Enterprise\Common7\IDE\devenv.exe" 
 SomeDSolutionToOpenForTesting.sln /RootSuffix Exp
 
 The quick_install.bat just copies the various build files to 
 the visual D debug install directory.
 
 e.g.,
 
 copy /Y "\visuald-0.45.1-rc2\bin\Debug COFF32\VisualD.dll" 
 "C:\Program Files (x86)\VisualD\Debug"
 
 What this does, is after a successful build, is copy the 
 VisualD dll to the debug install version and loads up an 
 experimental version of visual studio which uses that version 
 if you updated it's hive, which I outlined above(takes about 3 
 mins to modify all the entries pointing to the original visual 
 D install dir).
 
 After that, build visual D and it should update the debug 
 install, launch exp VS, open a D project and be ready for 
 testing.
 
 Then go to the first VS and attach process to the second, add 
 BP's, such as on the backspace switch case, and then go in to 
 the exp VS and hit backspace, it should break, but it doesn't 
 and the BP's say there are no symbols loaded.


 That's how I do it for VS2013 and VS2015 aswell (without the 
 complications of the private registry). I use the Visual D 
 debug output directory directly, so no copying necessary.

 I tried it for VS2017 too, and it worked for me, too.



Ok, so, what I realized was that I was still using the release 
version of visual D to try to attach to the debugged version. I 
guess I should use the release version to attach to the debug 
version and the exp debug version to attach to the another exp 
debug version, or just install the debug version as default(I was 
trying to avoid that since I use it for other projects right now).

I set it up and added C:\Program Files (x86)\VisualD to the 
symbols search list but no luck. Seems VS is simply not loading 
the pdb. (I've got it listed in several locations but it never 
shows up under modules)



 
 
 There is obviously a pdb file. I've copied it to the debug 
 install dir and added the debug dir as a symbols directory so 
 there is no reason why visual studio can't find it. I've also 
 tried different debuggers(mago, visual studio, etc).
 
 Given that this looks eerily similar to the BP problem I've 
 experienced in the past with visual D doing normal projects(no 
 cross debugging), it makes me believe it is a bug in visual D. 
 Remember when I said I couldn't get any BP's for x64? You 
 fixed that, then I've had instances where I couldn't get any 
 for x86 after the fix.
 


 Please note that even with the (private) registry patched, it 
 still loads Visual D twice, once from the debug directory, and 
 once from the installation folder (see the module list). I 
 suspect this happens because the global extension folder in 
 %VSInstallDir%\Common7\IDE\Extensions is still scanned.


Well, I tried a bunch of stuff and nothing seems to work. In the 
modules list, VisualD.pdb is not even listed(vdextensions is but 
for some path like C:\s\l\... which doesn't exist on my pc).

`dumpbin /headers`

Dump of file visualD.pdb
visualD.pdb : warning LNK4048: Invalid format file; ignored


I've tried launching the experimental VS which uses the debug 
version to debug another experimental instance but it too has the 
same problem. procmon shows that visualD.pdb isn't even searched 
for(at least it's now showing up).

This is all with debug coff as there is no pdb in for the 
standard debug.

Here's a link to the pdb.

https://ufile.io/eprlv

Maybe you can run dumpbin /headers on yours and see if errors out 
or not. If not, then it is something in the generation of it on 
my side(is it using cv2pdb(207,872 bytes?)).

Thanks.
Aug 15 2017
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 15.08.2017 19:31, Johnson wrote:

 On Tuesday, 15 August 2017 at 07:01:34 UTC, Rainer Schuetze wrote:

 On 14.08.2017 16:39, Johnson Jones wrote:

 On Monday, 14 August 2017 at 06:36:22 UTC, Rainer Schuetze wrote:

 On 13.08.2017 23:28, Johnson Jones wrote:

 One can prevent building the other projects using the configuration 
 manager. Seems to work fine.

 One problem is that I cannot seem to get breakpoints to work. Same 
 issues as I mentioned before with visual D saying the symbols 
 haven't been loaded for the document. I do not know if it's the 
 cross debugging issue or Visual D's issue though.


 What configuration are you using? I recently switched to "Debug 
 COFF32" as it produced the slightly better experience and doesn't 
 need the cv2pdb build step. "Debug" should be fine, too, though.



 Didn't help. To try it out, simply follow the steps I mentioned about 
 creating a separate debug install

 and add the build event(modify for your version of VS)

 \visuald-0.45.1-rc2\bin\Debug\quick_install.bat & "C:\Program Files 
 (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\devenv.exe" 
 SomeDSolutionToOpenForTesting.sln /RootSuffix Exp

 The quick_install.bat just copies the various build files to the 
 visual D debug install directory.

 e.g.,

 copy /Y "\visuald-0.45.1-rc2\bin\Debug COFF32\VisualD.dll" 
 "C:\Program Files (x86)\VisualD\Debug"

 What this does, is after a successful build, is copy the VisualD dll 
 to the debug install version and loads up an experimental version of 
 visual studio which uses that version if you updated it's hive, which 
 I outlined above(takes about 3 mins to modify all the entries 
 pointing to the original visual D install dir).

 After that, build visual D and it should update the debug install, 
 launch exp VS, open a D project and be ready for testing.

 Then go to the first VS and attach process to the second, add BP's, 
 such as on the backspace switch case, and then go in to the exp VS 
 and hit backspace, it should break, but it doesn't and the BP's say 
 there are no symbols loaded.


 That's how I do it for VS2013 and VS2015 aswell (without the 
 complications of the private registry). I use the Visual D debug 
 output directory directly, so no copying necessary.

 I tried it for VS2017 too, and it worked for me, too.


 
 
 Ok, so, what I realized was that I was still using the release version 
 of visual D to try to attach to the debugged version. I guess I should 
 use the release version to attach to the debug version and the exp debug 
 version to attach to the another exp debug version, or just install the 
 debug version as default(I was trying to avoid that since I use it for 
 other projects right now).
 
 I set it up and added C:\Program Files (x86)\VisualD to the symbols 
 search list but no luck. Seems VS is simply not loading the pdb. (I've 
 got it listed in several locations but it never shows up under modules)
 
 

 There is obviously a pdb file. I've copied it to the debug install 
 dir and added the debug dir as a symbols directory so there is no 
 reason why visual studio can't find it. I've also tried different 
 debuggers(mago, visual studio, etc).

 Given that this looks eerily similar to the BP problem I've 
 experienced in the past with visual D doing normal projects(no cross 
 debugging), it makes me believe it is a bug in visual D. Remember 
 when I said I couldn't get any BP's for x64? You fixed that, then 
 I've had instances where I couldn't get any for x86 after the fix.


 Please note that even with the (private) registry patched, it still 
 loads Visual D twice, once from the debug directory, and once from the 
 installation folder (see the module list). I suspect this happens 
 because the global extension folder in 
 %VSInstallDir%\Common7\IDE\Extensions is still scanned.


 
 Well, I tried a bunch of stuff and nothing seems to work. In the modules 
 list, VisualD.pdb is not even listed(vdextensions is but for some path 
 like C:\s\l\... which doesn't exist on my pc).
 
 `dumpbin /headers`
 
 Dump of file visualD.pdb
 visualD.pdb : warning LNK4048: Invalid format file; ignored
 
 
 I've tried launching the experimental VS which uses the debug version to 
 debug another experimental instance but it too has the same problem. 
 procmon shows that visualD.pdb isn't even searched for(at least it's now 
 showing up).
 
 This is all with debug coff as there is no pdb in for the standard debug.
 
 Here's a link to the pdb.
 
 https://ufile.io/eprlv
 
 Maybe you can run dumpbin /headers on yours and see if errors out or 
 not. If not, then it is something in the generation of it on my side(is 
 it using cv2pdb(207,872 bytes?)).
 
 Thanks.


dumpbin cannot display PDB files. You can use cvdump.exe from 
https://github.com/Microsoft/microsoft-pdb/tree/master/cvdump to do 
this. Your pdb file looks alright.

If you compile "Debug COFF32" conversion with cv2pdb should not be done, 
I guess it won't even be able to find any debug info.

The "Debug" configuration should create the PDB file with cv2pdb, but 
this might depend on the selected debug engine. mago understands the old 
CodeView information, so conversion is done only done for the VS debug 
engine (if "run cv2pdb" is configured to "if recommended for selected 
debug engine").

Whether you use the release or debug version of Visual D for the 
debugger devenv instance should not make a difference. You even don't 
need Visual D at all to use the debugger. IIRC only the expressions for 
the "Auto" window are supplied by Visual D.

Please double-check the module window. Is visuald.dll actually loaded 
from the path that you expect? Can you use explicit "Load Symbols" on it?

If I remember correctly, you only have VS2017 installed. I have some 
older versions of VS installed, too. Maybe there is still some component 
needed from older installations. I'll try to verify that...
Aug 15 2017
parent reply Johnson <Johnson Johnson.com> writes:
Update:

When attaching I noticed that it was set to automatic(Managed) 
and switch it to native and now I do get a listing for VisualD.dll


	VisualD.dll	C:\Program Files 
(x86)\VisualD\VisualD.dll	N/A	Yes	Cannot find or open the PDB 
file.		149	0.45.1-rc2	12/31/1969 7:00 
PM	10000000-1030E000	[18000] devenv.exe		


It seems to be loading the release version though and that is 
also presenting a problem.

I guess those registry hacks either got reverted or visual studio 
is not abiding by them.

Now I think I now what's going on. Maybe my original method of 
using the experimental version to load the debug version of 
Visual D won't work. Hence a slow and cumbersom process will have 
to be used of building Visual D, exiting, copying the files, 
loading it then attaching.

I'll try to see if something happened that is making the 
experimental visual studio load the installed visual D.

It might be what you said earlier about it still using it. Any 
ideas about that?
Aug 15 2017
parent reply Johnson <Johnson Johnson.com> writes:
	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.
Aug 15 2017
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
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.
Aug 15 2017
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
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.
Aug 15 2017
parent reply Johnson <Johnson Johnson.com> writes:
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 ;/
Aug 16 2017
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
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.
Aug 16 2017
parent reply Johnson Jones <JJ Dynomite.com> writes:
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.
Aug 16 2017
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
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.
Aug 16 2017
parent reply Johnson <Johnson Johnson.com> writes:
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.
Aug 17 2017
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
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".
Aug 17 2017
parent reply Johnson Jones <JJ Dynomite.com> writes:
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_4d0b469eE
p\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?
Aug 17 2017
parent reply Johnson Jones <JJ Dynomite.com> writes:
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_4d0b469eE
p\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.
Aug 17 2017
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 18.08.2017 00:14, Johnson Jones wrote:

 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_4d0b469eE
p\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.
 


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).
Aug 17 2017
parent reply Johnson Jones <JJ Dynomite.com> writes:
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.



 Aug 20 2017



 next sibling parent  Johnson Jones <JJ Dynomite.com>  writes:


I should state though, that I could be wrong(and haven't tested 
it out yet).  It's possible that some of the caching "features" 
screwed up what I think is going on. But the typical thing that 
got stuff to work was deleting the visual D entries in the 
registry(of course, it broke mago also). So, I'm not 100%. It may 
be no keys that are needed to be removed, just a few of them, or 
all of them.



 Aug 20 2017



prev sibling  parent  Rainer Schuetze <r.sagitario gmx.de>  writes:


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-484
-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-484
-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-4B9
-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.



 Aug 20 2017



prev sibling  parent  Rainer Schuetze <r.sagitario gmx.de>  writes:


On 13.08.2017 23:14, Johnson Jones wrote:

 So, just to let you know, I seemed to be able to setup Visual Studio so 
 that I can debug Visual D(with visual D).
 
 To do this:
 
 Load the experimental hive:
 
 https://blog.agchapman.com/updating-registry-settings-for-visual-studio-2017/ 
 
 
 Load the privateregistry.bin file from 
 %localappdata%\Microsoft\VisualStudio\15.0_[instanceid]{RootSuffix}
privateregistry.bin 
 
 
 
 Modify all visual D install dirs with a location one wants to use for 
 the debugged version, there are quite a few. I simply made a sub-dir 
 called debug and copied the original data to that location(and, of 
 course, made a backup).
 
 Create a way to copy the debug version of visual D to that directory(a 
 build event, batch file, etc).
 
 Then run visual studio with /RootSuffix Exp
 
 https://msdn.microsoft.com/en-us/library/bb166560.aspx
 
 It should load a new exp visual studio using the new visual D. Now one 
 can copy the dll without issue since they are different versions being 
 used.


Thanks for figuring this out.

Maybe this can be automated with a combination of a registry import file 
prepared from the extensions' visuald.pkgdef and loading/unloading the 
private VS registry via "reg load/unload".


 
 The only thing left to do is have it automatically run visual studio on 
 "start". There seems to be no csproj for visualD though so it can't be 
 modified, I guess a post build event could be used.
 


I set Visual D as the startup project and "<VSPath>\devenv.exe" as the 
target executable to debug for this project.


 Also, it seems that one can't disable building for a project. Visual D 
 has several projects and I'm so used to building using F6 that I tend to 
 rebuild the whole thing. Is it possible to get some way to disable 
 building for a project in the solution?
 


I just use "Build startup project" to build. Building the whole solution 




 Aug 13 2017