- This topic has 1 reply, 2 voices, and was last updated 2 months, 2 weeks ago by
.
-
Posts
-
6.0R3 build 5191, custom license, VS2022. I have a CMake based build where the CMake conditionally generates some C# projects, and some C++ projects. The VisualGDB CMake integration project conditionally sees only the C++ projects. The CMake generated visual studio solution sees the C# projects and the VisualGDB CMake integration project, so has ‘everything’. The target debug machine is an ARM/Linux system. The main program is C# but there are many C++ libraries that are part of the application. We have ‘host aliases’ set up for the build and target machines, so that multiple developers can clone the same source and use different build machines and debug targets. Standard stuff.
My main issue is pre-debug deployment to my debug target in two scenarios: running a C# program and doing managed debugging using the VSMonoDebugger plugin (that depends on managed and native code) and secondly running mono and doing native debugging of the .so libs using VisualGDB. I’m looking for a way to leverage VisualGDB’s features to help with deployment in these scenarios.
#1:
I’d like to be able to deploy VisualGDB build products (bunch of .so files) to the target when starting a C# debugging session (using VSMonoDebugger). There does not appear to be a way to hook deployment upon another event in Visual Studio? Is there a way to do this?
Even if there is not, I can create a custom shortcut (which will require another button push prior to starting debugging), but that shortcut is awkward since apparently I have to setup a ‘transfer single file’ step for each and every built file from its location on the build machine to the target machine (this does work, though, aside from the fact that custom shortcuts that are dozens of steps long don’t work well graphically in the GUI – no way to scroll the list – you’re limited by your screen height – try it!). I would rather use the synchronize directory or even better just the custom script steps, but can’t get these to work (the sync directory can’t flatten the build tree into a single directory with the built libraries on the target, and custom script file can’t properly expand the $(DeployHost) macro (it expands to ‘TargetMachine’, not my actual target’s hostname) so that the script running on the build machine can know what host to deploy the libraries to.
#2:
I’d also like to be able to do native debugging on my .so files being driven by the C# code. To accomplish this, I have a ‘debug only target’ in my VisualGDB project that runs mono. Starting to debug such a target won’t deploy any of the VisualGDB built .so files (there’s no build that depends on them, I guess?) or any of my C# code (since VisualGDB doesn’t know about any of that).
In the absence of a better solution that you might suggest, ideally I would have a way to run a VisualGDB custom shortcut via VS Command / macro. That custom shortcut would be able to have one step that copies files from the PC to the target (managed build products, other assets), and a second step that runs a script on the Linux build machine that can gather up and copy all the .so files and transfer to the debug target.
Both of these steps are not very compatible with the ‘synchronize directory’ steps as they need to pluck files from various build output locations and copy them to a (mostly) flat “install” directory ready for debugging.
The reason I’d want to be able to run a VisualGDB custom shortcut as a VS Command is to have a chance of hooking it up to either VSMonoDebugger or Visual Studio automation generally to try to get this all to work.
I’d appreciate any suggestions you might have.
Hi,
No problem. First of all, please try this build: VisualGDB-6.0.103.5206.msi. It fixes the BuildHost/DeployHost variable behavior and adds a height limit to the custom action list.
We also added a new command for deploying the output of the startup project (and its dependencies) without debugging (Debug->Deploy Project Output).
If you would like to combine it together with debugging the C# code, you would need to use a 3rd-party macro extension to set the startup project to the VisualGDB one, run the deployment command, set the startup project to the C# one, and finally launch the debug session. The DTE name for the “deploy project output” command is Debug.DeployProjectOutput.
If you would like to deploy the .so files and start debugging the mono process, the easiest way would be to define a dummy executable that is linked against all the .so files (so VisualGDB will treat them as dependencies and will deploy them), and then override the gdb/gdbserver command lines to actually debug mono instead of the dummy executable.
If you would still like to run the VisualGDB custom shortcuts programmatically, we can modify the DTE command handler on our side to accept the shortcut number (or name) as a parameter, if you have a convenient way of running custom DTE commands.
- You must be logged in to reply to this topic.