locked
Adding debug breakpoints during initialization RRS feed

  • Question

  • Hi -- Got something of a tricky question. I am writing an extensibility package (in C++ ATL, but that's not really relevant) and am debugging it by attaching to a Devenv.exe instance that uses the experimental registry hive. My package instantiates a custom virtual machine and the bootstraps a custom environment on top of it. I used to do this all in a single instance of Visual Studio, but my code was the actual project and it would grab its host IDE's DTE pointer from the Running Object Table and then add breakpoints programmatically as part of its initialization sequence. I am now trying to move this code over to being a Visual Studio package so that it can execute separately from an IDE-hosted project, and in doing so am now using the separate experimental-hive Visual Studio instance to actually execute the package. This means that my debugger and the code being debugged are now running under separate IDE instances and the DTE pointer I get hold of is to the target IDE and not the one hosting the debugger. So I can't just add breakpoints to the DTE debugger object I get, because it's the wrong debugger object. Nothing is being debugged via the experimental-hive debugger; in fact no project has even been loaded and the debugger object pointer actually comes back as null. But it's the other IDE that's running the debugger anyway, so I somehow have to find a way to add breakpoints to its breakpoint collection from the target it is debugging (which obviously isn't even in the same process). I'm assuming we're talking about some kind of DCOM call, assuming I can even find a way to get a remote pointer in he first place. Is this just too weird? Or do I have a prayer of figuring this out? Any thoughts would be greatly appreciated. Regards, Mike
    Tuesday, January 22, 2013 10:07 PM

All replies

  • All instances register DTE in the ROT (which is global), you could iterate the ROT looking for an object with the right process id (see here), it is odd you were using the ROT in proc, there are much simpler ways to get a DTE pointer in-proc.

    That said, to make sure I am clear you have this set up

    1: Custom project system that bootstraps a VM (on build? deploy? debug?)

    2:  A VS package that can attach to another instance of VS and set breakpoints as part of the 'pre build/deploy/debug' process?

    I think there is probably a more straight forward way to do this, specifically I believe your project system can supply IVsDebuggableProjectCfg and the debugger will use that to launch your target (i.e. your VM). In that code you could easily set up some 'just in time' breakpoints it seems. That woudl also eliminate the need to run your package in a seperate instance of VS, which seems somewhat unnatural of a setup, from a user perspective.
    Tuesday, January 22, 2013 10:58 PM
  • Hi -

    Thank you so much for your extremely quick response.   In the interim since I asked the question a few hours ago I have reproduced in the Package code the same logic I originally had when I was using a single IDE (essentially what you describe above about searching in the ROT and matching against process id).  This logic finds the Visual Studio instance whose DTE::Debugger::DebuggedProcesses collection includes the ProcessId of the Experimental Hive IDE that is the subject of debugging.   I'm sure it will work as soon as I figure out how to correctly cast the IUnkown pointer returned by the IRunningObjectTable::GetObjectW call to a valid DTE object (see my other question). 

    As for your suggestion about IVsDebuggableProjectCfg, I'm not sure it applies to me.  I am trying to create a package that doesn't care about the project system loaded into its IDE.  Thus I am trying to keep my functionality entirely separate from the project structure, adding its own document and designer types, but not caring what project structure they are added to.  So if I understand it correctly, I am not in a position to supply this interface, since it is not my project system being loaded.  Also, the only need I have to run a separate instance of VS is in following the debugging practices suggested in the literature, which dictates while debugging the package under development loading it into a separate IDE instance working off of the experimental registry hive.  When my package is ready for deployment, it will just load into a normal instance of the IDE and will not require the user to have two IDEs in the picture.

    Hope that clarifies things.

    Wednesday, January 23, 2013 1:33 AM