From Mynoteswiki.com

J.D. Meier

April 24, 2000

Contents 1 Summary 2 Part 1 2.1 Introduction 2.2 Debugging ASP Script 2.3 Debugging ASP Script Using the Microsoft Script Debugger 2.4 Debugging ASP Script Using the Visual InterDev Debugger 2.5 Debugging the Global.asa File 3 Part 2 3.1 Debugging Visual Basic Components Using the Visual Basic Debugger 3.2 Debugging Visual Basic Components from Visual InterDev 3.3 Debugging Visual Basic and Visual C++ Components Using the Visual C++ Debugger 3.4 Debugging Visual Basic and Visual C++ Components Using WinDBG 3.5 Conclusion

Summary

The following article originally appeared in the MSDN Online Voices "Servin' It Up" column.

Part 1

Introduction

This article focuses on using debuggers with ASP during development. Using a debugger can be a more effective approach for watching your variables and application flow than sprinkling your code with trace statements. This article provides information for debugging both ASP script and components called by ASP.

Debugging ASP Script

You can debug ASP script using either the Microsoft Script Debugger or Visual InterDev®.

Debugging ASP Script Using the Microsoft Script Debugger

The Microsoft Script Debugger provides the ability to step through both server- and client-side script. It allows you to view and change variable and property values as well as to view and control script flow. If you don't have Visual InterDev on your machine, use the Microsoft Script Debugger. Setting up: 1. Install the Microsoft Script Debugger, which you can download from the Microsoft Script Debugger Download Page. The Microsoft Script Debugger installs to \Program Files\Microsoft Script Debugger. Note that you'll need to reboot after installation. 2. Enable ASP script debugging for your Web application. Using the Internet Services Manage in Internet Information Services (IIS) 5, or the Internet Information Service Microsoft Management Console in IIS 4.0, right-click the ASP application and select Properties. Next, click the Configuration button. (If only the Create button is enabled, click it to register the directory as an ASP application. You will then be able to click the Configuration button.) From the App Debugging tab, ensure that the Enable ASP server-side script debugging option is checked (see Figure 1). Checking this option locks ASP down to one thread, so be sure that you uncheck this option when you are finished debugging (see KB article Q216580 "PRB: Blocking/Serialization When Using InProc Component (DLL) from ASP" ).

Figure 1. Enable ASP Server-side script debugging for the Web application

Using the debugger: You can use the Microsoft Script Debugger to debug your ASP server script in the following ways:

• Run an ASP page in the debugger.
• Respond to syntax or run-time errors (just-in-time debugging).
• Invoke the debugger through keywords in script.

To run your ASP page in the debugger, follow these steps: 1. From Internet Explorer, browse to the ASP page. 2. Open the Microsoft Script Debugger by selecting Script Debugger from the Internet Explorer View menu, and then choose Open. The Microsoft Script Debugger will appear. 3. From the Microsoft Script Debugger, select Running Documents from the debugger's View menu. The Running Documents window will appear (see Figure 2).

Figure 2. The Running Documents window in the Microsoft Script Debugger

4. Open your ASP page by double-clicking it in the Running Documents window. Your page should be listed beneath the Microsoft Active Server Pages node that refers to your Web application. 5. Set a breakpoint in your ASP server-side script either by pressing F9 or by selecting the Debug menu, and then choosing Toggle Breakpoint. 6. Return to Internet Explorer, and refresh your ASP page either by pressing F5 or by selecting Refresh from the View menu. 7. Switch to the Microsoft Script Debugger, and step through your application. Open the Call Stack and Command Window panes either by selecting them from the View menu or by clicking the appropriate toolbar buttons (see Figure 3). The Call Stack pane provides a trail of the script path, while the Command Window allows you to display variable values. To display variable values in Visual Basic® Scripting Edition (VBScript), use the print command "?" (e.g., MyVariable); in JScript®, just enter the variable name.

Figure 3. Debugging with the Microsoft Script Debugger

You can also use the debugger to respond to script errors. If an error occurs in your ASP page and debugging is enabled for your ASP application, the server automatically opens the Microsoft Script Debugger, and displays the error message that triggered the debugger. To invoke the debugger through keywords in script, use the Stop keyword in VBScript or debugger in JavaScript. Add the keywords to your ASP page during design time, and then browse to your ASP page. If debugging is enabled for your ASP application, the debugger will automatically be opened -- and it will break at the line of code where you placed the keyword.

More Information:

On Windows 95/98, you can only use the Script Debugger to debug client-side script, so you can't use it to debug your ASP server-side script.

Debugging ASP Script Using the Visual InterDev Debugger

If you're working in Visual InterDev, you can use its built-in Debugger. The Visual InterDev Debugger can debug both server- and client-side script in ASP pages. It also provides the ability to debug ASP server-side script from a remote machine (remote debugging).

Setting up:

"Microsoft Visual Interdev 6.0 Debugging" thoroughly covers installation and configuration guidelines for Visual InterDev for local and remote debugging, as well as outlines common problems and their resolution. Quick tip: If you don't see Catalog Class listed in DCOMCNFG (Start -> Run -> DCOMCNFG), then you probably don't have the Visual InterDev Server components installed, and you won't be able to debug. You'll need to install the Visual InterDev Server components (again, see "Microsoft Visual Interdev 6.0 Debugging").

Using the debugger:

You can use the Visual InterDev Debugger to debug ASP server-side script in the following ways:

• Run a page from Visual InterDev (automatic debugging).
• Attach the Visual InterDev Debugger to a running process (manual debugging).
• Respond to syntax or run-time errors (just-in-time debugging).
• Invoke the debugger through keywords in script.

When you run the debugger in automatic mode, Visual InterDev automatically performs the following steps for you (note that Visual InterDev automatically restores these settings to their original state when you stop debugging):

1. Enables the Web application's debugging options. 2. Marks the Web application to run in a separate memory space ("out of process"). 3. Creates a COM+ Application in IIS 5 or an MTS package in IIS 4.0 with the identity set to the user that started the debugging session. 4. Launches Internet Explorer and attaches to Internet Explorer's process. To use the automatic debugging feature in Visual InterDev, follow these steps: 1. In Visual InterDev, right-click on the ASP page you will debug in your Project Explorer, and select Set As Start Page (see Figure 4).

Figure 4. Setting a Start Page

2. Set a breakpoint for the debugger by placing the cursor on a line within your ASP script and pressing the F9 key. 3. Press the Start button on the Standard toolbar, or choose Start from the Debug menu. 4. If this is your first time starting the debugger, you'll be prompted for your credentials. Enter your Domain\Username and password. 5. Debug your script. The Visual InterDev Debugger will break on your breakpoint (see Figure 5). Be sure your debug toolbar is available by selecting Toolbars from the View menu, and then choose Debug. Also, add your additional debug windows, such as Call Stack, Immediate, and Watch, by choosing Debug Windows from the View menu, and then selecting the appropriate windows.

Figure 5. Visual InterDev Debugger stopping at a breakpoint

While automatic debugging simplifies the process of setting up your Web application for debugging, you may prefer manual control. There are also cases in which you will need to debug manually, because automatic debugging will not work -- such as when debugging an ASP application running on a port other than 80, or if you are remotely debugging a Windows NT 4.0 Web server from a Windows 2000 client.

To use the debugger manually, see the following articles, which provide step-by-step instructions:

• Q258929 "HOWTO: Debug ASP Applications Manually Against Windows 2000 Web Server"
• Q196378 "HOWTO: Debugging ASP Applications Manually Against Windows NT 4.0 Web Server"

You can also watch a KB video that walks through debugging ASP manually with Visual InterDev. Because you will manually set up the Web application's debugging properties when you debug manually, it is important that you remember to restore your Web application's settings when you are finished debugging. Be sure to uncheck Enable ASP Server-side script debugging; otherwise, your Web application is locked down to a single thread of execution.

More information:

There are several issues to be aware of when using the Visual InterDev Debugger:

• In Windows 95/98, you can't debug ASP server-side script (Q199004 "INFO: Visual InterDev6 ASP Debugging Not Supported in Windows 95/98" ).
• On Windows NT 4.0, with Internet Explorer 5, breakpoints in client-side script in ASP pages are not hit (Q233035 "BUG: Client-side Breakpoints in ASP Pages Not Hit with IE 5 Installed" ). This problem does not occur in Windows 2000.
• Only one user can use remote debugging on the server at a time (Q202040 "PRB: Can't Attach to Application Microsoft Active Server Pages" ).

For a complete outline of the issues associated with debugging from Visual InterDev, see Q244272 "INFO: Visual InterDev 6.0 Debugging Resources."

For more common issues related to remote machine debugging with Visual InterDev, see "FAQ: Remote Machine Debugging."

Debugging the Global.asa File

The process for debugging the Global.asa file is similar to that of other script pages. You can use either the Microsoft Script Debugger or the Visual InterDev Debugger. You can either set breakpoints in the events in the Global.asa or place commands (VBScript's Stop or JScript's debugger) to invoke the debugger in the events in the Global.asa.

Note, however, that in Visual InterDev, you can't set the Global.asa file as a start page; you need to request an ASP page to trigger the Global.asa file to fire. This is because, unlike inline script in ASP pages, the Global.asa contains event-driven procedures. As such, you need to trigger the appropriate event in order to debug the corresponding procedure.

The Global.asa responds to the following events:

• Application_OnStart fires once the first time any ASP page is requested within the Web application.
• Application_OnEnd fires when the Web application is shutting down.
• Session_OnStart fires once when a new user session is established.
• Session_OnEnd fires once either when a user session times out or when script explicitly calls the Session.Abandon method.

Part 2

Debugging Visual Basic Components Using the Visual Basic Debugger

If you're working with Visual Basic components, the Visual Basic Debugger will probably be your tool of choice. Using the Visual Basic Debugger can be effective for debugging Visual Basic components running under ASP, but it has some caveats to note. The following sections address these issues and offer alternatives for debugging your Visual Basic components.

Setting up:

To avoid a few common problems and debug Visual Basic components effectively, configure your development machine up front. The two main things you'll need to do are: 1. Run your Web application in a memory space separate from the main Web service (Inetinfo.exe). 2. In IIS 5, either change the IIS authentication methods for the Web application, or change DCOM settings on your machine.

Running your Web application in a memory space that is separate from Inetinfo.exe allows you to avoid a common problem when working with ASP. When you recompile a component after calling it from ASP, you may get a Permission Denied error (see Figure 6). This is because IIS has cached the object's class factory (see Q166279 "HOWTO: Lifetime of a COM Component Under IIS, ASP, and RDS" ).

Figure 6. Visual Basic returns Permission Denied when you recompile

Running your Web app in a separate memory space allows you to unload it from memory when you need to recompile. While the default isolation of Medium (Pooled) in IIS 5 is in a shared memory space outside of Inetinfo.exe, that won't allow you to unload your Web application. In IIS 5, you need to change your Web application's Application Protection setting to High (see Figure 7). In IIS 4.0, you need to bke sure the option Run in Separate Memory Space (isolated process) is checked. You can access these options by right-clicking the Web application in the Internet Services Manager in IIS 5, or in the Internet Service Manager in IIS 4.0, and choosing Properties.

Figure 7. Setting Application Protection to High (Isolated)

Once your application is running out of process, you can use the Unload button to remove the Web application from memory. The Unload button is in the same dialog box as your Web application's process isolation, but it's available only when your Web application is loaded. For more information on running your Web application out of process, see "Server Reliability through Process Isolation."

In IIS 5, you also need to change either the IIS authentication level for the Web application or the DCOM settings. Otherwise, you will run into the following problem when trying to debug your Visual Basic object within the Visual Basic debugger:

  Server object, ASP 0178 (0x80070005)
  The call to Server.CreateObject failed while checking permissions. Access is denied to this object.
  /debugvb/DebugVb.asp, line 2

The following articles discuss this problem and possible workarounds:

• Q259725 "PRB: Error Occurs When You Debug a COM+ Component Under the Visual Basic IDE with an ASP Client"
• Q255502 "PRB: Server Object Error 'ASP 0178' Running a WebClass in Windows 2000"
• Q244807 "PRB: Object Required Error for ObjectContext Under Windows 2000 in Visual Basic IDE and ASP"

Changing your DCOM settings by following KB article Q259725 "PRB: Error Occurs When You Debug a COM+ Component Under the Visual Basic IDE with an ASP Client." This problem does not occur under IIS 4.0.

Using the debugger:

To use the Visual Basic Debugger to debug your Visual Basic components under ASP, follow these steps: 1. In Visual Basic, set a breakpoint in your component's method that you will call from your ASP page either by pressing F9, or by selecting the Debug menu, and then choosing Toggle Breakpoint. 2. In Visual Basic, either press F5, or select the Run menu, and then choose Start. 3. If this is your first debug session, you may see the Debugging options tab in the Project Properties dialog box (see Figure 8). Use Wait for components to be created, or specify the URL of the ASP page that calls your test component in the Start browser with URL option. If you choose the former, you will need to browse to the ASP page that calls your component. If you choose to specify the URL, the browser will run that page. You can then debug your component.

Figure 8. Project Debugging options

More information:

• If you are debugging a Visual Basic Microsoft Transaction Server (MTS) component under ASP, be sure that you have at least Windows NT Service Pack 4, and that your component is set to something other than 0-NotAnMTSObject (see Q244457 "HOWTO: Debug an MTS Visual Basic Component Running Under ASP" ).
• Note that MTS Debugging is not supported under Windows 95/98.

For further details, read the following:

• Q177182 "HOWTO: Debug a Visual Basic DLL under Active Server Pages"
• Q188919 "HOWOT: Avoid 'Error 91' when Debugging MTS Components with Visual Basic"

Debugging Visual Basic Components from Visual InterDev

Debugging Visual Basic components from Visual InterDev can be helpful when you need to step through your ASP script into your Visual Basic component and back. Debugging Visual Basic components from Visual InterDev is basically putting together what you know about debugging ASP script with Visual InterDev and debugging Visual Basic components with Visual Basic. Note that you aren't literally debugging Visual Basic components from Visual InterDev, but you are actually stepping back and forth between the Visual InterDev Debugger and the Visual Basic Debugger.

Setting up:

You'll need to have Visual InterDev Debugging properly configured. (See "Microsoft Visual InterDev 6.0 Debugging" ). If you're debugging in IIS 5, you'll need to change your DCOM settings according to Q259725 "PRB: Error Occurs When You Debug a COM+ Component Under the Visual Basic IDE with an ASP Client" -- even if you've changed your IIS authentication methods so that you can step into your Visual Basic component. If you don't change your DCOM settings, you'll get a Server.CreateObject error when you try to step from Visual InterDev into your Visual Basic component, and you won't be able to debug (see Figure 9).

Figure 9. Server.CreateObject error when debugging Visual Basic from Visual InterDev

Using the debugger:

If the DLL is already loaded, you will have to restart IIS before you can debug the DLL, or you will not be able to stop on breakpoints.

To debug Visual Basic components from Visual InterDev, follow these steps: 1. In Visual Basic, set a breakpoint in your component's method that you will call from your ASP page either by pressing F9 or by selecting the Debug menu, and then choosing Toggle Breakpoint. 2. In Visual Basic, either press F5, or select the Run menu, and then choose Start. 3. If this is your first debugging session, you may see the Debugging tab in the Project Properties dialog box. Choose Wait for components to be created. 4. In the Visual InterDev Project Explorer, right-click on the ASP page that calls your waiting Visual Basic component, and select Set As Start Page. 5. In Visual InterDev, set a breakpoint for the debugger by setting the cursor on a line within your ASP script and pressing the F9 key. 6. Press the Start button on the Standard toolbar, or choose Start from the Debug menu. 7. Step through your ASP script. When your ASP script calls a method in your Visual Basic component, you can switch to Visual Basic and continue stepping through your code. When your Visual Basic method completes, you can switch back to Visual InterDev and continue to step through your ASP script.

More information:

For an actual sample and walkthrough, see the KB article Q200998 "HOWTO: Debug a Visual Basic DLL from Visual InterDev."

Debugging Visual Basic and Visual C++ Components Using the Visual C++ Debugger

The Visual C++ Debugger provides rich debugging capabilities and is the tool of choice for debugging Visual C++ components. However, you can also use the Visual C++ Debugger to debug your Visual Basic components. This technique may be useful if you are working with both Visual Basic and Visual C++ components under ASP, or if you need to debug Visual Basic components running under a different security context than the interactive user. This section provides steps for debugging both Visual C++ and Visual Basic components using the Visual C++ debugger.

Setting up:

1. Run your Web application in an isolated memory space (see the section on Debugging Visual Basic Components with the Visual Basic Debugger). 2. Create symbols for your component. For a Visual C++ component, you can generate symbols by building a debug version of your DLL. From the Visual C++ Build menu, choose Set Active Configuration and select the Win32 project configuration (see Figure 10). When you build your Visual C++ project, symbols will be generated in the /Debug directory beneath your project.

Figure 10. Setting the Active Project Configuration

For a Visual Basic component, you can generate symbols by changing options on the Compile tab in the Project Properties dialog box. In Visual Basic, select the Project menu, and then choose YourProject Properties. This will bring up the properties for your project. Switch to the Compile tab, and choose Compile to Native Code, No Optimization, and Create Symbolic Debug Info (see Figure 11). When you compile your component, a symbol file (PDB) will be generated.

View Figure 11. Creating Symbols for Visual Basic

Using the debugger:

The Visual C++ Debugger provides the ability to attach to a process to initiate debugging. You can attach to a process from Visual C++, or you can launch the debugger from Task Manager for a particular process. Usually, the trick when working with ASP is determining which process to attach to.

To attach to a process to debug a Visual Basic or Visual C++ component under ASP by using the Visual C++ Debugger, follow these steps:

1. From Internet Explorer, browse to the ASP page that calls your component. This will load the parent Web application. 2. In Visual C++, select Start Debug from the Build menu, and then choose Attach to Process. This brings up the Attach to Process dialog box. In IIS 5, be sure the Show System Processes option is checked (see Figure 12). This will allow you to attach to an instance of dllhost, which hosts your out-of-process Web applications. In IIS 4.0, you may see one or more instances of mtx, which hosts your out-of-process Web applications. If your Attach to Process dialog box is empty, you will need to launch the debugger from Task Manager (see below).

View Figure 12. Show System Processes is enabled

3. Determine the correct Process ID (PID), and attach to it from the Attach to Process dialog box. Click OK. In IIS 5, you can determine the PID of your Web application using the Component Services Manager (see Figure 13). By choosing Status View from the View menu in the Component Services Manager, you can see the PIDs of running applications. Note, however, that the PIDs listed in the Attach to Process dialog box are in HEX. Use Calc.exe (Start -> Run-> Calc) to determine the HEX value for your PID by entering the PID from the Component Services Manager and then switching to HEX.

View Figure 13. Using the Component Services Manager to obtain the PID

In IIS 4.0, there are a few ways to determine the correct PID. A common approach is to bring up TaskMgr and watch the instance of MTX.exe that comes up when you first hit an ASP page in your Web application. When you view instances of MTX in TaskMgr, you will probably see at least one instance already running, because it's hosting your in-process IIS applications. A more reliable way, if you have Windows NT 4.0 Service Pack 4 or later, is to use the Microsoft Script Debugger. The Running Documents window in the Microsoft Script Debugger will contain Web application names and their corresponding PIDs. Another alternative is to use GETPID, which is a utility that comes with the IIS 4.0 Resource Kit , or EMCMD.EXE with the /p option. EMCMD.EXE is included in DBG.EXE when you download WINDBG.

4. After attaching to the correct process, you need to load your component's symbols. In Visual C++, from the Project menu, choose Settings. This brings up the Project Settings dialog box. Switch to the Debug tab, and choose Additional DLLs from the Category drop down. Add your DLL beneath Local Name under Modules (see Figure 14).

View Figure 14. Adding your DLL's source to the debug session

5. In Visual C++, open the source file for your component. You can do this either by choosing Open from the File menu, or by clicking the Open button in the toolbar. If you are debugging a Visual Basic component, choose All Files from the Files of Type option, because you will need to open the appropriate Cls file that contains the Visual Basic source you are debugging.

6. Set a breakpoint in your source file either by pressing F9 or by clicking on the Insert/Remove Breakpoint toolbar button. If you can't set a breakpoint, your .PDB file is probably out of sync with your source file. Rebuilding your component is a common remedy.

7. From your browser, hit refresh. Visual C++ should stop on your breakpoint. You can now use the debugger to step through your code.

Launching the debugger from Task Manager may be necessary -- for example, if your process list is empty (see Q235434 "BUG: 'Attach to Process' List Is Empty." To launch the debugger from Task Manager against a particular process, follow these steps:

1. Using Internet Explorer, browse to the ASP page that calls the method of your component. 2. Bring up Task Manager (Start -> Run -> Taskmgr). 3. Right-click the correct PID (using the techniques previously mentioned), and select Debug (see Figure 15). A warning dialog box may pop up and ask you to confirm that you'd like to attach the debugger. Choose Yes.

View Figure 15. Selecting Debug from Task Manager

4. Follow steps 4-7 from the previous section. Note that when you stop debugging with the Visual C++ Debugger, the original process will be torn down. For out-of-process Web applications that you are debugging -- that means, Dllhost.exe in IIS 5 and MTX.exe in IIS 4 -- you may see the following error message:

  The remote procedure call failed and did not execute.

Simply refresh your ASP page.

More information:

The following KB articles provide additional information:

• Q177182 "HOWTO: Debugging a Visual Basic DLL under Active Server Pages"
• Q183480 "Debug ISAPI and Filter DLL Under IIS 4.0"
• Q98890 "HOWTO: Debugging a Service"
• Q152054 "INFO: Tips for Debugging ISAPI DLLs"

Debugging Visual Basic and Visual C++ Components Using WinDBG

Using WinDBG is similar to using the Visual C++ debugger in that you attach to a process, load your symbols and source, and debug your code. It's lighter in weight than Visual Studio -- and if you don't have Visual Studio on the machine, WinDBG allows you to step through your source.

Setting up:

1. Install WinDBG. You can download it for free from the Platform SDK Windows 2000 Debuggers site. This version of WinDBG works on both Windows NT 4.0 and Windows 2000. 2. Create symbols for your component (follow the steps in the Debugging Visual Basic and Visual C++ Components Using the Visual C++ Debugger section). 3. Place your source and symbols (PDB file in Visual Basic) in the same directory as your component on the target machine. Using the debugger: To use the WinDBG debugger for components under ASP, follow these steps: 1. Using Internet Explorer, browse to the ASP page that calls the method of your component. This will launch an instance of Dllhost.exe (IIS 5) or MTX.exe (IIS 4.0), if your Web application wasn't already running. 2. Determine the correct PID to attach the debugger to (follow the steps under the Debugging Visual Basic and Visual C++ Components Using the Visual C++ Debugger section). In WinDBG, the processes will be listed in HEX, so use CALC.EXE to determine the HEX value of your PID. 3. Open WindDBG. The default location is in the Debugging Tools folder (Start -> Programs -> Debugging Tools) or under \Program Files\Debuggers\bin directory on your file system. 4. In WinDBG, choose Debug, and then select Attach to Process. 5. In the Attach to Process window, select the correct process and click Select (see Figure 16). WinDBG will load the symbols that it can find in its search path.

Figure 16. Attaching to a process in WinDBG

6. From your browser, refresh the ASP page that calls the component you are debugging. It will be hung, because it will be waiting for WinDBG commands. 7. In WinDBG, enter g at the command prompt to resume execution (see Figure 17). Your ASP page will complete. You can find additional WinDBG commands and their purpose in WinDBG's help. View Figure 17. Using the g command in WinDBG to resume execution 8. In WinDBG, open the source file that you are debugging. If you're debugging Visual Basic, be sure to switch the Files of type dropdown box to All Files (*. *) (see Figure 18).

Figure 18. Opening the Visual Basic source file

9. In WinDBG, set a breakpoint in your source file by pressing F9. Your line of source will be highlighted. 10. From your browser, refresh your ASP page. 11. Switch back to WinDBG. Your source code will be highlighted, and you are ready to debug (see Figure 19).

View Figure 19. WinDBG in action

When you stop debugging, you may see the following error message the first time you hit your ASP page:

  The remote procedure call failed and did not execute.

Refresh your ASP page. The error message simply indicated that either Dllhost.exe in IIS 5 or MTX.exe in IIS 4.0 was shut down.

More information:

See the following BugSlayer columns regarding WinDBG:

• BugSlayer December 99
• BugSlayer January 2000

See the following KB articles for more information:

• Q192754 "HOWTO: Debug InProc COM Components Inside IIS Using WINDBG"
• Q99953: "WinDbg Message 'Breakpoint Not Instantiated'"
• Q131007 "How to Use Windows NT Windbg with Visual Basic"

Conclusion

Now you've seen some debuggers and how you can use them under ASP. Maybe you've learned a trick or two along the way. Above all, you have an overview of how to debug both script and components. Learning how to debug effectively under ASP takes time and practice, but the information in this article provides you with a good head start.

J.D. Meier was born and reared on the U.S. East Coast. Since heeding Horace Greeley's advice, he has worked as a Developer Support engineer specializing in server-side components and Windows DNA applications involving MTS and ASP technology.