Debugging support for ASP.Net

From the CLR perspective, ASP.Net is just another managed application. You can just attach MDbg to it and start debugging. While this works, it has some limitations:
You need to:
1) make sure ASP.Net is deployed and started (since MDbg can only attach to an existing process).
2) You need to work out any security issues yourself (since MDbg doesn't have any special security knowledge).
3) figure out which process is ASP.Net (and get the right worker process).
4) figure out any cross-process causality (eg, associations between a web client and web server) yourself.

Azeem Khan (VS developer that consumes ICorDebug) explained to me that VS does several additional things to address these and improve the end user experience:

1. Being able to hit F5 or do a StepIn to deploy/debug your web service/app. The CLR debugging services itself has no cooperation with ASP.Net for deployment or startup.
2. VS works out which worker process is going to be executing user code by asking ASP .NET (we send the 'debug' verb) and then doing an auto-attach to that process i.e. user doesn't need to provide pid etc. If you just use MDbg, you need to determine this yourself.
3. VS supports web service causality, which includes:
    3a) Doing a StepIn at a call to a service causes VS to do an auto-attach behind the scenes and stop in the called service method (works out pid and sets a bp on called method etc).
    3b) Logical merged callstack from web client and web server.
4. Support for remote debugging.  Visual Studio does all the work here.
5. Lots of error checking, ability to open ports to enable remote debugging for user, etc. etc.  The CLR debugging services doesn't even have the ASP.Net semantics to have meaningful ASP.Net specific error checks.