Dot Net Mafia

Group site for developer blogs dealing with (usually) .NET, SharePoint 2013, SharePoint 2010, Office 365, SharePoint Online, and other Microsoft products, as well as some discussion of general programming related concepts.

How to: Use the SharePoint 2013 Search KeywordQuery Class

Over the past few versions of SharePoint, I have provided a number of blog posts on how to query search. Of those, my posts on how to use the KeywordQuery class using KQL are some of the most popular (2010 and 2007). In continuing that tradition, I am proud to present the “How to” post on using the KeywordQuery class in SharePoint 2013. The good news: your old KeywordQuery code should still work. The bad news: the way you did it is marked completely obsolete. I actually had to dig through quite a bit of documentation to find the right API that wasn’t obsolete. One thing that always provided confusion was that there were similar classes named KeywordQuery in both Microsoft.Search.Query and Microsoft.Office.Server.Search.Query. To reduce some of that confusion, the KeywordQuery class in Microsoft.Search.Query is now marked as obsolete. The new updated class is in Microsoft.Office.Search.Query. Microsoft may have killed the word Office from the name of the product in 2010, but it’s alive and well in the API.

Now let’s talk about what we need to execute some queries with our code. The code here today will work well from farm solutions in SharePoint as well as other .NET applications hosted on the same SharePoint server. We’ll be building a console application today. If you want to query remotely using the object model, then you will need to use the Search Client Object Model which I covered previously. Create a new console application, and then you will need to add a few references. These can be found in the 15 hive in the ISAPI folder. Add the following:

Microsoft.Office.Server

Microsoft.Office.Server.Search

Microsoft.SharePoint

Microsoft.SharePoint.Security

The classes we need are in the search assembly but you’ll get lots of errors about dependencies missing if you don’t include the others. We then need the following references. This gives us what we need for search, SharePoint, and for the underlying datatable object that is available after we query.

using System.Data;

using Microsoft.SharePoint;

using Microsoft.Office.Server.Search.Query;

Once we have this, we’re ready to get started. There are many ways to instantiate a KeywordQuery object. For simplicity, I am just going to pass a SPSite object for one of my site collections. You can also pass a SPWeb or you can use the proxy technique like I used in my SharePoint 2010 post. We’ll first, get our SPSite object.

Now, we specify our query using the QueryText field. This is where you can use your custom KQL queries. The documentation team updated the post on this so there are a lot of good tips here. I am just going to search for the word SharePoint.

keywordQuery.QueryText = "SharePoint";

In the past, we would then set the ResultsProvider and ResultTypes that we want, but now we don’t have to. In fact, this whole process takes considerably less code. Instead we use the new SearchExecutorclass that I first mentioned in my Client OM post.

SearchExecutor searchExecutor = newSearchExecutor();

We then use it’s ExecuteQuery method passing it our KeywordQuery class.

Assuming it executes correctly, we can then get our search results. Before, we used to use an indexer using ResultTypes.ReleventResults to get the table of results we need. The indexer has been made obsolete, so now we must use the new Filter method. I figured out what it required from the obsolete descriptor of the indexer. For the first value, it needs a string with a value of TableType and since the previous enum is also obsolete, we now use KnownTableTypes.RelevantResults.

So if you have a lot of search based code, you may need to do some updates at some point. However, I think these are good changes and simplify the process a little bit. In an upcoming post, I’ll cover some of the new things you can do with the KeywordQuery class.

roelBSS
said:

Hi Corey,

Thanks yet again for a great write-up on SharePoint 2013. I am a bit confused however, about the proper class to use in this case. You state two different namespaces in the text, but in the code, you use Microsoft.Office.Server.Search.Query, which is probably the correct one, right?

I have implemented your example, and have a question about the "QueryInfo" object that is filled after you issue a query: The TotalResults property stays 0, even though you have lots of results in the results table. Have you notices this before? Do you know of a workaround or solution to the problem? All other properties of the QueryInfo are being updated after querying, just not TotalResults.... And this is a property you'd really like to know in a search based application ;)

This code doesn't return any results even though i have used SP2013 Query tool to test out my query which has one keyword and it returns 1 result while using code doesn't return results. any idea why would this happen ?

June 30, 2014 12:35 PM

Chil
said:

I am trying to use the following query for a customized keyword search webpart.

Created:{Today-365} and IsDocument:1

Once I use the above query on “Build your Query” at SC level, I got some search results.

But, Once I use String queryText = "Created:{Today-365}"; inside of my keyword query console program. (my keyword search console program works fine with other keyword query)

I got the error” we did not understand your search term”.

Could you explain to me why and any solution?

March 18, 2015 6:52 AM

Sushrut
said:

I am using keyword query to get community sites using querytext as "WebTemplate:Community Path:/Communities/" where communities is the site collection URL.

If I use the same query in content by search web part, I get all the result and which is higher than number I get when I execute query programatically. I am using same account to see the results so it should not be related to permissions. Also I have site collection admin permission.