If you have ever wondered how you can add or remove items via code that you see on the exclude and include content page then here is some sample code to do that.
As you can see in the screen-shot below I’ve added a new rule (called a Site Restriction in SharePoint terms) that includes a main site and its content and excludes a subsite, these sub filters are called SitePaths.
Using code shown at the end of this entry I've added the w2k3-devclient:5003 site rule.
What we need to do is obtain the ISiteRestrictions interface and use its Add method passing it a group name (note this is not the full URL it must be a without the http:// prefix) and true or false indicating whether it is to be included or excluded.
MSSITLB.ISiteRestriction Add ( System.String bstrName , System.Boolean fIncluded )
The Add method returns a ISiteRestriction object which in turn has a Add method returning a ISitePath2 object which allows us to add Site Paths to fine tune the filtering of the content source.
Some methods of the ISitePath2 interface are
string AccountName [ get]
int AuthenticationType [ get]
bool FollowComplexUrls [ get, set ]
bool Included [ get, set ]
bool IncludeSubdirs [ get, set ]
bool SuppressIndex [ get, set ]
Curious at the 2 at the end of ISitePath2? Way back in the old days of COM if you wanted to extend an interface with new methods you couldn’t change the original as that was part of the COM contract of invariance of interfaces, so the developers normally just pegged the next number up on the interface name to create the new one. (Update: whoops this is just been added to .net best practice guidelines 
)
Now the path to actually get a ISiteRestriction interface is a bit torturous mainly because all the functionality for controlling the search engine is done by accessing the SharePoint Portal Search COM libraries via interop and the documentation for these interfaces are completely missing.
Also according to MSFT they are completely unsupported, hmm so the means of controlling your enterprise wide search engine via API’s is unsupported?
This is not good but hopefully completely sorted via a managed interface in v3.
For now to get access to the interfaces we need to add a reference to thses libraries on the COM tab - the SharePoint Portal Search CoClasses Type Library which gives us access to SearchAdminClass and also the Microsoft Search Interface Type Library for the other COM interfaces.
-
We instantiate the SearchAdminClass class which gives use access to the Applications property, now Applications in MS Search terminology comes down to the directory that the indexes are stored in. Different applications will have different directories, it’s a way of separating index content.
-
Each portal site has a specific ApplicationName that we get from the PortalSite object.
-
This then allows us to get a reference to the BuilderServer interface which we can get the list of Catalogs. The default catalogs are the famous Portal_Content and Non_Portal_Content.
-
Then finally within each catalog live the Site Restrictions which define the source of the data to be indexed.
Heres the sample code for a simple console application that lists the Catalogs and all the Site Restrictions and Site Paths within them.
As shown in the screen-shot above it also adds some test rules to the Non_Portal_Content catalog so comment that out of you don't want that to happen.
using System;
using Microsoft.SharePoint.Portal.Topology;
using MSSCTLB;
using MSSITLB;
namespace ShowRestrictions
{
/// <summary>
/// Summary description for Class1.
/// </summary>
class Class1
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main(string[] args)
{
ShowRestrictions();
}
private static void ShowRestrictions()
{
TopologyManager man=new TopologyManager();
PortalSite site=man.PortalSites[new Uri("http://w2k3-devclient:5001")];
MSSCTLB.SearchAdminClass sadmin=new SearchAdminClass();
IApplications applications1 = (IApplications) sadmin.Applications;
IApplication2 application1 = (IApplication2) applications1[site.SearchApplicationName];
IBuildServer2 buildserver= (IBuildServer2)application1.BuildServer;
IBuildCatalogs2 catalogs=(IBuildCatalogs2)buildserver.BuildCatalogs;
foreach(IBuildCatalog3 cat in catalogs)
{
Console.WriteLine("Catalog {0}",cat.Name);
MSSITLB.ISiteRestrictions siterestrictions=(MSSITLB.ISiteRestrictions)cat.Sites;
if (cat.Name=="Non_Portal_Content")
{
MSSITLB.ISiteRestriction NewSearchContent=siterestrictions.Add("w2k3-devclient:5005",true);
NewSearchContent.Paths.Add("http://w2k3-devclient:5005/sites/",true);
NewSearchContent.Paths.Add("http://w2k3-devclient:5005/sites/dontsearchme/*",false);
}
foreach(ISiteRestriction2 restriction in siterestrictions)
{
Console.WriteLine(restriction.Name + "," + restriction.Included);
foreach(MSSITLB.ISitePath2 sitepath in restriction.Paths)
Console.WriteLine("SitePath : {0},{1}",sitepath.Path,sitepath.Included);
}
}
Console.ReadLine();
}
}
}
Now there is a lot more to the Search classes than this, with them you can control all aspects of the search process and I hope to get some time to do more digging.
Colin.