Believe it or not, there is really nothing special about the process of debugging a Web form. You do things like set breakpoints, step through the code, examine variables, and so forth. Unfortunately, the debugger is not set up out-of-the-box. You need to configure it yourself, which requires two steps:
- Update Web.config
- Update property pages
The first step will already have been done if you copied the Web.config from the first article in this series. If you created your own Web.config or copied it from somewhere else, make sure that the compilation tag has a debug attribute set to true like this:
<compilation debug=”true” />
You should also remember two key things when you make this change. First, the code is case sensitive. You must enter the attribute exactly as shown or debug mode will not be set. Second, be sure that you make this change in the Web.Config file that’s located in the Web application’s root virtual directory.
Want to learn more about codebehinds? Check out the first two articles in our series:
Debug mode is on
With the debug mode now set, ASP.NET runtime will generate debugging symbols for dynamically generated Web page classes. Also, it enables the debugger to attach itself to the Web application so that we can debug with it.
One warning: Enabling debug mode greatly affects the performance of your ASP.NET application. You should disable debug mode before you deploy the application.
Now that you have your Web forms ready for debugging, you need to set up Visual Studio .NET. This is done with the second of the two steps, which is the trickiest part of the process, if you don’t count the actual debugging of the whacked-out Web form. This step involves updating the project property pages or, more specifically, the debug properties.
Let’s walk through the process:
- Right-click on the Web project name in the Solution Explorer (in this case, the Greetings folder).
- Select Properties to open the project’s Property Pages dialog box.
- Select the Debugging folder, as shown in Figure A.
- Set the Command edit box to aspnet_wp.exe. (If the aspnet_wp.exe executable is not on your executables path, you’ll need to provide the complete pathname.)
- Set the Attach edit box to Yes.
- Click OK to save your changes and close the Property Pages dialog box.
|Greetings property pages|
If you were observant, you may have noticed that the HTTP URL is already set correctly to the Web form we built in our previous article. This is because it was entered into the dialog box that opened when you first executed the Web form.
Debug that Web form
Okay, now that we have everything set up, let’s see if we can debug our Web form. First, we need to set up a breakpoint just like we would any other application type. If we don’t set a breakpoint, the Web form will merrily run without stopping.
We’ll place a breakpoint on the first line of the OnLoad() method. Simply click in the border to the left of the line of code in the codebehind you want to stop. Now, to start debugging your Web form, just press the [F5] key or select Start from the Debug main menu. Figure B shows Greetings stopped at a breakpoint.
When you start your debugging session, if you see the message Unable to start debugging on the Web server instead of your Web application, try specifying your machine name instead of “localhost” in the HTTP URL edit box.
Now you are ready to debug your Web form. As you can see in Figure B, you have auto, local, watch, stack, and an assortment of other debugging windows at your disposal. You can step into, over, or to the cursor. Run to the next breakpoint. Basically, anything you can do when debugging a standard Managed C++ application you can do with a Web form codebehind. The reason for this is simple. A codebehind is an assembly just like what you generate when compiling a console or Win form application.
The only thing the debugger can’t do with Managed C++ that it can do with C# or Visual Basic.NET is walk through the ASP.NET Web form’s .aspx file. (You can set a breakpoint in a Web form’s .aspx file, and the debugger will stop, but stepping through it doesn’t work properly.) This is really not much of a loss, since there’s no embedded code to walk through anyway.
Web forms are an excellent development tool, and Managed C++ can be used to develop them just like other .NET languages. Debugging them in Managed C++ is a bit different from the other languages (C# and Visual Basic), but it is possible and not as troublesome as envisioned.