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 any other 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 app.
I should note that when I step into a piece of 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.
Thanks
There is a simple fix for this.
Open both solution file and run it. Stop the the second solution instance which you want attach to process, but make sure that ports are running. Now you can attach port process to first solution instance and debug like magic.
Here is what I did.
Say a project from solution A refers 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 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 Virtual Directory.
Press F5 and start debugging Solution B instance of Visual Studio. Then Press F5 and start debugging 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.
There is no way to have 2 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. 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
Ensure the .dll and .pdb are in the bin. You will be able to debug to the other solution opened in the other Visual Studio.
We usually have a folder (ex. Dependencies) where the dlls are referenced from. Place the dll in this folder. The Dlls are pushed to this folder when we build the referenced project (using Build events, there are other ways too).
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.
What if you explicitly load the symbols from Solution A?
If you go to Tools->Options->Debugging->Symbols 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 Debug->Windows->Modules while debugging.