digitalmars.D.ide - Visual D bug in paths
- Jo blow.net (26/26) Mar 21 2022 I had issues with old projects working correctly after upgrading
- Jo blow.net (6/6) Mar 21 2022 So I deleted the .vs directory and it fixed the debug source
- Rainer Schuetze (18/26) Mar 25 2022 AFAICT the "debug source files" usually only contain the directories of
- Jo Blow (37/66) Mar 25 2022 The exact error is a dialog that pops up saying:
- Rainer Schuetze (9/66) Mar 30 2022 The error code means "The requested operation requires elevation.". I
- Jo Blow (12/44) Apr 05 2022 It was checked, I tried unchecking and using various debuggers
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 2022
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 2022
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 2022
On Friday, 25 March 2022 at 09:18:09 UTC, Rainer Schuetze wrote:On 21/03/2022 21:38, Jo blow.net wrote:It didn't solve the problem ;/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?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 2022
On 26/03/2022 05:54, Jo Blow wrote:On Friday, 25 March 2022 at 09:18:09 UTC, Rainer Schuetze wrote: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 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."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 2022
Jo Blow <Jo Blow.net> On Wednesday, 30 March 2022 at 16:52:35 UTC, Rainer Schuetze wrote:On 26/03/2022 05:54, Jo Blow wrote: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).On Friday, 25 March 2022 at 09:18:09 UTC, Rainer Schuetze wrote: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 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 "
Apr 05 2022