Finally, protocol handler...

According to Xiong's instructions and arrangement, the startkit of search contains the ifilter and protocol handler parts. Different from general SharePoint development, the two search extensions are deeply embedded in the underlying layer and need to be directly written using C ++ com ...... But I don't know how to use com ...... But at least you can check the code and change it. In fact, both ifilter and protocol handler are not new things in Sharepoint. As early as Windows desktop search, these two things (especially ifilter) exist ).

Ifilter is relatively smooth, and there are a lot of online materials. Although there is no sample on the Internet, you can find several examples from the Windows SDK, which is simple and complex. As a result, I studied MP3 format and wrote an ifilter for MP3. If you have the opportunity, introduce ifilter in detail.

Protocol handler is troublesome. The complexity is not comparable to ifilter (in fact, protocol handler contains a special ifilter). There is very little information on the Internet, let alone the sample code. I searched Google and various blogs and found only one thing written in C # (from John kozell). However, this is just a framework with no substantive content. I tried to write an example based on this framework, but I couldn't run successfully on moss and killed the moss search ...... So I had to wait.

(In other words, there is actually a protocol handler example in the sharepoint2001 SDK, But This SDK cannot be found to download ......)

Finally, a few days ago, I waited for the release of SDK 2007, which included an example of protocol handler, and pulled the code again, which is not complex, you can only search shared folders in another way. But not to mention this sample 文 (the readme.txt is not counted). When I try to compile it, it cannot be compiled ...... After a few days, I finally got it done last night. Here is the content.

The main reason for this sample compilation failure is that a resource file sampleprotocolhandler. RC is missing (for details, see Readme ). In fact, if you change to a person who has some knowledge about com and ATL, it is estimated that such a thing should be easy. The key is that I won't use com ......

I have put this file on OTEC. After decompression, please change the extension ...... Address: file missing from protocol handler Sample In SDK 1.2

When using this RC, you need to change the resource language in the project to Chinese (0x804). Of course, you can change the RC language settings.

Several key issues:

1. Because I compile code on the local machine and put it on the VM for execution, but vc8 is not installed on the VM (that is, C ++ corresponding to vs2005), because in vc8, the compilation result is embedded in the manifest list (this is done to prevent DLL hell, And a winsxs [side by side] similar to GAC is designed from XP). therefore, to run the vc8 program or use its DLL in an environment without vc8, you must first put the corresponding items in winsxs. The method is very simple. On the machine with vc8 installed, there is SDK \ V2.0 \ bootstrapper \ packages in the vs directory, and the required DLL will be thrown into winsxs.

Generally, the 2nd Region is registered using regsvr32.exe XXXXX. dll. In fact, the dllserverregister method is called. In the sample of the SDK, the registry information is written in the RGS file. RC is referenced, and then compiled. res, which is linked to the DLL. The RC file is missing, so this registration information is not written in, resulting in regsvr32 registration failure, error code 0x80070715 (no resources ). After the RC is added, 0x80070716 occurs, and the registration information is not found in the resource. At a glance, it is found that two quotation marks are added ....... Then compile and register again. 0x80029c4a occurs, and The TLB file is not found. Originally, we registered atl com with TLB ...... Copy the TLB and register it successfully.

In fact, the so-called registration here is nothing more than filling in some content in the registry, if you have patience, you can also fill in the line by hand ...... At the beginning, I entered it by hand ......

3. In Moss, the new protocol handler needs to create a new content source for running, but in the management center, there is no out-of-box interface to add custom content source types. Fortunately, there is another example in the SDK to add custom content sources.

Put:

(Sample for crawling logs: // Protocol)

(Search results. We can see that in addition to the sample protocol, we also found MP3, thanks to the ifilter of the previously written MP3)

TIPS:

Ifilter: ifilter is a plug-in that searches for files of this type based on the corresponding file type, CLSID, or progid. Moss provides some common ifilter, such as office documents, txt, HTML, and XML. You can search for these documents in full text. Third-party ifilter mainly includes PDF and AutoCAD. In fact, ifilter technology has been used in Windows desktop search. When searching "my computer", there will be a search condition for what the file content contains, the same ifilter is used to retrieve files.

Protocol handler: During a crawling search in Moss, different types of crawling are used, HTTP, Sharepoint, exchange public folder, shared folder, and other types of protocols are supported by default. After Moss search is installed by default, the following protocols are supported: BDC, bdc2, file, HTTP, https, Rb, RBS, SPS, sps3, sps3s, spsimport, SPSS, STS, sts2, sts2s, sts3, and sts3s, as you can see, many of them are network crawling protocols of SharePoint. Different protocols use different protocol handler for network crawling.