Beyond debugging this issue -- Analysis of debugging failures in ASP. NET

Debug the token
-- ASP. NET debugging Failure Analysis

Friends who use VS. NET may often encounter the problem of being unable to debug ASP. NET. Some friends have provided some implementation solutions. The preliminary summary includes the following aspects (Note: The local debugging solution is discussed here ):
-Determine whether the current user has been added to the Debugger Users Group
-Determine whether the current user has the Administrator permission
-Whether the "allow ASP. NET debugging" attribute in the Web Application project property is set to True. You can also modify the debug attribute of the compilation element of the Web. config file to True.
Note that the operating systems required for local ASP. NET application debugging are Windows 2000 Professional, Windows 2000 Server, Windows 2000 Advanced Server, Windows XP Professional, and Windows Server 2003. That is to say, we cannot perform debugging on Windows XP Home, Windows ME, and Windows 98. (Nonsense ?)
Generally, we can use the above solutions to run ASP. NET debugging. If there is a problem, try to reconfigure IIS by using the. Net built-in ASPNET_REGIIS.EXE.
However, this article will discuss how to debug ASP. NET without the local Administrator permission. Does it sound unnecessary? But if you think about it carefully, you will realize the necessity of doing so. The reason is very simple. In most software companies with relatively formal management, developers are generally not granted the Administrator permission on the local machine, so how to debug ASP without the Administrator permission on the local machine.. NET application is the first problem to be solved. For this reason, I have consulted some materials (mainly MSDN online) and summarized a feasible solution, hoping to share it with you. Test environment: Windows XP Professional SP1, Vistual Studio. Net 2002.
First, add the currently logged-on user to the Debugger Users Group (In addition, this user must belong to the Users group at least. In most cases, developers are granted the Power Users permission ). By the way, if you want this user to maintain the Web virtual directory, you need to add this user to the VS Developers group. Of course, this has nothing to do with the ability to debug ASP. NET applications.
Next, according to Microsoft, if this user wants to debug ASP under Windows XP Professional. NET application, you also need to add this user to the "Log on as a batch processing job" Policy (of course, support for debugging ASP. in other versions of Windows. NET. You can add this in the Security Settings> Local Policies> User Rights Assignment> Batch Job logon section of the "Control Panel> Administrative Tools> Local Security Settings" tool. user. Unfortunately, the results are not as described in the relevant Microsoft documentation. After these settings are set, debugging can be performed. After a period of research, I found the answer from an article on MSDN Online. As we all know, by default, the ASPNET_WP.EXE process runs in the Web Server mode, and its user name is ASPNET. In this case, you must have the Administrator permission on the local machine to debug the Web Application. This is why we still cannot debug it. So how can we solve this problem ?. Net is ASP. NET users provide another solution. We can make ASPNET_WP.EXE run under a specified user as a working process. At this time, specify that the user can be debugged as long as it belongs to the Debugger Users Group. Finally, we can see the dawn of victory.
So how can I make ASPNET_WP.EXE run under a specified user account? The answer is, configure the configuration items in the machine. config file. Take VS. NET2002 as an example. This file is located in C: \ WINDOWS \ Microsoft. NET \ Framework \ v1.0.3705 \ CONFIG. What we need to do is find the processModel configuration item and modify the attributes of userName and password. Note: If you are using a domain user, enter <domain> \ username. Then, find the Temporary ASP. NET Files Properties directory, which is located in the same directory as the CONFIG directory. In the context menu, choose Properties> Security> advanced. The advanced security settings of Temporary ASP. NET Files Properties dialog box is displayed. In the "permission" tab, click "add" to add the specified user to the "permission project" list. Restart your computer.Note:The above operation requires the Administrator permission on the local machine, which must be supported by the system Administrator.
In the sense, it should be easier to configure. If you have any shortcomings, please kindly advise.