How to step thru code using experimental instance? RRS feed

  • Question

  • I've a UI VS project (ProjA) which will be deployed to use in our VS environment eventually.

    When I hit F10 (step thru code), an experimental instance of VS2010 launched and the original VS2010 opened with ProjA went to the running/debug mode...

    What is the correct way to debug/step thru code in ProjA for VS extension?


    Wednesday, October 12, 2011 10:52 AM


All replies

  • You can use VS the usual way to debug your application: put breakpoints where you want and use VS Experimental to navigate to the code where your your breakpoint is... 
    Wednesday, October 12, 2011 11:36 AM
  • I put 2 breakpoints to my WPF source code (as my package is the UI based), however, those breakpoints didn't get hit.

    Also, I intentionally changed the OK button text to something funny like 'OKK' on my Dialog box Foo, and hit F5 to debug it.

    However, Foo dialog box still showed 'OK' button in the Experimental instance of VS2010.

    What did I miss?


    Thursday, October 13, 2011 12:34 AM
  • Did you see your package in 'Modules' from VS?

    Do you have Symbols loaded?

    Thursday, October 13, 2011 12:08 PM
  • Some background info, my VS2010 has already installed the package (let's say V1.0 of the package) and we have used it for awhile.

    What I'm working on is for the V2.0, and I'm assigned on this. Unfortunately, I'm new and just picking up on the VS package/SDK development.

    So what I've seen on the Experimental instance of VS2010 was most likely V1.0.

    And if you don't mind, can you let me know where to load the symbols (within Experimental instance?!)

    Thanks for your help.

    Thursday, October 13, 2011 6:16 PM
  • You have to see Modules in Visual Studio, not the experimental version, just like for any project:

    When running: Debug | Windows | Modules


    You will see a 'Name' column. Ensure your DLL module is listed here.

    You will see a 'Symbol File' column. Ensure it is not empty. It is empty, use contextual menu to load symbols (Load Symbols From | Symbol Path). 

    Thursday, October 13, 2011 8:30 PM
  • Thanks for the info.

    This is what I did,

    1. F5 to run the project (let's say Foo project and this project has been set as startup project)

    2. Experimental instance of VS2010 was up and running. The VS2010 with Foo project was in the debug mode.

    3. Go to Debug->Windows->Modules (while Foo project still in the debug mode).

    4. I could not see Foo.exe in the Modules window.


    What did I miss?


    Thursday, October 13, 2011 9:07 PM
  • I'm still completely missing what exactly you are attempting to do here.

    When you build a VS SDK package project, it is automatically registered with the experimental instance of VS.

    When you attempt to debug the package, (F5) your debugger settings are typically configured to launch devenv.exe with the following switch:

       /rootsuffix Exp

    Which indicates that the instance of VS you are launching to run using the experimental instance. If you have breakpoints set in the project loaded in the 1st instance of VS (the one that you launched the experimental instance from), these should be hit, provided that code is actually being run in the experimental instance.

    From the 1st instance of devenv.exe, if you select Break.All from the debugger, you should be able to view the list of assemblies/dlls loaded into the address space of the 2nd instance of devenv.exe (the experimental instance). Note, I think the debugee (the process your are debugging) has to be stopped (in break mode) for the modules window (the one in the 1st instance of devenv) to show your component.

    It sounds like there is some confusion as to which package you are debugging/seeing in the experimental instance. If you have updated the package and don't see the updated UI elements, chances are you aren't debugging what you think you are. Using the Modules toolwindow can help you there.

    You might also want to read up on how/what the experimental instance really is. Primarily it's a 2nd registry hive, that the 'experimental' instance uses, instead of the original registry hive (so as to ensure you don't wipe out your development environment with a bad package). Details on how this works can be found in the following blogs.







    Ed Dore
    • Marked as answer by Yi Feng Li Wednesday, October 19, 2011 3:25 AM
    Thursday, October 13, 2011 11:57 PM