| Prev | Next |
Debug ASP .NET
Debugging for web services such as ASP requires that the Enterprise Architect debugger is able to attach to a running service.
Begin by ensuring that the directory containing the ASP .NET service project has been imported into Enterprise Architect and, if required, the web folder containing the client web pages.
If your web project directory resides under the website hosting directory, you can import from the root and include both ASP code and web pages at the same time.
It is necessary to launch the client first, as the ASP .NET service process might not already be running; load the client using your browser - this ensures that the web server is running.
In the debug setup you would then select the 'Attach' radio button. When this choice is selected, the debugger will prompt you each time for the process to debug.
Click on the Debug window to start the debugger; the 'Attach To Process' dialog displays.
The name of the process varies across Microsoft operating systems, as explained in the ASP .NET SDK; for example, under Windows Vista the name of the IIS process is w3wp.exe.
On Windows XP, the name of the process resembles aspnet_wp.exe, although the name could reflect the version of the .NET framework that it is supporting.
There can be multiple ASP.NET processes running under XP; you must ensure that you attach to the correct version, which would be the one hosting the .NET framework version that your application runs on; check the web.config file for your web service to verify the version of .NET framework it is tied to.
The Debug window should be enabled and any breakpoints should be red, indicating they have been bound.
You can set breakpoints at any time in the web server code. You can also set breakpoints in the ASP web page(s) if you imported them.
Notes
Some breakpoints might not have bound successfully, but if none at all are bound (indicated by being dark red with question marks) something has gone out of synchrony; try rebuilding and re-importing source code
Learn more
