Debugging Multiple Solutions in VS2010

I have two separate solutions, SolutionA and SolutionB. Solution A refers to the output of SolutionB as follows:

SolutionA
    ProjectA1
        References: ProjectB1.dll, ProjectB2.dll
    ProjectA2

SolutionB
    ProjectB1
    ProjectB2

      

What I would like to do is run SolutionA to debug the program, but then add a second IDE to debug Solution B (for example, to go through ProjectA1 to ProjectB1).

So far the only way I've been able to do this is by adding ProjectB1 to SolutionA, which forces you to test the solution in TFS and doesn't seem to be recognized as the same project for debugging purposes. Is there a way to do this?

+3


source to share


1 answer


We often encounter this problem with our larger projects that include exported libraries. The approach you are taking is correct and should work.

Starting with a source control issue: I've seen problems with TFS doing this because projects don't have a shared root folder - TFS doesn't like it when the project file is not in the child folder of the solution file location. It might try to remove the source control bindings from Project B1. I found that having separate workspaces where Project B1 is not in the current workspace for solution A helps a lot here. (Just be careful not to test your solution with Project B1 enabled, or other people receiving the solution might get weirder errors.)



If you are not considered the same project for debugging purposes, make sure you are referencing the correct config / architecture files they debugged and that the pdb files are available. As long as the source files are in the same folders where they were when the dll was built, VS should find them. You don't even need a project to solve this problem, VS will find the source files as long as they are available. Adding projects to the solution gives you additional navigation, intellisense, etc., although I would definitely go that route.

In the worst case, try changing the Project A1 reference to a temporary reference at the project level. Again, don't test your solution this way, but it's a quick way to get your debug process right.

+1


source







All Articles