Scott Nonnenberg erklärt in einem Video bei Channel9, wie man seinen eigenen Debugger Visualizer in VS 2005 erstellt.

After installing Visual Studio 2005 RC1 on my new DEVBOX, I copied my existing projects to the new machine and had to debug an ASP.NET 2.0 application.

The detailed scenario:

I'm running a ASP.NET 2.0(.50727)  application on Windows Server 2003 SP1.
The application is running as a website in her own AppPool running under his own user account ("DEVBOX\IWAM_CodeFairway", which is member of IIS_WPG and Debugger Users).
Integrated Windows Authentication is activated for this website (and it's virtual directories).
The application worked, but when I tried to debug it using VS 2005 RC1, I got the following error message:

"Unable to start debugging on the web server. Logon failure: unknown user name or bad password."

The solution:

Click Start -> All Programs -> Microsoft Visual Studio 2005 -> Visual Studio Tools -> Visual Studio 2005 Remote Debugger:

Then click "Tools" -> "Permissions" and add "DEVBOX\IWAM_CodeFairway". Grant "Debug" permission and click ok.

Visual Studio Remote Debugging Monitor can also be installed to run as a windows service. More details on this are in the help file.

Imho it is the easiest way to debug ASP.NET 1.1 applications as non-admin using VisualStudio.NET 2003, when you're following these instructions:

Grant the following rights to your LUA (= Limited User account) for the directories listed below:

&INSTALLROOT% is of the form c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322 and %WINDIR% is of the form C:\WINDOWS.

After this you have to add your LUA to the security groups 'Debugger Users' and 'VS Developers'

By default, with a restricted user login, you cannot debug Web applications because the user running the debugger is not a member of the proper group to debug other users' programs (Administrators), and the Web server started ASP.NET as the NETWORK_SERVICE account.

If you do not want to grant this login membership in the local Administrators group or run the debugger as the local Administrator, you need to change the account that ASP.NET is running as. On Windows XP Professional, edit machine.config as shown below and put in your username and password in clear text. This has the potential disadvantage of requiring all ASP.NET applications on the machine to run as your user account, but is the best method for IIS 5, and allows you to debug and build Web apps the same way you did in the past.

As an Administrator, edit the attributes of the file "%INSTALLROOT%\Config\machine.config" 'on the processModel tag, as shown:

<processModel
                enable="true"
                userName="DOMAIN\username"
                password="MyPassword"
                ...
/ >

If you do not set a restrictive ACL on the machine.config file, putting your userid and password in cleartext allows anyone to see your password. Even if you set a restrictive ACL, all users in the Administrators group will still be able to see it.

The resolution to the above security risk is the following: Use the aspnet_setreg.exe utility to put an encrypted version of the LUA's username and password in the registry by using the following command:

aspnet_setreg.exe -k:SOFTWARE\MY_SECURE_APP\processModel -u:"username" -p:"MyPassword"

Then modify the processModel as follows to point it to the registry:

<processModel
    userName="registry:HKLM\SOFTWARE\MY_SECURE_APP\processModel\ASPNET_SETREG,userName"
    password="registry:HKLM\SOFTWARE\MY_SECURE_APP\processModel\ASPNET_SETREG,password"
...... />

By default the DACL on the "HKLM\SOFTWARE\MY_SECURE_APP" hive grants Full Control to only System, Administrators and Creator Owner. Since ASP.NET is running under my userid, the caveat here is to make sure that I gave my userid (ex. "username") Read access to this registry hive where the userid and password are now stored.

My machine needed to be rebooted after modifying all these settings - so it won't by a disprofit if you do it also ;-)

Das Visual C# Team hat eine relativ umfangreiche FAQ zum Visual Studio.NET Debugger in Form eines Word-Dokuments veröffentlicht.

Außerdem hat bei mir bei ASP.NET Projekten folgendes schon geholfen:

• Das Projekt aus der Projektmappe entfernen und neu hinzufügen (Menüpunkt vorhandenes Projekt hinzufügen).
• Im Internet Explorer unter Extras / Optionen / Sicherheit / Lokales Intranet die Seiten http://localhost und http://127.0.0.1 hinzufügen.
• Ebenfalls im Internet Explorer: die Security Settings zurücksetzen.
• Ein weiterer Kanditat, der im Zusammenhang mit Windows Server 2003 Probleme bereiten kann, ist die "Internet Explorer Enhanced Security Configuration". Schlimmstenfalls sollte diese deinstalliert werden.

Bei LearnVisualStudio.NET ist ein neues Trainingsvideo verfügbar: Effective Debugging Techniques

Gezeigt werden Grundlagen wie das Setzen von Breakpoints, schrittweises Abarbeiten von Code, Step Into, Step Over, Step Out, das Auslesen von Variablen usw.

Das Video ist allerdings nicht für alle Ewigkeit frei verfügbar - deshalb sollte es bei Interesse sofort heruntergeladen werden.

Greggm hat eine Beschreibung gepostet, wie man Remote Debugging mit Visual Studio .NET 2002/2003 mit XP SP2 zum Laufen bekommt.