In addition to internal performance enhancements and optimizations, this version of Active Server Pages (ASP) has the following new features:
| • | Better International and UTF-8 Support | ||||||||||
| • | Improved POST Support | ||||||||||
| • | ASP Hang Detection | ||||||||||
| • | Caching of Popular Files | ||||||||||
| • | UNC Enhancements | ||||||||||
| • | COM+ Services in ASP
| ||||||||||
| • | New Metabase Properties for ASP | ||||||||||
| • | ASP Debugging |
UTF-8 support has been expanded to all ASP built-in object properties and methods. The last version of ASP supported UTF-8 only for Response.Write.
ASP can now read chunked-encoded POST data from a client.
When an IIS Web site is busy there may be instances when the maximum number of ASP threads has been spawned and some of the ASP threads are hung, resulting in degraded performance. HSE_REQ_REPORT_UNHEALTHY, and the World Wide Web Publishing Service (WWW service) will recycle the worker process hosting ASP.dll and make an entry in the event log.
Note
Threads are considered hung if they do not respond to a timeout.
ASP now caches some of the most-recently used files on disk, in addition to keeping a memory cache. The default location of the disk cache is %systemroot%\System32\inetsrv\ASP Compiled Templates. You can change the location of the disk cache by setting the AspDiskTemplateCacheDirectory Metabase Property.
ASP can now handle UNC paths in ASP scripts.
If you wanted to use COM+ services from an ASP application in previous versions of IIS, you had to create a COM component that would call the methods of those services. Now, you can configure your ASP application to use the following COM+ services without having to create a COM component:
| • | Apartment Model Selection: ASP is now capable of running all of its threads in a multi-threaded apartment (MTA). If your COM components are primarily free-threaded or both-threaded, running the ASP threads as MTA can improve performance significantly. To enable an ASP application to run in an MTA, you can use the metabase setting, AspExecuteInMTA Metabase Property, at the application level. This means that you can have one application running on ASP MTA threads and a second application running on ASP STA (single-threaded apartment) threads. The default for ASP threads continues to be STA. Important When you switch an ASP application from running in STA to MTA (or from MTA to STA), the impersonation token becomes obsolete. This can cause the application to run with no impersonation, effectively letting it run with the identity of the process which might allow access to other resources. If you must switch threading models, disable the application and unload it before you make the change. The following example sets the Default Web Site application (W3SVC/1/ROOT) to execute in MTA: On Error Resume Next
set providerObj = GetObject("winmgmts://MyMachine/root/MicrosoftIISv2")
' Get a reference to the ASP application called Default Web Site
set IIsWebVirtualDirSettingObj = providerObj.get("IIsWebVirtualDirSetting='W3SVC/1/ROOT'")
WScript.Echo "Before: AspExecuteInMTA = " & IIsWebVirtualDirSettingObj.AspExecuteInMTA
' Set the ASP application to execute in MTA
IIsWebVirtualDirSettingObj.AspExecuteInMTA = 1
IIsWebVirtualDirSettingObj.Put_()
WScript.Echo "After: AspExecuteInMTA = " & IIsWebVirtualDirSettingObj.AspExecuteInMTA
|
| • | Side-by-side Assemblies: Side-by-side (SxS) assemblies allow ASP applications to specify which version of a system DLL or classic COM component to use, such as WinHTTP 5.1, Shell Common Controls version 6.0 (Comctl32.dll), GDI Plus version 1.0 (GDIplus.dll), and Visual C++ Run-time Libraries version 6.0. For example, if your ASP application relies on MSXML version 2.0, you can ensure that your application still uses MSXML version 2.0 even after service packs are applied to the server. Any new version of MSXML is still installed on the computer, but version 2.0 remains and is used by your application. Configuring SxS assemblies requires that you know the path to the DLL, and that the COM+ manifest file exists in every virtual directory that needs to use the DLL. The COM+ manifest is an XML file that has information about where a DLL is installed. IIS does not verify that the manifest exists. A manifest looks like the following file excerpt: <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity publicKeyToken="75e377300ab7b886" type="win32" name="Test4Dir" version="1.0.0.0" processorArchitecture="x86"/>
<file name="DirComp.dll" hash="35ca6f27b11ed948ac6e50b75566355f0991d5d9" hashalg="SHA1">
<comClass clsid="{6C6CC20E-0F85-49C0-A14D-D09102BD7CDC}" progid="DirComp.PathInfo" threadingModel="apartment"/>
<typelib tlbid="{AA56D6B8-9ADB-415D-9E10-16DD68447319}" version="1.0" helpdir=""/>
</file>
</assembly>
You can enable side-by-side assemblies on the IIS side programmatically or by using IIS Manager. |
1. | In IIS Manager, right-click a Web site or virtual directory and click Properties. |
2. | Click the Virtual Directory tab, and click Configuration. |
3. | If the configuration button is not available, it is because you have not created an application for this virtual directory. Click Create to create an application. |
4. | In the Application Configuration dialog box, click the Options tab. |
5. | Select the Enable Side by Side assemblies check box. |
6. | In the Manifest file name box, type the name of the COM+ manifest file. |
7. | Click OK twice. |
Important
Only one version of a system DLL can be used in any application pool, even though this feature is configurable at the application level. For example, if application App1 uses MDAC, version 2.5 and application App2 uses MDAC, version 2.4, then App1 and App2 should not be in the same application pool. If they are, the application that is loaded first has its version of MDAC loaded, and the other application is forced to use it until the applications are unloaded.
Important
Only one version of a COM+ component can be used in any application pool, even though this feature is configurable at the application level. For example, if application App1 uses version 1.0 of a custom COM+ application called Shop.dll, and application App2 uses version 2.0 of Shop.dll, then App1 and App2 should not be in the same application pool. If they are, the application that is loaded first has its version of Shop.dll loaded, and the other application is forced to use it until the applications are unloaded.
The following metabase settings have been added for this release of ASP.
| Metabase Property Name | Purpose |
Enables features like COM+ side-by-side assembly (formerly known as Fusion), partitioning, and so on. | |
Specifies the location of the ASP disk cache. | |
Enables ASP threads to execute in a multi-threaded apartment. | |
Sends the ASP session cookie to a browser securely. | |
Specifies the ASP Disk cache maximum. | |
Specifies the COM+ partition to use for the application. | |
Enables ASP to run the global.asa Application_OnEnd and Session_OnEnd events anonymously. | |
Specifies the limit of the buffer size. | |
Specifies the maximum number of bytes allowed in the entity body of an ASP request. | |
Allows ASP applications to specify which version of a system DLL or classic COM component to use. | |
Because the worker process, W3wp.exe, runs as the Network Service account in IIS 6.0 worker process isolation mode, you must configure Launch and Access permissions to enable ASP debugging for Script Debugger and Visual InterDev. For more information, see Enabling ASP Debugging.