www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ide - Visual D bug in paths

reply Jo blow.net <Jo blow.net> writes:
I had issues with old projects working correctly after upgrading 
to 2022.

The issue is that the "Debug source files" point to 2019 which 
were deleted upon upgrade.

That is, right mouse button on the project Solution in the 
Solution Explorer and click properties. Then go to Common 
Properties -> Debug Source Files. A new project uses ..\Microsoft 
Visual Studio\2022\Enterprise\... ...14.30... while the old 
projects point to ..\Microsoft Visual Studio\2019\Enterprise\... 
... 14.25...

And this gives an issue debugging the old project. I'm pretty 
sure the 2019 files don't even exist any more. IIRC I uninstalled 
everything having to do with VS before upgrading.

The issue is that there is no easy way to update the projects to 
get them to work.

My specific issue is that I could not debug the x86 project 
because it would give an error: "Cannot launch debugger on" which 
does not occur on creating a new x86 project(which led me to 
snooping around and seeing that the "debug source files" where 
different and the old one was pointing to the hold files.

I tried find a way to fix this but I couldn't. I think it must be 
using a pointer to something.

I guess a solution would be to detect those files and see if they 
exist and/or compare them to a new version and ask the user if he 
wants to upgrade the project or have a link in the visual d menu 
that can be used to update the project?
Mar 21
parent reply Jo blow.net <Jo blow.net> writes:
So I deleted the .vs directory and it fixed the debug source 
files so they now point to the 2022 install. I still cannot debug 
the old project in x86 mode even after messing with various 
debuggers(mago, mixed mode, visual studio). I've tried matching 
up the new working projects settings with the old and everything 
is the same so I have no idea what really is going on.
Mar 21
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 21/03/2022 21:38, Jo blow.net wrote:
 So I deleted the .vs directory and it fixed the debug source files so 
 they now point to the 2022 install. I still cannot debug the old project 
 in x86 mode even after messing with various debuggers(mago, mixed mode, 
 visual studio). I've tried matching up the new working projects settings 
 with the old and everything is the same so I have no idea what really is 
 going on.
 
 
AFAICT the "debug source files" usually only contain the directories of the Microsoft C++ header and source files. More directories are added there if you manually locate a source file that the debugger cannot find autoamtically. I don't see an update of those directories when loading a solution into VS 2022, even with VS 2019 still installed, so deleting the .vs folder seems like a good solution. I don't think these settings are vital to starting the debugger, though. I guess you are using the visualdproj projects. The "mago debug engine" that can be selected in the debugging options is a 32-bit engine only, so it doesn't work in VS 2022 anymore. The "mago extension" to the Visual Studio debugger is ported to 64-bit and works with both VS engines adding similar and more functionality. One thing I stumble over from time to time is that the VS project configuration dialog doesn't always open with the current configuration, so changes to the settings seem to have no effect. If that doesn't help: what is the exact error message you get?
Mar 25
parent reply Jo Blow <Jo Blow.net> writes:
On Friday, 25 March 2022 at 09:18:09 UTC, Rainer Schuetze wrote:
 On 21/03/2022 21:38, Jo blow.net wrote:
 So I deleted the .vs directory and it fixed the debug source 
 files so they now point to the 2022 install. I still cannot 
 debug the old project in x86 mode even after messing with 
 various debuggers(mago, mixed mode, visual studio). I've tried 
 matching up the new working projects settings with the old and 
 everything is the same so I have no idea what really is going 
 on.
 
 
AFAICT the "debug source files" usually only contain the directories of the Microsoft C++ header and source files. More directories are added there if you manually locate a source file that the debugger cannot find autoamtically. I don't see an update of those directories when loading a solution into VS 2022, even with VS 2019 still installed, so deleting the .vs folder seems like a good solution. I don't think these settings are vital to starting the debugger, though.
It didn't solve the problem ;/
 I guess you are using the visualdproj projects. The "mago debug 
 engine" that can be selected in the debugging options is a 
 32-bit engine only, so it doesn't work in VS 2022 anymore. The 
 "mago extension" to the Visual Studio debugger is ported to 
 64-bit and works with both VS engines adding similar and more 
 functionality.

 One thing I stumble over from time to time is that the VS 
 project configuration dialog doesn't always open with the 
 current configuration, so changes to the settings seem to have 
 no effect.

 If that doesn't help: what is the exact error message you get?
The exact error is a dialog that pops up saying: " cannot launch debugger on C:\projects\test\test\Win32\Debug\test.exe hr = 800702e4 " I thought it worked because I created a test project. It seems it has something specific to do with older projects. I can debug a new project in x86 using mago or visual studio x86 mixed mode. But in my older project I cannot get anything to work except for x64 debugging but my project uses x86 dlls that I cannot port to x64. I tried creating a new project so it seems like it is something fishy with my code. I'm using the requests library and simply drag and drop the folder in to the new project and copy over the code(which is just one file). The requests library gives me an error about "errors in imported modules: depreciated ... Usage of the 'body' keyword is depreciated. Use `do` instead." I can't imagine that causing a problem with the debugger but maybe? It works in x64 mode and the error doesn't stop a build. ------ Rebuild All started: Project: test, Configuration: Debug Win32 ------ Building Win32\Debug\test.exe... ..\..\test\test\requests\pool.d(281): Deprecation: Usage of the `body` keyword is deprecated. Use `do` instead. ..\..\test\test\requests\pool.d(370): Deprecation: Usage of the `body` keyword is deprecated. Use `do` instead. ..\..\test\test\requests\streams.d(1033): Deprecation: Usage of the `body` keyword is deprecated. Use `do` instead. 1 file(s) copied. ========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ========== The copied file is just a post build command that copies the exe. Any ideas?
Mar 25
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 26/03/2022 05:54, Jo Blow wrote:
 On Friday, 25 March 2022 at 09:18:09 UTC, Rainer Schuetze wrote:
 I guess you are using the visualdproj projects. The "mago debug 
 engine" that can be selected in the debugging options is a 32-bit 
 engine only, so it doesn't work in VS 2022 anymore. The "mago 
 extension" to the Visual Studio debugger is ported to 64-bit and works 
 with both VS engines adding similar and more functionality.

 One thing I stumble over from time to time is that the VS project 
 configuration dialog doesn't always open with the current 
 configuration, so changes to the settings seem to have no effect.

 If that doesn't help: what is the exact error message you get?
The exact error is a dialog that pops up saying: " cannot launch debugger on C:\projects\test\test\Win32\Debug\test.exe hr = 800702e4 "
The error code means "The requested operation requires elevation.". I guess that there might be some compatibility concerns regarding the windows version built into the executable. I suspect you are building the programs with the Digital Mars toolchain (which uses the OMF object fileformat and the optlink linker). Try enabling MS-COFF output on the Compiler->Output project configuration page.
 
 
 I thought it worked because I created a test project. It seems it has 
 something specific to do with older projects. I can debug a new project 
 in x86 using mago or visual studio x86 mixed mode.
 
 But in my older project I cannot get anything to work except for x64 
 debugging but my project uses x86 dlls that I cannot port to x64. I 
 tried creating a new project so it seems like it is something fishy with 
 my code.
 
 I'm using the requests library and simply drag and drop the folder in to 
 the new project and copy over the code(which is just one file).
 
 
 The requests library gives me an error about "errors in imported 
 modules: depreciated ... Usage of the 'body' keyword is depreciated. Use 
 `do` instead."
This is a message from intellisense, not the actual build.
 I can't imagine that causing a problem with the debugger but maybe? It 
 works in x64 mode and the error doesn't stop a build.
I doubt this is an issue.
 
 ------ Rebuild All started: Project: test, Configuration: Debug Win32 
 ------
 Building Win32\Debug\test.exe...
 ..\..\test\test\requests\pool.d(281): Deprecation: Usage of the `body` 
 keyword is deprecated. Use `do` instead.
 ..\..\test\test\requests\pool.d(370): Deprecation: Usage of the `body` 
 keyword is deprecated. Use `do` instead.
 ..\..\test\test\requests\streams.d(1033): Deprecation: Usage of the 
 `body` keyword is deprecated. Use `do` instead.
          1 file(s) copied.
 ========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========
 
 The copied file is just a post build command that copies the exe.
 
 Any ideas?
 
Mar 30
parent Jo Blow <Jo Blow.net> writes:
On Wednesday, 30 March 2022 at 16:52:35 UTC, Rainer Schuetze 
wrote:
 On 26/03/2022 05:54, Jo Blow wrote:
 On Friday, 25 March 2022 at 09:18:09 UTC, Rainer Schuetze 
 wrote:
 I guess you are using the visualdproj projects. The "mago 
 debug engine" that can be selected in the debugging options 
 is a 32-bit engine only, so it doesn't work in VS 2022 
 anymore. The "mago extension" to the Visual Studio debugger 
 is ported to 64-bit and works with both VS engines adding 
 similar and more functionality.

 One thing I stumble over from time to time is that the VS 
 project configuration dialog doesn't always open with the 
 current configuration, so changes to the settings seem to 
 have no effect.

 If that doesn't help: what is the exact error message you get?
The exact error is a dialog that pops up saying: " cannot launch debugger on C:\projects\test\test\Win32\Debug\test.exe hr = 800702e4 "
The error code means "The requested operation requires elevation.". I guess that there might be some compatibility concerns regarding the windows version built into the executable. I suspect you are building the programs with the Digital Mars toolchain (which uses the OMF object fileformat and the optlink linker). Try enabling MS-COFF output on the Compiler->Output project configuration page.
It was checked, I tried unchecking and using various debuggers but all the same issue. I tried removing the requests library and commenting out all the code except main and it's return but same thing. I copied the code to a new project and it works fine(can debug) so this seems to be something to do with a setting/configuration between the projects. I've compared the project settings and they are identical(having two VS's open on the settings pages and switching back and forth. Only thing different is the copy command on post-build).
Apr 05