Consume your custom (SharePoint 2013 hosted) WCF Data Service in a SharePoint 2013 App

I think this will be my shortest post ever. To consume your custom (SharePoint 2013 hosted) WCF Data Service in a SharePoint 2013 App you can simply follow the instructions you find here:

Then why is this still worth a post? Simply because I think that it’s very easy to oversee this option and start digging in the wrong direction. In my case I believed that because a SharePoint hosted WCF Data Service is basically available at

hostweburl + '/_vti_bin/your_data_service_folder/your_data_service.svc'

It would be also accessible. But I found that available isn’t the equivalent of accessible. I’m still not sure whether I’m facing a flaw in my SharePoint 2013 environment or whether it really is not possible to go beyond the boundaries of the host web using SP.RequestExecutor or AppContextSite (also see my question here: But using External ContentTypes for Apps I found a quick and easy way to consume my custom (SharePoint 2013 hosted) WCF Data Service afterall.

One remark

To make things work for a WCF Data Service you may need to change the following line in the sample code

"accept": "application/json",


"accept": "application/json; odata=verbose",


Hosting a WCF Data Service in SharePoint (2013)

Hosting a WCF Data Service in SharePoint requires you to make a few important changes or else it will fail.

1. Change the servicehost Factory

If you created your WCF Data Service using VS2012 you will find that the servicehost Factory is set to

System.Data.Services.DataServiceHostFactory, Microsoft.Data.Services, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35

However, for WCF services hosted in SharePoint you can use other Factories that will take the burden of configuring endpoints, bindings and behaviors of your shoulders ( Even though this information applies to SharePoint 2010, it’s still valid for 2013. So I ended up changing my Factory to

Microsoft.SharePoint.Client.Services.MultipleBaseAddressDataServiceHostFactory, Microsoft.SharePoint.Client.ServerRuntime, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c

2. Disable Impersonation

If you can access the service but none of it’s methods because ‘NT AUTHORITYIUSR’ cannot logon, changes are that you need to update the Web.Config so that impersonation is set to false. That way IIS won’t use the IUSR account for impersonation.

<identity impersonate="false">

Additional configurations

3. Add the connection string to the Web.Config (if you’re using Entity Framework)

If you make use of an Entity Framework you need to add the Entity connection string to your web service Web.Config file

4. Deploy Microsoft.Data.Services and dependencies to GAC

I had a couple of “misunderstandings” with NuGet as well as with the way the WCD Data Service packages are updated and deployed to GAC. In my case I ended up including the correct versions in my SharePoint WSP package for GAC deployment. But in reality, this simply should be a prerequisite before the application is deployed. The caveat with having the wrong versions referenced is that you may see errors indicating that the service type was not found. But reality a wrong version of Microsoft.Data.Services was loaded ( instead of

Some final thoughts …

Obviously it doesn’t make much sense in the SharePoint 2013 age to deploy web services to SharePoint’s ISAPI folder. The lower the number of dependencies on the base installation of SharePoint, the easier it is to upgrade to the next version. So of course you should create a remote app. But this would immediately increases the complexity as you need to implement proper authentication (and possibly authorization).



Developing Apps for SharePoint 2013

I’m basically using my blog right now as a public scrapbook. I simply log every issue I run into when I developing my first SharePoint 2013 hosted App.

Issue 1. – JavaScript Error(s) when deploying/testing my first App Part (15th March 2013)

An App Part is basically a very simple yet effective solution to add functionality to the host web (the web hosting the app): It simply is an IFrame that displays a page hosted elsewhere. In my scenario of a SharePoint hosted app this page is hosted in a subsite i.e. in the app web just below the host web. However, IE9 seems to have difficulties handling script loading in an IFrame that is added after the IFrame’s hosting page already completed loading. If I create a simple SharePoint hosted App Project in Visual Studio 2012 and add a Client Web Part (Host Web), press F5 and navigate back to the host web to add the App Part (=Client Web Part) to a (newly created wiki page) in the host web, the solution breaks on the following error:

Error: 'Object' is undefined

It points to jQuery’s statement

// Save a reference to some core methods
toString = Object.prototype.toString,

Later I found that also other global JavaScript objects, i.e. Function and Type were not registered. This error can be “surpressed” in two ways:

1. Make sure that the page isn’t loaded in IE9 Compat View. Also ensure that IE by default doesn’t want to display all intranet sites in Compatibility View by clearing the tick in the box here Tools > Compatibility View Settings > Display Intranet Sites in Compatibility View.

2. However, it’s not always that easy to control IE9’s Compatibility View Settings and hence I added the following JavaScript as the first statement in the document’s head:

<script type="text/javascript">

More info here:

Issue 2. – Each time when debugging from VS2012 (F5’ing) I need to enter my credentials

A quick look with Fiddler showed that credentials aren’t sent (ah well, who would have guessed with the “Enter credentials box” popping up). Since the isolated App domain (*.app.futurama.local in my case) was properly configured in DNS and host file I could solve the problem by adding *.app.futurama.local to IE’s intranet sites.



Configuring my SharePoint 2013 development environment (with only 6 GB)

I know there are a lot of posts out there that will guide you through the setup of a SharePoint 2013 development environment. So does it really needs another one? Well, maybe I searched with my eyes closed or I just have a very exotic idea of what my SharePoint 2013 development environment must look like:

  • Windows Server 2008 R2 with SP1 that is Active Directory Server at the same time
  • SQL Server 2008 R2 with SP1
  • SharePoint 2013 RTM
  • Visual Studio 2012 with Office/SharePoint App Development extensions

Disclaimer: I’m quite sure that with the hacks I promote in what now follows I am far beyond supported terrority … But it works!

I started by creating a Hyper-V virtual machine on my notebook with 8 GB, meaning that I had only 6 GB to spare for my virtual development environment. Without knowing I had digged myself one deep hole! Below I’ll provide a detailed list of all the steps I eventually took to jump over the deep hole (incl. pointers to other websites that turned out to be extremely valuable). However, first I’ll present you with a brief overview of all the problems I initially ran into:

  • AppFabric’s Distributed Cache doesn’t like it when you have less than 10% of physical total memory available and hence will you’ll see many errors like “The Execute method of job definition Microsoft.Office.Server.UserProfiles.LMTRepopulationJob” appear in your event viewer.
  • Most SharePoint Web Services cannot be activated as they require at least 5% of total memory and you’ll find many errors like “WebHost failed to process a request (…) Memory gates checking failed because the free memory (139665408 bytes) is less than 5% of total memory”.
  • To make the Farm Account a local administrator on a server that is Active Directory’s Domain Controller is not as straight forward as you may think.
  • Don’t be smart and use the local administrator’s account as Farm Account because the System Account is not allowed to deploy Apps to SharePoint (and you cannot debug/deploy SharePoint hosted Apps to your local SharePoint if you don’t run Visual Studio 2012 with elevated priviliges i.e. as local administrator: a perfect example of a catch22). I suspect that even though the target Web Application’s Application Pool’s identity differs from the Farm Account, there are still some Web Services running (e.g. the User Profile Service) under the Farm Account and this means that you’ll be using the System Account (= Current Application Pool’s Identity) afterall.
  • The User Profile Synchronization Service requires SQL Server’s full version and it doesn’t seem to fancy named instances either.
  • Processes like NodeRunner.Exe are eating away my memory like biscuits. As it turns out, these are all search host control related services that on a development machine can be told to back off a little.

So here are my steps and pointers:

  • Create a new Hyper-V virtual box and install Windows Server 2008 R2 with SP1 (of course you can opt for Server 2012, but let’s keep changes to a minimum for now).
  • Log on to the new Windows Server 2008 R2 SP1 VM as local administrator.
  • Promote your server to Domain Controller e.g. FUTURAMA.local.
  • Create the necessary SharePoint and SQL service accounts e.g. FUTURAMAscvacc_spfarm (Farm Account), FUTURAMAsvcacc_spsvc (SharePoint Service Application Pool Account), FUTURAMAsvcacc_appsvc (SharePoint Web Application Pool Account) and FUTURAMAsvcacc_sql (SQL Service Account)
  • Install SQL Server 2008 R2 with SP1 (configure the SQL Service Account to run all SQL related services). For the User Profile Synchronization Service to start properly, it’s vital that you install the full version and not SQL Server Express. Also avoid creating a named instance. Alternatively, you can opt to create an alias.
  • Run SharePoint’s 2013 prerequisiteinstaller.exe (and make sure it continues running when it optionally reboots your server)
  • Install SharePoint 2013.
  • Configure SharePoint 2013 using the wizard (configure FUTURAMAsvcacc_spfarm as the Farm Account) and create the SharePoint_Config database on the default SQL instance i.e. not on a named instance or else you might run into trouble later when starting the User Profile Synchronization Service.
  • Using the Farm Wizard (available from the Central Administration) create a Managed Account for FUTURAMAsvcacc_spsvc and mark a number of Service Applications for Installation (here’s my selection: App Management Service, Business Data Connectivity Service, Managed Metadata Service, Search Service Application, Secure Store Service, State Service, Usage and Health Data Collection, User Profile Service Application and User Profile Service Application).
  • As last step, let the wizard create a Site Collection so you have default root website. Since it’s a development box, you naturally pick the Developer Site template for the Site Collection’s root website.
  • Still in Central Administration create an additional Managed Account (Central Administration > Security > Manage security accounts) for FUTURAMAsvcacc_appsvc and change the Application Pool Identity for the default Web Application (I personally like the Web Application to run under a different account as SharePoint Web Services, but it’s a matter of taste).
  • At this point you’ll need to adjust the memory claim of App Fabric’s Distributed Cache Service. First verify whether the service was started at all (Central Administration > Systems settings > Manage services on server > Distributed Cache). Start PowerShell and make sure you add SharePoint’s cmdlets (Add-PsSnapin > microsoft.sharepoint.powershell + Enter). First verify that the Distributed Cache is UP by typing:
Get-CacheHost (verify it's UP)
Get-CacheHostConfig (verify the current cache size)
Update-SPDistributedCacheSize -CacheSizeInMb 100
  • Ps, App Fabric stores its configuration like provider and connectionString variables in the registry here: HKLM>Software>Microsoft>AppFabric>V1.0 and those variables are set when you run Add-SPDistributedCacheServiceInstance as a PowerShell cmdlet.
  • Now update all the web.config’s of all SharePoint services to avoid them demanding 5% of memory, which on a box with only 6 GB simply is not around. If you don’t do this, none of the services can be activated. To achieve this you need to update the web.config files of all services in “C:Program FilesMicrosoft Office Servers15.0WebServices” as well as in “C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions15WebServices” (or similar folders if you have decided to spread the installation over multiple drives). Simply add the following line “<serviceHostingEnvironment minFreeMemoryPercentageToActivateService=”0″ />” immediately below “<system.serviceModel>” e.g.:
<servicehostingenvironment minFreeMemoryPercentageToActivateService="0" />
  • Before you can start the User Profile Synchronization Service you need to make the Farm Account a local administrator. Unfortunately, this group is no longer visibly available on a Windows server that was previously upgraded to Domain Controller. Therefore launch the command prompt as Administrator (right mouse click Command Prompt > Run as Administrator) and type:
net localgroup administrators /add FUTURAMAsvcacc_spfarm
  • In addition you may find that the NetBios name of your domain isn’t the same as the fully qualified domain name. If that’s the case (or if you just want to be sure) run the following PowerShell commands:
Get-SPServiceApplication (copy the id of the User Profile Service Application)
$uspa = Get-SPServiceApplication -Id "%paste the id of the User Profile Service Application%"
$uspa.NetBiosNamesEnabled = 1
  • Before starting the service you need to verify whether the Farm Account has permissions to Replicate Directory Changes: (also read through the other 3 recommendations – normally they wouldn’t apply, but as the saying goes: Better be safe than sorry).
  • Ps, If you let SharePoint’s Farm Configuration Wizard configure a default Site Collection, you may find that a MySite host was already prepared for you, e.g.:MySite host: /my (explicit managed path),MySites path: /my/personal (implicit managed path).Otherwise, this is the time to configure MySites and make a (mental) note of the configuration (because you’ll need it later to configure the User Profile Synchronization Service Application).
  • Now it’s time for a coffee! Whilst sipping your coffee, just read Microsoft’s recommendations to make sure you haven’t missed anything so far:
  • Finally you can start the User Profile Synchronization Service (Central Administration > Systems settings > Manage services on server > User Profile Synchronization Service). This process may run for up to ten minutes. To make sure nothing goes wrong you can open the current ULS log (HIVE 15 > LOGS) and keep refreshing/reading it as were it a very exciting novell. If you followed these instructions, you shouldn’t see (m)any errors related to the provisioning of the User Profile Synchronization Application.
  • Ps, The process of installing the User Profile Synchronization Service Application involves updating the Profile and Sync DB, activating Microsoft’s Fore Front Indentity Synchronization Service (also see services.msc) whilst trying to add/read/manipulate registry keys here: HKL>System>CurrentControlSet>Services>FIMSynchronizationServices.
  • Also, if you want to see how synchronization was handled by Fore Front Identiy Manager (FIM) you may want to start the Synchronization Service Manager UI that you’ll find here: C:Program FilesMicrosoft Office Servers15.0Synchronization ServiceUIShellmiisclient.exe
  • If you’re lucky, the service has started. According to the documentation you can now remove the Farm Account again from the local administrators group. I must confess that I haven’t done this so far. It’s a development environment after all.
  • To be able to develop and debug/deploy SharePoint 2013 Apps using Visual Studio 2012 you still need to configure the Subscription Settings Service Application as well as set up the App Domain for isolating Apps. However, here my fellow Dutch country woman (and former colleague at Avanade) Mirjam van Olst did a great job:
  • To free up some memory you can now reduce the SharePoint Search Host Controller from consuming unlimited memory resources. If you don’t execute this step (at this time) you might find that a couple of NodeRunner processes consume endless amounts of memory. First set off the following PowerShell command:
    Set-SPEnterpriseSearchSerivce -PerformanceLevel Reduced
  • Then update C:Program FilesMicrosoft Office Servers15.0SearchRuntime1.0noderunner.exe.config and set memoryLimitMegabytes to anything greater than 0 (=default):
<nodeRunnerSettings memoryLimitMegabytes="50" />

Conclusion: Life for a SharePoint developer just has grown a bit more complicated, surely if you used to be a lazy guy like me and simply used the local administrator account on your undersized development machine as Farm Account!



Adding a local SharePoint 2013 (development server) as a cache host to AppFabric’s cache cluster

UPDATE If you’re landed at this page, you’re probably stuck with a SharePoint 2013 installation that is causing you headaches. If that’s the case you may want to read this post first:

Having just installed SharePoint 2013 my eye was struck by an anoying error report:


Apparently, SharePoint 2013 had some trouble displaying the microfeed. Digging a little deeper I found many errors in the Event Log e.g.

Application: DistributedCacheService.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.UriFormatException
at Microsoft.ApplicationServer.Caching.VelocityWindowsService.StartServiceCallback(System.Object)
at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
at System.Threading.ThreadPoolWorkQueue.Dispatch()

Further reading through the event log made me aware that the Distributed Cache Service was not able to start because it demands by default 10% of available physical memory. Having installed SQL and SharePoint on a single server with 6 GB clearly would not work. Luckily I quickly found the following blog entry and thought my troubles were over. Wrong!

I fired up PowerShell and typed

Set-CacheHostConfig -Hostname SP2013 -cacheport 22233 -cachesize 300

I tried other commands e.g.

Get-CacheHostConfig -ComputerName SP2013 -CachePort 22233

But all I would get was

Get-AFCacheHostConfiguration : ErrorCode<ERRCAdmin010>:SubStatus<ES0001>:Specified host is not present in cluster.
At line:1 char:1
+ Get-AFCacheHostConfiguration -ComputerName SP2013 -CachePort "22233"
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Get-AFCacheHostConfiguration], DataCacheException
+ FullyQualifiedErrorId : ERRCAdmin010,Microsoft.ApplicationServer.Caching.Commands.GetAFCacheHostConfigurationCommand

For some reason or another, my server wasn’t registered as a cachehost in the first place. I downloaded and studied Microsoft’s Windows Server AppFabric Caching Deployment and Management Guide and it quickly appeared to me that I needed to manually add my server as a cachehost as follows:

Register-CacheHost -Provider %PROVIDER% -ConnectionString %CONNECTION STRING% -Account "NT AuthorityNetwork Service" -CachePort 22233 -ClusterPort 22234 -ArbitrationPort 22235 -ReplicationPort 22236 -HostName SP2013

However, I had no clue what to enter as the provider and the connnection string. It turns out that SharePoint Distributed Cache cluster configuration info can be found in a file named “DistributedCacheService.exe.config” that is stored in the “AppFabric 1.1 for Windows Server” folder. As a provider I had to enter “SPDistributedCacheClusterProvider” and the connnection string value needed to point to SharePoint’s config database e.g. “Data Source=SP2013SQLExpress;Initial Catalog=SharePoint_Config;Integrated Security=True;Enlist=False”. However, even though these values can be found here, they are in fact stored in the registry here: HKLMSoftwareMicrosoftAppFabricV1.0Configuration. If for some reason information cannot be found here, your distributed cached will error out stating “Error in reading provider and connection string values”. I also noticed that in this config file the host name was called “localhost”. I changed this to “SP2013″ (However, I don’t believe it’s supported to update out-of-the-box files). Finally my server was added as a cachehost to AppFabric cachecluster but it refused to start …

HostName : CachePort Service Name Service Status Version Info
-------------------- ------------ -------------- ------------
SP2013.FUTURAMA.LOCAL:22233 AppFabricCachingService DOWN 3 [3,3][1,3]

Of course I still needed to trim its out-of-the-box memory requirements as follows:

Set-CacheHostConfig -Hostname SP2013 -cacheport 22233 -cachesize 300

Now finally things started to work …

HostName : CachePort Service Name Service Status Version Info
-------------------- ------------ -------------- ------------
SP2013.FUTURAMA.LOCAL:22233 AppFabricCachingService UP 3 [3,3][1,3]

If you’re really unlucky and the Windows AppFabric Caching Service has encountered too many errors, its startup mode may have been set to Disabled. In that case you need to change it back to Automatically. However, don’t start the service using the Windows Service Configuration panel. Instead, once you applied all changes, simply type:


It seems the Distributed Cache Service will cause us a few headaches in the years to come, still … It’s a great solution for problem that has been around for too long!



Search Content Web Part for SharePoint 2010 (Sandbox)

Every since I learned about SharePoint 2013’s Content Search Web Part, I thought “Hey, that’s easily done with SharePoint 2010 as well!”. This weekend I finally managed to put my head down and do some creative programming. But of course, as this is the Age of Apps, I wanted to create a lightweight (a.k.a. a sandboxed) solution. Below, you’ll find a first screenshot of what I came up. It gives a rather good first impression of what the Search Content Web Part for SharePoint 2010 can do (for you).


Click image to enlarge

So what can it do? The basic idea of the Content Search Web Part is simple yet effective: Define and execute a search query and go and fetch for each result the corresponding item with its wealth of information, which is subsequently merged into an attractive grid-like layout. This cannot be achieved with the out-of-the-box Core Search Result Web Part simply because SharePoint’s Search Application doesn’t return enough information. Let me try and explain, using the example shown in the previous screenshot. Here, for instance, information found in SharePoint Publishing Pages is used to build an attractive layed out UI element. I’ve used cupcakes (many thanks to the guys over at; It’s such a tasteful alternative to regular lorem ipsum) but in real-life this can be the latest Corporate or Departmental News. Links to those pages were returned as a result from a keyword based search query for “Cupcake AND Brownie”. The seach query was further enhanced to search within the “All Sites” scope and to only return items of a specific content class (in this case: STS_ListItem_850, which corresponds to SharePoint Publishing Pages). But page content, rollup images, last modified dates etc. of course are not part of the results that were returned. So this is where the Content Search Web Part starts to do more than the out-of-the-box Search Core Results Web Part. Doing more, in this case, means fetching additional (item) information for each search result. With the detailed information available, the Content Search Web Part starts merging it into an attractive template (e.g. an HTML/CSS snippet). The outcome of this step is then placed in a grid-layout that is defined by a number of results per row and a maximum number of items that should be returned in the first place. To beautify the final result, an external CSS file (for example uploaded to the site’s Style Library) can be linked to the Web Part.

A couple of benefits of this approach …

  • It pulls together data across multiple SharePoint Sites, Site Collections and even Web Application
  • It’s lightweight i.e. you don’t need to ask the administrator to install it. Instead, it’s sufficient to have Site Collection Administrator rights.
  • It’s easy and intuitive to configure.
  • Templates can be defined using industry standards such as HTML and CSS
  • It doesn’t create any dependencies when upgrading to the next version (then it can be replaced by SharePoint 2013’s out-of-the-box Content Search Web Part)

A closer look …

To create a sandboxed web part I could have opted for SharePoint’s Client Object Model. But I didn’t. Instead I choose for a client-side jQuery approach that would query SharePoint’s web services. This means that the server (SharePoint) needs to exchange information e.g. settings with the client (Browser / jQuery). Under the hood, when the web part is loaded, this is achieved by using a number of hidden form fields. All the settings entered by the user into the web part’s editor (see screenshot below) are hence available to the client once the user applies his configuration.


With this information available, the client invokes a query to SharePoint’s Search Query Web Service (<your site>/_vti_bin/search.asmx). For each search result that is found in the response of SharePoint’s Search Query Web Service, the client continues querying SharePoint’s Lists Web Service (<search result’s path to item’s site>/_vti_bin/lists.asmx) to get the list item for each result using the PATH property found in search result. Unfortunately, this may result in the client trying to obtain a list item e.g. an Announcement or a Publishing Page of a SharePoint site that resides in a different Web Application. So the client basically tries to invoke a query across different domains and this is not allowed (known as XSS or cross-site scripting). However, jQuery (as of version 1.6) provides a work-around. But this work-around shows a warning to the user that a cross-domain query is about to be invoked: “This page is accesssing information that is not under its control. This poses a security risk. Do you want to continue?”.


Cross-domain queries can be surpressed by deselecting “Allow queries to other web applications”. When surpressed, any query to another web application fail and hence the results will fail in the final output.

Defining item fields …

Each search result returned from SharePoint’s Search Query Web Service itself doesn’t contain a whole lot of information. But it provides a PATH property that can be used to locate the item in SharePoint. Knowning the item’s location, its information stored in fields (= columns) can easily be retrieved using SharePoint’s List Web Service. However, at a lower level, SharePoint uses field names that are differ from the column names visible in the UI. Once a valid search Query was defined and tested (by clicking Apply in the web part editor panel) the raw XML output can be viewed. This helps to find the names of the fields (colored red) that contain the information that can be merged into the template. The following screenshot is an example of such output.


Click image to enlarge

Remark The Content Search Web Part will try to automatically change relative URLs (like ows_PublishingRollupImage in the example above) into absolute URLs.

Field names can then be entered into the web part’s editor panel separated by a semi colon e.g. “ows_PublishingPageContent;ows_PublishingRollupImage” (without quotes). In addition, it is possible to limit the number of characters returned. This limit can be entered between square brackets immediately following the field name as follows: “ows_PublishingPageContent[400];ows_PublishingRollupImage”. This will cause the text to be shortened to the first 400 characters. It will then cut off at the end of last word and add a read-more link. When the user click’s this link, he/she will be taking to the original item. A close-up look is shown in the following screenshot.


Remark The markup e.g. “<p><span class= ng-dire…” is ignored when the content is shortened. Only the text within the HTML markup is used.

Creating the Template …

The Template Editor isn’t a highly advanced editor. But it is sufficient for pasting any HTML snippet created in a full-blown editor. The template is for laying out a single item i.e. not for laying out the whole result set returned. The idea behind this is that each item is the basically same by definition. Only the content is different. The Search Content Web Part then takes care of laying out items according to the grid that the user defined i.e. number of items per row and total number of items that should be returned.


Click image to enlarge

Content for each field that was retrieved is can be easily placed into the Template using a wiki-like notation e.g. for “ows_PublishingPageContent” use “[[ows_PublishingPageContent]]” (again, no quotes). The cupcake example that I used uses the following (simple) template:

<div id=”CSWPNewsItemHeader”>
<div id=”CSWPNewsItemTitle”>
[[ows_Title]] </div>
<div id=”CSWPNewsItemModified”>
[[ows_Modified]] </div>
<div id=”CSWPNewsItemBody”>
<div id=”CSWPNewsItemContent”>
[[ows_PublishingPageContent]] </div>
<div id=”CSWPNewsItemRollupImage”>
[[ows_PublishingRollupImage]] </div>

Understanding the grid-layout and CSS …

The Search Content Web Part places each merged output into it’s own DIV that is then placed into another DIV (=ROW) that eventually resides inside another DIV (=Container). However, there is one challenge with this setup: the width property of the DIV that holds the merged outcome. Most of the CSS that defines the setup of the grid i.e. the container, rows and row items is defined in a CSS file that is automatically placed inside the Style Library in a separate folder CSWP (here you also find the javascript files used by the Content Search Web Part) called CWSP.css. In addition, you can specify your own CSS file with CSS instructions for you template. For a good result, you need to include the following CSS instruction:

width: 48%;
display: inline;
padding: 5px;
margin: 0px;
float: left;

This statement is for the box that frames the template. In my example I specified that I want 2 items per row. Hence I’ve specified a width property of 48%. If you want only 1 result per row, you need to specify it with a width of about 98% or 99%.

Error handling …

Errors are handled in a SharePoint friendly manner. The following screenshot show the error that is raised when the search scope is omitted.


Click image to enlarge

Requirements …

Downloading …

Feel free to download Search Content Web Part using the following link: (rename extension from ZIP to WSP e.g. WebParts.WSP)

It will show a little banner at the bottow as follows:


Click image to enlarge

Feel free to make a donation ( ) if you like it. In that case I happily send you a copy without banner!

Installing …

1. Upload WSP file to the site’s solution gallery



2. Activate uploaded solution


3. Add Content Search WebPart to the page