You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This one is a bit of a complex question. I'm currently maintaining an extension that is built atop Microsoft's MI Engine for our in-house C++ projects. The projects themself are modified regular Windows C++ projects that include customized target and property files. The debugger part of this extension is also modified in certain parts to allow debugging on a very-low-performance system where fetching thread infos and stacks simply makes the debugging experience absolutely unbearable. I'm talking about pauses of more than half a minute when editing breakpoints and entering break mode. The upload procedure is also crammed into the debugging session start code and uses FTP since SFTP uploads are a multitude slower on this platform.
All of this is done in the "on before" handler for the debug command. The default debug command is canceled as part of this.
P.S.: Dirty project detection and rebuild logic is also shoved into the "on before debug" handler. ☹️
Two questions:
What would be the correct way to extend a C++ project like that? (With proper IntelliSense support for Linux/GCC code, deploy target, and dirty project detection.)
Any way of quickly "fixing" the debug command part, so that I can actually wire my customized debugger into my projects without hacky "on before" and "cancel default" handling?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
This one is a bit of a complex question. I'm currently maintaining an extension that is built atop Microsoft's MI Engine for our in-house C++ projects. The projects themself are modified regular Windows C++ projects that include customized target and property files. The debugger part of this extension is also modified in certain parts to allow debugging on a very-low-performance system where fetching thread infos and stacks simply makes the debugging experience absolutely unbearable. I'm talking about pauses of more than half a minute when editing breakpoints and entering break mode. The upload procedure is also crammed into the debugging session start code and uses FTP since SFTP uploads are a multitude slower on this platform.
All of this is done in the "on before" handler for the debug command. The default debug command is canceled as part of this.
P.S.: Dirty project detection and rebuild logic is also shoved into the "on before debug" handler.☹️
Two questions:
What would be the correct way to extend a C++ project like that? (With proper IntelliSense support for Linux/GCC code, deploy target, and dirty project detection.)
Any way of quickly "fixing" the debug command part, so that I can actually wire my customized debugger into my projects without hacky "on before" and "cancel default" handling?
Beta Was this translation helpful? Give feedback.
All reactions