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.
