Is it possible to debug multiple projects at the same time in Visual Studio?
I know you can select multiple startup projects from the solutions properties, but how are the breakpoints handled?
If two projects use the same class (two different instances of it), and I am stopped with a breakpoint in it, will it only block one program or both? How can I know which executable is hitting the breakpoint? I'm a bit confused.
Yes, it is possible. You can set multiple startup projects in your solution (right-click solution, go to Set Startup Projects, choose Multiple startup projects), and specify the action for each project contained in the solution (None, Start, Start without debugging). If you have multiple projects set to Start, the debugger will attach to each one as it launches.
When you hit a breakpoint, you can see which process you're in using the Debug Location toolbar (you may have to show it; some profiles hide this by default). It will show which process you're currently looking at, which thread you're on, and which stack frame you're in:
I believe the default behavior is that when one process breaks, the debugger will break all of them. This way you can check the state of any attached process when you hit a single breakpoint.
No. You can debug an EXE file and step into a debug version of a linked DLL file, if you're careful about making sure the EXE file "sees" the same DLL file as the debugger, but you can't debug two EXE files at the same time. At least as far as I'm aware.
Related
Just as the title asks. I have solution with 5 projects in it. All dlls are connected with each other and whenever I start debugging, I can freely debug any of them. I'd like to add a separated project and access it's object by using reflection only (no references between the rest and 6th proj at all). Can I make it attach automatically to the debugger? I'm aware of function 'attach to existing process' but that's manual job.
You don't need anything special. Make sure you have pdb file next to the dll for that separate project, have source code locally matching to the version used to build that project, and possibly turn off "my code only" in tools -> options -> debug. At that point Visual Studio should pick up debugging information and allow you to set breakpoints and debug normally.
If PDB located somewhere else you can manually point to the PDP via debug->window->modules view by selecting "load symbols" from context menu on module you are interested to debug.
If sources don't match exactly you can instruct VS to use whatever you have also it likely will lead to confusing debugging experience (How does Visual Studio know if the source file matches the original version?).
You can put below line in your debugging dll ,in which function you want to debuge. it automatically ask you to attach with debugger
System.Diagnostics.Debugger.Launch();
I have a Visual studio solution containing multiple programs, each of which contains it's own Class and Main Method. I need to set these programs up to run one after the other, as some of them access the same database tables, and I do not want there to be conflicts.
I have tried setting up dependencies and creating a new program with class dependencies, however, this does not seem to have worked, does anyone have an idea?
Right click on your solution > Properties > Common Properties > Startup project
Select "Multiple startup Projects" and change the value of the Action column from "None" to "Start" or "Start without debugging"
Visual Studio is a development tool. It is not a tool to orchestrate how your application should execute. Your application should also function when executed outside Visual Studio.
With that in mind you need to decide how to partition your application. Right now you seem to have several applications (console programs?) that need to execute one after the other. An easy solution is to create a batch file that executes each in turn. You can also create a separate application that execute each "child" application in sequence using the Process.Start method but why bother when you can create a batch file?
You might also consider merging your different applications into a single application that has a Main method that executes each task in sequence.
Without more information about your problem it is hard to give you specific advice.
You mentioned you have tried "Multiple Startup Projects" approach but did you set the order in which multiple projects run when you start the debugger?
To set the order in which multiple projects run when you start the debugger
Open the Solution Property Pages dialog box.
Select the Startup Project set under Common Properties.
In the pane on the right, select Multiple Startup Project.
Select a project, and then click Move Up to run that project earlier when you start the debugger, or click Move Down to run the project later.
Reference: How to: Modify Project Properties and Configuration Settings
You need run each program in separate Visual Studio instances.
This has been driving me crazy and cutting down on my productivity all day. At one point for debugging I dragged an external file from another project into my current solution (Visual Studio 2010) so I could debug it as the class defined in it was being used by the solution I'm working on.
That was all well and good and after I was done I removed it from the solution and everything was normal. At some point however Visual Studio has decided that every single time I run my solution it will bring the external file back in as well as replacing the breakpoints that I used way back when for debugging. No matter how many times I remove the breakpoints and remove the external file from my solution this continues to happen every time I run.
I'm guessing there is some kind of file or setting saved somewhere that's telling VS to do this? Could anyone help me figure things out so I don't have to deal with breakpoints in a file I don't currently care about every time I need to run my application?
After stopping the debugger. Delete that break point manually either by opening that file or from the list of break points. Yes, visual studio stores this as part of the pdb file. Deleting that file is also an option if you don't mind losing all the debug information.
I have two web applications in the same solution. I put break points in both of them and when debug I can't access but the start up one. How to debug both of them?
Just right click on your project solution in visual studio then go to properties and in Common Properties > Startup Project select Multiple startup projects. Then choose the appropriate action.
That way you will be able to debug both
You can have only one active project at time of compilation/running. By the way, if one active project somehow calls something from another, just press F11 and you will jump into another project and symbols for it will be loaded automatically and you can debug it.
EDIT
If you are asking about debugging 2 projects contemporary in parallel, it's not possible with in one VS. If these are the separate projects that communicate with eash others, let's say chat application, you can naturally, by running two instances of VS and debug communication between them.
Hope this helps.
You should try to open two versions of visual studio, run both solutions, but set the start up project differently for each, and run them both. The two instances of visual studio should catch the break points of their respective start up programs. I know this works for windows/console applications. Although I've never tried it with 2 web applications. You may have to configure the applications to use different ports.
This is happening to me very often. When I am working in Visual Studio 2010 and say I make a code change, then build... Both my existing breakpoints become disabled / and or cannot be set and I also cannot set new breakpoints. Does anyone have a solution for this? It is very annoying. So far the only way I have been able to get around this is to restart Visual Studio which can take 5 to 8 minutes to reindex everything or to try rebuilding individual projects in my solution. My solution consists of several DLLs which make up the entire program.
Check that you have the dependencies set correctly in your projects. I know my breakpoints will become disabled if the code is "out of date". If you don't have the dependencies set up right, then when the updated code is rebuilt it will not rebuild all of the related code which will then leave those modules "out of date".
Since this is VS 2010, the dependencies are on the project not on the solution (you can add solution dependencies, but project dependencies will carry over into a new solution so it is the better way to go when possible).
This issue is caused when you having your Configuration Manager settings set to Release rather than Debug.
In Visual Studios select Build from the menu, then Configuration Manager.
In the next dialog select your project, then locate the drop down menu near the top left corner titled "Active solution configuration:" Make sure it is set to Debug.
That should fix the problem.
As it turns out the post.build file contained numerous conditions for whether or not it should copy several DLLs to a target directory... Since I didn't have time to pick through the xml for these actions I just used a bash script to copy the files after building. No need to get complicated... Otherwise, the formal solution involves setting conditions for allowing the DLLs to be overwritten/copied after compile or not.
I find the Visual Studio post.build file concept a little excessive since in the end it will make little difference whether a dll is overwritten with a freshly compiled version, yet, if you make code changes, compile, and it doesn't copy to the target directory you end up running your app with an out of date DLL and you are not testing with the recent code change..! Others have even implemented the post.build file complete with xml and goto statements...! Leave it to Microsoft to complicate the build & debug process...
Alternatively, if your code is under version control start afresh by checking out the head revision, do another clean and rebuild and start debugging again.
This for whatever reason enabled me to insert breakpoints in my VS 2010 C# project once again, whereas no amount of fannying around with properties, configurations etc got rid of my phantom breakpoint problem.
The best solution I found for this was to quit my Windows job and get another job as a Mac Developer where we use Xcode.! What a huge difference.! I sure haven't seen that breakpoints problem again.!