Step 1: Before beginning the debugging process, it is necessary
to load the debugging symbols associated with the component into IIS.
This can be accomplished by simply viewing a page in a browser which contains
server-side script that creates an instance of the component. Note that
the page must run out-of-process from IIS so that it’s accessible to the
Visual Basic debugger. To make sure of this, start up the Microsoft Management
Console for IIS and, in the tree view in the left pane, right-click on
the name of the directory in which the page is located. On the menu that
appears, select Properties.
In order for the page to run out-of-process from IIS, the directory in which it’s located must be an application starting point. To determine whether or not this is the case, look at the tree view in MMC. Icons for the directories which are application starting points are depicted as open boxes, whereas those directories which are not application starting points are represented by the standard folder icon. If the page’s directory is not an application starting point, click the Create button on the property page. You can give the new application a name after creating it, although this is not actually necessary.
Once you’ve ensured that the directory is capable of running the page out-of-process, make sure that the check-box to the left side of Run in separate memory space is checked (in the above screenshot this checkbox is disabled as we have not yet created the Application starting point.) Finally, click OK to close the property page, and, unless you have a burning need to keep it running, close MMC.
Alternately, you could create a simple Visual Basic client to call the server component, which is equally effective, with the caveat that it requires additional time initially to write the code for the client, and will not support the use of any of the built-in ASP objects, if you have need of these.
Step 2: Once the debugging symbols are loaded, or the test client
is written, you can set breakpoints at appropriate spots in your code
by left clicking inside the gray margin alongside a line, as is shown
in the image below. The same result can be produced by placing the cursor
on a line of code, and then either selecting Toggle Breakpoint
from the Debug menu, or hitting F9. As the name of
the option under the Debug menu implies, all three of these
methods will also remove a breakpoint.
Step 3: In keeping with the spirit of Visual Basic, the Start,
Break, and End commands are marked with the
recognizable tape-recorder symbology, and can be found on either the toolbar
or the Run menu. To actually start the Visual Basic debugger,
click the Start option at one of these locations.
Step 4: To step into your code, reload the page that calls
your component or start your test client. The debugger will halt execution
at the first breakpoint that it reaches. You can now examine your code
by utilizing the various commands and windows available in the Visual Basic debugger.
These are, briefly, as follows:
Step Into - steps into a procedure that is called from the current line
Step Over - steps over the current line, placing the cursor on the next line of code
Step Out - steps out of the current procedure
Run To Cursor - continues execution of the program until the line on which the cursor currently rests is reached
Break - halts the execution of the program. In essence, when a breakpoint is reached, the result is equivalent to an execution of Break
End - End stops the debugger, halting the debugging process.
Watch - the Watch window in the debugger allows for viewing of the
current value of a variable or expression. A watch can be initiated
with the Add Watch command, or by copying the expression
or variable and pasting it into the Watch window
Locals - a list of the data members that are local to the current
procedure, and their values.
Immediate - any expression entered into the Immediate window is
immediately evaluated, and any function call is immediately executed.
As is often the case when the use of a debugger is needed, you’ll want to alter or correct your code, and subsequently recompile it. Note that when an instance of your component is created by a server-side script, the library associated with it is attached to the web process, and you’ll be disallowed from writing over it with a recompilation. You can rectify the situation by detaching your component from the web process in one of two ways. The first is to open up the property sheet in MMC for the directory in which the server-side script is located, and click the Unload button. The second, more drastic measure, is to select Settings on the Start menu, open the Control Panel, open the Services window, select "IIS Admin Service", and click Stop. You’ll eventually want to restart the web process, a feat that can be accomplished by selecting "World Wide Web Publishing Service" in the Services window and clicking Start.
If your component is also registered with the Microsoft Transaction Server (MTS), you will need to detach your DLL from this process by right-clicking on your package in the MTS explorer and selecting Shut Down.
Note that if you have your test ASP page open in an Editor such as Microsoft Visual Interdev, or if you have a test client open in Visual Basic, this application may also have a lock on your DLL. To get Interdev to release the lock, you must exit out of Interdev. To get Visual Basic to detach from the DLL you can simply select Remove Project from the File menu. Having performed these steps, you will then be able to recompile your ActiveX DLL project.
Finally, if your component is registered with MTS, you will need to inform MTS that the DLL has changed. To do this, right-click on My Computer in the Transaction Server Explorer and select the Refresh All Components option. Alternatively, you can run mtxrereg from any command prompt, or by selecting Run from the Windows NT Start menu, entering mtxrereg and then clicking the OK button.