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?

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?

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?
> 

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).