We usually use VS development Time debugging program is to use ' F5 ' directly run the program, ' F5 ' run debugging will be automatically first global compilation, which saves us to ctrl+shift+b compile time.
However, when there are too many projects in the solution, each time you debug to press ' F5 ', you have to wait for the VS to global compilation of the entire solution, and this wait time depends on how much the project is, and too much of the project can be time-consuming.
One of my previous projects was a solution that contained more than 100 projects, and then each time the global compilation had to wait for 40s~90s, and the laptop was longer (I could go out and smoke, although I didn't smoke). So, debugging with ' F5 ' becomes quite unrealistic.
A good solution to this situation vs. is to debug a running program in a way that uses an additional process.
First step: We need to find the PID of the running program
Step two: attaching to a process
Finally, the program is in the debug state.
The benefit of debugging with an additional process is that you do not have to compile the entire solution at all, and which project you need to debug to compile.
PS: I often forget to compile the project when the code attach process for a project is debugged, and the result is:
Tip The source code is different from the original version, the breakpoint will not hit! People remember to warning.
Finally, this feature is very useful in medium-sized projects, small projects ... Not that necessary, after all, now the computer performance of a few project compilation time can be ignored
The writing is not good everyone will see it, welcome to correct and communicate.
VS debugging with an additional process