53

Currently I have solution A that contains a domain layer base and solution B that references the binaries from solution A. Is there a way to debug straight through from one to the other with two instances of Visual Studio open (one for each solution)?

I've read that you can just add the existing projects from solution A to solution B. Is there another solution that works? I've tried directly attaching solution A to what the running executable in solution B, but it won't let me attach multiple debuggers to the same application.

I should note that when I step into a piece of it, it automatically brings up the code from solution A within solution B's instance of Visual Studio to debug in. I suppose this is acceptable, but you can't just set arbitrary breakpoints and wait for the code to hit them this way.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Chris Cap
  • 1,056
  • 3
  • 13
  • 21

7 Answers7

38

There is no way to have two instances of Visual Studio debugging the same process. This is a limitation of Windows, and most other operating systems in that at most one process can be debugging another.

It is a perfectly supported scenario though to debug binaries that are not a part of your solution. As you've noted you can happily step into binaries from Solution B while debugging from a Solution A.

One item that will get in the way here though is the debugging feature named "Just My Code". This is a feature aimed at minimizing the debugging experience to just the code in your solution. It is great for normal solutions, but bad when you're debugging arbitrary binaries. It's likely causing a lot of the problems around break points you're seeing. You'll want to disable it by doing the following

  • Menu ToolsOptionsDebugging
  • Unchecked "Enable Just My Code"
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
JaredPar
  • 733,204
  • 149
  • 1,241
  • 1,454
  • 4
    Also see Chris's answer. You can set breakpoints to Solution A's source code in Solution B without adding projects to solutions. Point Visual Studio to A's PDB files (created during compile, see Chris's answer) and then open A's source file in Solution B. You can just open or drag-n-drop, you don't have to add it to the solution. One note, sometimes the breakpoint will look hollow (like it won't be hit) until it's assembly gets loaded, which could be at runtime. – Vimes Jul 31 '13 at 20:24
  • @JohnB When you say "drag-n-drop", what do you mean? If I drag a file from the solution explorer of one instance of VS 2010 to another, the only valid drag target is the text editor, and it just pastes a copy of the filename into the open document. If I drag the editor tab from one instance of VS I can't drop it into the other. Is there a quick and easy way to do this that doesn't involve messing around with file->open? – Weeble Mar 06 '14 at 14:07
  • 2
    @Weeble, I drag the source file from Windows Explorer onto the Visual Studio text area. For me, this opens file. – Vimes Mar 06 '14 at 22:51
23

You can only have one debugger debugging a process at once. So that means you only need one instance of Visual Studio open.

However, you can just open the .cpp/.cs/whatever file from Solution B into Solution A's copy of Visual Studio and set breakpoints. It'll still work even though those files aren't actually part of the solution.

Dean Harding
  • 71,468
  • 13
  • 145
  • 180
  • 10
    I have been using VS for 13 years and just learned from you that one can just open a source file that is not presented in the solutions being debugged and still allows the setting of breakpoints (if the pdb is found and the source file is at the same location and maybe other conditions, but still. I'll investigate further). Thanks a lot Dean – buckley Jul 29 '15 at 11:25
16

What if you explicitly load the symbols from Solution A?

If you go to menu ToolsOptionsDebuggingSymbols, you can point it at the .pdb file from Solution A.

Then you can see if the symbols are loaded from your binaries by going to menu DebugWindowsModules while debugging.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Chris
  • 6,642
  • 7
  • 42
  • 55
1

There is a simple fix for this.

Open both solution files and run them. Stop the second solution instance which you want attach to the process, but make sure that ports are running. Now you can attach the port process to the first solution instance and debug like magic.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
1

Here is what I did.

Say a project from solution A refers to a project from solution B and I want to debug into solution B project from solution A project.

Open solution B in Visual Studio. Set the project properties to "Use Local IIS Wb Server", set the project URL and create a virtual directory.

Open solution A in another Visual Studio instance. Set the project properties to "Use Local IIS Wb Server" and Check "Use IIS Express", set the project URL and create a virtual directory.

Press F5 and start debugging the solution B instance of Visual Studio. Then press F5 and start debugging the solution A instance of Visual Studio.

Now both the instances of Visual Studio will be in debug mode.

Start from solution A now and you should be able to debug into solution B just like if both projects were in the same solution.

The key here is to "Use IIS express" for one and "Local IIS Web server" for the other project. This will let you have two debuggers running at once.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
1

Here is a real and easy solution. Just change your solution properties to use the Multiple Startup Projects setting and set which project to start simultaneously.

Follow this:

Debug Multiple Projects at the Same Time in Visual Studio

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
CB4
  • 690
  • 3
  • 13
  • 25
  • 3
    There's a difference, though, between starting up multiple projects (if you need a server running, for example), and just referencing an external project so that you can step into the code. – Robert Harvey Oct 20 '17 at 20:49
0

Ensure the .dll and .pdb files are in the bin folder. You will be able to debug to the other solution opened in the other Visual Studio instance.

We usually have a folder (for example, Dependencies) where the DLL files are referenced from. Place the DLL file in this folder. The DLL files are pushed to this folder when we build the referenced project (using build events. There are other ways too).

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131