Programming Guidelines for Event Sinks

This section outlines guidelines for implementing an event sink.

• For optimal performance, create an in-process Component Object Model (COM) class that supports execution in a multi-threaded apartment (MTA). The event dispatcher threads execute from within the Microsoft® Internet Information Services (IIS) MTA. If your sink supports the single-threaded apartment (STA) only (and the default for Visual Basic), then all interfaces will be marshalled across the MTA apartment and STA apartment boundaries.
• Provide an implementation of the IEventIsCacheable interface by your sink. If you implement the IEventIsCacheable interface and the IsCacheable method returns S_OK, the event dispatcher will cache the sink and will use the same object for subsequent events; otherwise, each event will create a new instance of the sink.
• Never install an untested sink on a production server, especially a sink that runs in- process. Exceptions thrown from within these in-process sinks may disable the IIS (inetinfo.exe) process or cause it to stop responding.
• Do not place Microsoft® Collaboration Data Objects (CDO) interface definitions in your sink’s interface definition language (IDL) file (if you use one directly) when working in C or C++. Information about CDO types—including all classes, interfaces, enumerations, and modules—can be found in the supplied headers. If you do place IDL information in your IDL file, and any of these types are referenced from within your library statement, you will re-map various globally unique identifiers (GUIDs) (IIDs most likely) from the CDO dynamic- link library (DLL) to your DLL. This will not cause immediate harm because your DLL contains the necessary type library information required for the universal marshaller to function properly; however, if you subsequently remove the sink from the registry, the CDO libraries will function improperly.