SCRIPTING: Troubleshooting IIS 4.0 and Visual InterDev 6.0 by Ken Spencer Published by 29th StreetPress Dec.98; $24.95US; 1-58304-029-3 148 pages Chapter 2 Using Active Server Pages (ASP) and HTML

INTRODUCTION AND TABLE OF CONTENTS Page 1: APPLICATION AND SESSION VARIABLES Page 2: USING THE VISUAL INTERDEV 6.0 SCRIPT DEBUGGER Page 3: SCRIPTING

ASP scripting lets you develop applications that run on IIS 4.0.

Problem: You can't use response.buffer.
You can experience problems in your application when you use response.buffer = true in your ASP application, and it does not work.

Solution: To use buffering, you must enable it in the IIS 4. 0 MMC.
To enable buffering of HTML output,

1. Start the IIS 4.0 MMC.
2. Select the application you wish to change and display its Property pages.
3. Click Configuration in the Application Settings section.
4. Click the App Options tab.
5. Check the Enable buffering option.
6. Apply the changes.

Problem: Users are unable to use parts of applications with session variables due to unsupported or disabled cookies.
HTML supports client-side cookies to store information locally on a user's system. The cookies can be stored in RAM while a user is using the browser, or they can be stored in the file system for persistent storage.

IIS 4.0 and ASP use cookies to identify users within an application session by sending an ASPSESSIONID cookie to the user's browser. IIS automatically creates the ASPSESSIONID cookie for a user's session when the user first accesses a file processed by the Asp.dll. (The first access to a page processed by Asp.dll causes IIS to load and execute the global.asa, at which point the cookie is created.)

The cookie is sent to the browser without an expiration date. Because there is no expiration date, the browser stores the cookie in its memory. Each time the user accesses another page in the application, IIS requests the SESSIONID cookie and checks it against the open sessions on the server. If IIS finds a match, it knows the user has a current session and the user can interact with session variables and continue to work in the application.

If the user's browser does not support cookies or the user has disabled cookies, then the user cannot use any part of the application that uses session variables.

Solution: Use the Cookie Munger utility included in the Internet Information Server Resource Kit to add support for browsers that do not support cookies.

Cookie Munger is an ISAPI filter that filters all output from your server and automatically filters out the ASPSESSIONID cookies to prevent warning messages in browsers that do not support cookies. It also munges local URLs in each page by adding the cookie as a named querystring variable to the URL.

A different approach would be to minimize the use of cookies by using querystrings and other techniques to pass information with your application.

Problem: Script will not execute.
ASP pages are script files that must be executed by the Asp.dll.

Solution: For IIS 4.0 to let script files execute, the directory must be marked as either Execute (including script) or Script, as shown in Figure 2.6

Problem 1: By default, all IIS 4.0 applications run in the same IIS process namespace and can negatively affect each other.
If all the applications use the default setting and run in the IIS namespace, the applications can make maximum use of the server's resources and perform at the maximum possible level.

However, there is a downside. When you execute an application in the IIS namespace, that application can affect other applications in the namespace. Figure 2.7 shows the Windows NT Task Manager Processes tab while an ASP application is running. This simple application uses the Visual InterDev 6.0 Data Environment to pull information from a SQL Server database and send it to the browser in an HTML stream.

All the applications and sites that are on a server will run in the Inetinfo.exe process. (You can review this load by looking at the Inetinfo.exe process via Task Manager or Performance Monitor.) You can see that a process named Inetinfo.exe is using the CPU (note the value of 54 in the CPU column).

If all applications run in the IIS 4.0 namespace, every application can impact other applications in that namespace -- including the Inetinfo.exe process itself. If an application crashes, it can bring down other applications in the namespace, and can cause the Inetinfo.exe process to stop, which stops all Web applications and sites on the server.

Problem 2: When applications run in the IIS namespace, COM components running in an application cannot be replaced unless you stop the IIS 4.0 process.
Stopping the IIS 4.0 server, of course, stops all Web applications and sites on the server.

IIS 4.0 uses MTS to manage IIS 4.0 in-process and isolated applications. In Task Manager, you can see this by watching the instances of Mtx.exe that are created automatically. This is the MTS runtime that executes the various packages.

Figure 2.8 shows the MTS Explorer with the various IIS packages visible. The IIS 4.0 In-Process Applications package contains every application you create on a server.

IIS 4.0 uses the Web Application Manager (WAM) component (WAM.dll) to manage each application. Each application has its own instance of WAM, regardless of whether the application is an in-process or an isolated application. If you open the IIS 4.0 In-Process Applications package, you will see all the applications and the WAM defined for each one, as Figure 2.9 shows. Notice the IISWAM prefix for each application. If you display the properties for any of these entries, you will see that they use WAM.dll.

Solution to 1 and 2: You can configure applications to execute in isolated mode.
When you configure an application to execute in isolated mode, the WAM handles the changes to the application settings by using the IISADMIN objects. When you change the isolated setting, the WAM automatically creates an MTS package for the application and configures it. You can see this in the MTS Explorer view shown in Figure 2.10 (page 32).

Figure 2.10 shows the Components folder for the application named Project2. This folder was created automatically when I changed the application to isolated mode. When I applied this change, the WAM created the package for me and configured it.

What effect does using the isolated mode have on an application? You can see by using Task Manager, Performance Monitor, and other tools to watch what happens (Figure 2.11 on page 33). When applications run in isolation mode, they run in a process separate from IIS. This results in cross-process communications between processes using a technique called marshaling, which is very slow. Therefore, isolated applications run many times slower than they would in the IIS process application switches to isolated mode. The application will continue to run in isolated mode until you turn off the debugging setting.)

To set an application to isolated mode,

1. Start the MMC.
2. Select the application you wish to change and display its Property pages (look back at Figure 2.6).
3. Check the Run in separate memory space (isolated process) box.
4. Apply the changes.

One benefit of running an application in isolated mode is that it can be stopped at any time. You stop the application by using the ISM to unload. Once an application is unloaded, you can replace COM components that are used in the application, replace ISAPI DLLs that are used only by that application, and perform other maintenance on it. A stopped application automatically restarts when the next user requests page from the application.

To stop/unload an application in isolated mode,

1. Start the MMC.
2. Select the Application you wish to change and display its Property pages (look back at Figure 2.6).
3. Check the Unload option button.

If the Unload option button is dimmed, the application is not set to execute in isolated mode, or you opened the property pages for a directory that is not the application's starting point.

Problem: You want faster image rendering in the browser.

Solution: Adding height and width attributes to image links results in faster displays in the browser. The sizing information lets the browser determine the screen space requirements for the image and render it faster.

Problem: You receive HTTP Error 404.
The HTTP 404 error indicates that IIS cannot find the specified link. This error usually results from a referenced page that has been renamed or a link in the referencing page that has been edited incorrectly.

Solution: FrontPage, IIS 4.0, and Visual InterDev all contain tools, such as Link View and Site Server Express, for resolving broken links.

Problem: You have difficulties using CSS with both Netscape and Intemet Explorer (IE) browsers.
Netscape Navigator and Communicator versions 4.0 through 4.03 implement cascading style sheets (CSS) differently from the way IE implements them. Navigator interprets relative URLs as relative to the document rather than relative to the linked CSS file.

Solution: You can work around the difference in CSS implementations in the following ways:

• Copy but do not move all of the images from the directory of the theme that you are using to the directory that contains the document that references the CSS file.

or

or

• Use the Browser Capabilities component to automatically detect which browser is looking at a page and reset the stylesheet link information to the correct file.

To find other differences in using CSS with Netscape and IE browsers, explore the CSS implementations on both the Microsoft and Netscape Web sites.

Problem: Design-time controls do not show up in Visual InterDev 6.0 Quick View.
Quick View does not execute any server-side code, code that the design-time controls depend upon. As a result, when you use Quick View, you see only the static HTML in your page and nothing else.

Solution: You must use View in Browser to execute server-side code and view design-time controls in your page.

Problem: IIS 4.0 does not return custom error messages.
When errors occur in an ASP page in the application and IIS 4.0 does not return the custom error messages that you specified, it is because you did not set the Check That File Exists setting for the custom error.

Solution: Set Check That File Exists for custom errors.
To set Check That File Exists to return custom error messages,

1. Start Internet Server Manager.
2. Right-click the Web site and click Properties.
3. Click the Home Directory tab.
4. Click Configuration.
5. Highlight the extension that fails to return the custom error message.
6. Click Edit.
7. Check the Check That File Exists checkbox.
8. Click OK
9. Click Apply.

This process changes the settings for that extension.

For more information, see Microsoft Knowledge Base article Q176919.

INTRODUCTION AND TABLE OF CONTENTS Page 1: APPLICATION AND SESSION VARIABLES Page 2: USING THE VISUAL INTERDEV 6.0 SCRIPT DEBUGGER Page 3: SCRIPTING

Copyright © 1999 Ken Spencer