[This documentation is preliminary and is subject to change.]

Installing protocol handlers involves copying the DLLs to an appropriate location in the Program Files directory and registering them. The installation application can also add a search root and scope rules to define a default crawl scope for the data store, and stop and restart the Windows Search service.

This topic is organized as follows:

• Installation Guidelines
• Registering Protocol Handlers
• Registering Your Protocol Handler for Shell Parsing Support
• Registering Search Connectors in Windows 7
• Registering Display Name and Icon Properties by Third Party Protocols in Windows 7
• Registering DocumentType Properties in Windows Vista
• Related Topics

Installation Guidelines

Protocol handlers should implement self-registration for installation and should follow these guidelines:

• The installer must use either EXE or MSI installer.
• Release notes must be provided.
• An Add/Remove Programs entry must be created for each add-in installed.
• The installer must take over all registry settings for the particular file type or store that the current add-in understands.
• If a previous add-in is being overwritten, the installer should notify the user.
• If a newer add-in has overwritten the previous add-in, it should be possible to restore the previous add-in's functionality and make it the default add-in for that file type again.
• The installer should define a default crawl scope for the Indexer by adding a search root and scope rules using the Crawl Scope Manager.
• The installer should initiate re-indexing in the same manner as shown in the ReIndex Code Sample included in the Windows Search SDK Samples.

Registering Protocol Handlers

1. Register the version independent ProgID with the following keys and values:

   HKEY_CLASSES_ROOT\<Version independent progID>
        (Default) = <protocol handler's class description>
   HKEY_CLASSES_ROOT\<Version independent progID>\CLSID
        (Default) = {<protocol handler's CLSID>}

2. Register the version dependent ProgID with the following keys and values:

   HKEY_CLASSES_ROOT\<version dependent progID>
        (Default) = <protocol handler class description>
   HKEY_CLASSES_ROOT\<version dependent progID>\CLSID
        (Default) = {<protocol handler's CLSID>}

3. Register the protocol handler's CLSID with the following keys and values:

   HKEY_CLASSES_ROOT\CLSID\{<protocol handler's CLSID>}
        (Default) = <protocol handler class description>
   HKEY_CLASSES_ROOT\CLSID\{<protocol handler's CLSID>}\InprocServer32
        (Default) = <DLL install path>
        Threading Model = <your threading model>

4. Register the protocol and the protocol handler with Windows Search. In the following example, <Protocol> is the name of the protocol itself (MAPI, file, CSC, and so forth).

   HKEY_LOCAL_MACHINE\Software\Microsoft\Windows Search\ProtocolHandlers
        Protocol Name = <version dependent progID>

Registering Your Protocol Handler for Shell Parsing Support

For search results to bind the URLs returned from the query to the data source object, you must register your protocol for shell parsing support. For more information about creating a Shell data store, see Implementing the Basic Folder Object Interfaces.

The entry resembles the following example:

Registering Search Connectors in Windows 7

In Windows 7 and later, search connector files (*.searchConnector-ms) allow users to send search queries to remote Web services that support Windows Federated Search. They are also used to search local index scopes created by protocol handlers.

Registry keys define how the search connector is created, and trigger processing. Processing refers to a search root. When a search root is unprocessed, this feature must still perform work for the particular protocol handler and associated search root. After this work has been completed, the search root is marked as a processed root by creating a new registry key for it under HKCU\Software\Microsoft\Windows Search\ProcessedSearchRoots. After this registry key is created, this feature does not process the search root again.

The entry resembles the following example:

Registering Display Name and Icon Properties by Third Party Protocols in Windows 7

In Windows 7 and later, it is no longer necessary for third-party protocols to implement the IShellFolder interface for third-party indexing options to appear. Third-party protocols can instead register a display name and icon to appear in the indexing options of the Control Panel applet.

The entry resembles the following example:

Registering DocumentType Properties in Windows Vista

In Windows Vista you need to make additional registry entries for each DocumentType property that your new data store supports.

The entry looks like the following example:

The following example consists of registry entries for a Lotus Notes protocol handler to associate specific Notes items with the Mail, Meeting, and Document DocumentType properties, respectively:

Related Topics

• Using the Crawl Scope Manager
• Windows Search SDK Samples
• Debugging Protocol Handlers