Re: Debugging Visual D using Visual D
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.
Re: Debugging Visual D using Visual D
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.
Re: Problem with BP's
On Friday, 18 August 2017 at 00:02:23 UTC, Johnson Jones wrote:
On Thursday, 17 August 2017 at 22:41:51 UTC, Johnson Jones
wrote:
I was doing something strange ;/
I had code like
mixin(import("Myfile.d"));
CallSomeFunctionInMyFile();
And no BP's could be hit in side the function call. D would
say that there was an error in the symbols for the project.
but making MyFile.d a module(adding module MyFile; at the top)
and doing
import Myfile;
CallSomeFunctionInMyFile();
Allowed the breakpoints to be hit.
I guess this is a related problem with mixin debugging, which
still doesn't work for me. In a sense, it might be a good why
to debug them because the file exists already and one doesn't
have to have it generated by the compiler to debug. This
should help get the symbols and line numbers correct and the
line mappings. Might help make a seemless way to debug them.
e.g., any BP's in Myfile.d have to be translated to the
original file they are mixed in at and vice versa when
debugging them(open Myfile D).
Hmm, maybe that wasn't the fix, still getting the error in some
cases:
The error is "Unexpected symbol reader error while processing
test.exe"
It might have been coincidence that the above change worked or
it might be that it only partially fixed it.
What's strange about it is that delegates inside the function I'm
calling are hit but code in the root of the function are not.
void CallSomeFunctionInMyFile()
{
addDelegate(()
{
foo();
});
foo();
}
The first foo will break on a BP assinged to it but the second
one won't.
Re: Problem with BP's
On Thursday, 17 August 2017 at 22:41:51 UTC, Johnson Jones wrote:
I was doing something strange ;/
I had code like
mixin(import("Myfile.d"));
CallSomeFunctionInMyFile();
And no BP's could be hit in side the function call. D would say
that there was an error in the symbols for the project.
but making MyFile.d a module(adding module MyFile; at the top)
and doing
import Myfile;
CallSomeFunctionInMyFile();
Allowed the breakpoints to be hit.
I guess this is a related problem with mixin debugging, which
still doesn't work for me. In a sense, it might be a good why
to debug them because the file exists already and one doesn't
have to have it generated by the compiler to debug. This should
help get the symbols and line numbers correct and the line
mappings. Might help make a seemless way to debug them. e.g.,
any BP's in Myfile.d have to be translated to the original file
they are mixed in at and vice versa when debugging them(open
Myfile D).
Hmm, maybe that wasn't the fix, still getting the error in some
cases:
The error is "Unexpected symbol reader error while processing
test.exe"
It might have been coincidence that the above change worked or it
might be that it only partially fixed it.
Problem with BP's
I was doing something strange ;/
I had code like
mixin(import("Myfile.d"));
CallSomeFunctionInMyFile();
And no BP's could be hit in side the function call. D would say
that there was an error in the symbols for the project.
but making MyFile.d a module(adding module MyFile; at the top)
and doing
import Myfile;
CallSomeFunctionInMyFile();
Allowed the breakpoints to be hit.
I guess this is a related problem with mixin debugging, which
still doesn't work for me. In a sense, it might be a good why to
debug them because the file exists already and one doesn't have
to have it generated by the compiler to debug. This should help
get the symbols and line numbers correct and the line mappings.
Might help make a seemless way to debug them. e.g., any BP's in
Myfile.d have to be translated to the original file they are
mixed in at and vice versa when debugging them(open Myfile D).
Re: Debugging Visual D using Visual D
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_\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_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_\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_4d0b469eExp\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
Re: Debugging Visual D using Visual D
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_\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_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_\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_4d0b469eExp\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?
Re: Debugging Visual D using Visual D
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.dllC:\Program Files (x86)\VisualD\Debug\VisualD.dll N/AYesSymbols loaded. C:\Program Files (x86)\VisualD\Debug\VisualD.pdb229 0.45.1-rc212/31/1969 7:00 PM13FB-143C* [8972] devenv.exe VisualD.dllC:\Program Files (x86)\VisualD\VisualD.dllN/A YesCannot find or open the PDB file.2710.45.1-rc2 12/31/1969 7:00 PM 18D4-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_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_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
Re: Debugging Visual D using Visual D
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.
Debugging Visual D using Visual D
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?
Visual D: Unexpected symbol reader error while processing test.exe
I'm very few BP's are working now ;/ Getting that error on most of the lines of code I have https://ibb.co/cVVSSF Not sure why it broke all of a sudden. Since these things seem to be relatively random I'll play around with it after a while. Maybe a more informative error message could be added for things like this? or a logging feature? Whats strange is that the BP works in the delegate but not in the main program ;/
VisualD: Intellisense broke?
Tried to do some work this morning and Intellisense is not
showing.
Not sure what happened. Working fine yesterday.
It seems that when I converted my code to automatically generate
some fields, the semantic engine is not seeing them ;/
I went from something like
struct X
{
int a;
}
to
struct X
{
mixin("int a;");
}
and now x. doesn't list a.
(or rather, I'm using with(x) and a. does nothing (a is a struct
in that case))
There surely has to be a better way to get all this stuff to work
consistently? It isn't magic that's going on behind the scenes
and everything ultimately has to be well defined and meaningful.
Re: Visual D no bp's on x64
On Thursday, 3 August 2017 at 07:06:06 UTC, Rainer Schuetze wrote: On 31.07.2017 19:51, Johnson Jones wrote: On Saturday, 22 July 2017 at 12:54:17 UTC, Rainer Schuetze wrote: On 18.06.2017 20:25, Mike B Johnson wrote: [...] After installing VS2017 on a fresh Win10 install I could reproduce this issue: the mago debug engine failed to load the symbols when only VS2017 is installed, because the COM-CLSID to load msdia140.dll changed. Switching to the VS debug engine worked, though. Should be fixed in the next release. I installed a fresh VS2017 and the latest beta visual D and same issues. As of today, was this suppose to be fixed? It hasn't been released until now: https://github.com/dlang/visuald/releases/tag/v0.45.0 Thanks! Seems to be working.
