VS Debugging Tips additional process

Using VS for a period of time the apes believe they've had this debug experience: each time you press F5 to debug the breakpoint, you have to wait for a long time: let the solution compile through, and then start the VS comes with the simple version of IIS as the server boot, and then open the browser, and finally the corresponding operation entered our breakpoint. If there are 30 projects in our solution, we can imagine how long we should wait. Think about it again. Co-development when it comes to assuming that our solution is wrong in one place. So other people just can anxious, waste a lot of precious time, then, there is no way to solve it? The answer is the additional process debugging that I'm going to say next.

In fact the principle is still the same. Just use the F5 when the VS self-active to the various actions to complete. Now we're going to do it manually.

The approximate process is for example the following:

1. Deploy the site to local IIS

Deployment of the site, is not the focus here, assuming that the less will be able to carry out Baidu. There are many tutorials. My test this time is by creating a virtual folder and then converting the target project into an application.

2. Browse for pages to debug in IIS

In the IIS-joined project, right-click the target page, select Browse, and wait for the browser to respond (this is the equivalent of starting the IIS process):

3. Attaching the IIS process to VS

Find the "Debug" menu in VS and choose "Join to Process". Then pop up for example the following dialog box. Tick "Show all in Session" to find the relevant process "W3wp.exe" in IIS, then click "Attach".

Let's say that we're not doing the VS with the admin, it will prompt you for permission. We right-click the icon of VS and select "Execute as Administrator" to do so. There is a more thorough way to find the VS program, right-click, select the "Compatibility" tab, and click "Execute this program as administrator" in the "Privilege level" check. Each subsequent execution of VS will be the Administrator identity.

After joining the process we will find that our vs is in the debug state, then we can follow the method we used to debug the corresponding.

This kind of debugging feeling a bit of trouble, in the solution of the project is not much and the cooperation of developers less than the case of F5 debugging feel more convenient. The advantage of this kind of debugging is. We don't have to wait for the VS every slow start and then go into the debug state. Because the steps were given to IIS and VS, it was quicker to start up. And for those who are often the trouble of being updated. This approach is undoubtedly a boon.

We can reduce the error of other people as much as possible.

"Not afraid not to know. Be afraid of not know ", existence is reasonable. Maybe someone else is using a seemingly clumsy method when we're crazy about a problem, so. We should broaden our horizons as much as possible. Come on, man!

Vs Debugging Tips for additional processes