Changes in COM+ Services in IIS 6.0

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.

For code examples that configure IIS to use the new COM+ services, see Configuring COM+ Services in IIS.

The following new COM+ services are available on IIS 6.0:

• 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.

Caution

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.

• Side-by-side Assemblies

  Side-by-side (SxS) assemblies allow ASP applications to specify which version of a SxS-supported system DLL to use, such as MSVCRT, MSXML, COMCTL, GDIPLUS, and so on. For example, if your ASP application relies on MSVCRT version 2.0, you can ensure that your application still uses MSVCRT version 2.0 even after service packs are applied to the server. Any new version of MSVCRT is still installed on the computer, but version 2.0 remains and is used by your application. SxS-supported DLLs are stored in %WINDIR%\WinSxS.

  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>
  

Important Note:

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 MSVCRT, version 2.5 and application App2 uses MSVCRT, 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 MSVCRT loaded, and the other application is forced to use it until the applications are unloaded.

• COM+ Partitions

  COM+ Partitions can be used to isolate Web applications into their own COM+ partitions. This is useful to prevent one Web application from accessing the private COM+ applications, configuration information, and data of another Web application. COM+ partitions can hold different versions of your own custom COM components. For example, if you host Web sites for two competing companies that both use COM+ in their Web applications, you can use COM+ partitions to ensure that one company's Web application cannot access the COM+ components in the other company's Web applications. If one of those companies asks you to change certain features in a COM+ application that they both use, you can isolate the new version of that COM+ application in the partition that is linked to their Web application.

Important Note:

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.

• Tracker

  COM+ tracker allows administrators or developers to debug ASP applications. For example, if a Web application is causing problems on your server, you can enable COM+ tracker to determine when ASP pages are being loaded, when COM components are loaded, and when threads leave a page. After you have debugged your application, you can disable COM+ tracker to return your application to normal performance speed.

• Transactions

  Transaction support in ASP pages has been available since IIS version 4.0. However, IIS has changed its internal implementation of transactions to take advantage of COM+ services. IIS no longer creates a COM component to house a transaction but accesses the COM+ transaction service directly, thus greatly improving the speed of transaction processing. As always, transactions can only be configured at the page level using the @TRANSACTION directive and the events of the ASP built-in object called ObjectContext.