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 ;/
