The SPWebCollection.WebsInfo property

Recently, while browsing some MSDN docs, I came across the WebsInfo property of the SPWebCollection class. This property is a collection of the SPWebInfo class which contains metadata about each web in the given web collection.

Methods and properties such as SPWeb.GetSubWebsForCurrentUser,  SPSite.AllWebs and SPWeb.Webs, all return an object of the SPWebCollection class and the WebsInfo property can be used as a wrapper on some basic information about each web.

The properties available in the WebInfo class are:

1.  Configuration
2. CustomMasterUrl
3. Description
4. Id
5. Language
6. LastItemModifiedDate
7. MasterUrl .
8. ServerRelativeUrl
9. Title
10. UIVersion
11. UIVersionConfigurationEnabled
12. WebTemplateId

So when working with the returned collection of webs, if you refer to any of the above mentioned properties, then there is no further need to open an expensive SPWeb object of that web. The value of the property is simply returned from the SPWebInfo object. Here is some code which demonstrates how to use the WebsInfo property.

Now here is where it gets interesting. After deploying the above code, I switched on my Developer Dashboard to confirm that referring to any of the properties is indeed as non-expensive as claimed. And here is what my Developer Dashboard had to say regarding the call:

So only 1 database query was made with the procedure proc_ListAllWebsOfSite. After opening this procedure in the Content Database, it contained this piece of code:


In fact, if you want to refer to any of these properties directly from the SPWeb objects of the returned webs, then also no additional call will be made to the database to fetch the properties. Here is the code to demonstrate that:



As far as you access only these properties from the SPWeb object, there will be no need to make any more calls to the database.

Now, If you want to refer to any of the other properties of the SPWeb object, things are going to get expensive. For example, if you want to refer to the SPWeb.SiteLogoUrl property, you will get the following result in the Developer Dashboard:

So as you can see SharePoint has to call the proc_GetTpWebMetaDataAndListMetaData procedure for each SPWeb object in order to return the SiteLogoUrl property.

If you use reflector or ILSpy and open the SPWeb Class in the Microsoft.SharePoint.dll , you will see that there are 2 internal methods called InitWeb( ) and InitWebPublic( ) which are responsible for initializing most of the properties of the SPWeb object. These methods in turn call the SPWeb.Request.OpenWebInternal( ) method which actually does the job of calling unmanaged code to open the expensive SPWeb object.

This was indeed a valuable learning for me as it would hugely impact the performance of my code. I hope it was a good learning for you too!

PowerShell Scripts for SharePoint 2010

I was working with Large Lists recently and needed to create huge amount of test data. I had to work with about 2,000 Sub Sites, 2,000 Lists, 6,000 documents and about 20,000 list items. So naturally the all so powerful PowerShell was the only answer for creating such an amount of test data with so much flexibility and ease of use. So I thought to write down here some of my scripts which someone might find useful:

1) Index Fields:

2) Delete Site:

3) Upload Document:

4)Add New Group to Site:

5) Create New Site:

6) Add User to Site:

7) Clear Object Cache on All Web Front Ends

8) Enable the Developer Dashboard

Hope you find them useful!

Caching Options in SharePoint 2010

So recently we had to look up options for caching data in our project and I took the responsibility of doing some research on the various options available for caching in SharePoint 2010. The basic motive behind implementing caching was to reduce the calls to the database and hence improve the performance.
Here are some of my findings:

1) BLOB Cache

Binary Large Object cache or BLOB cache is a disk based cache in SharePoint. This means that the data is stored on the Hard-Disk of the Web Front End Server.
Initially for the first call, data is fetched from the database and stored on the WFE. Any further calls to the same data are responded with the cached version hence avoiding a call to the database.

It can be used to store data in a variety of format including images, audio, video etc. Furthermore, you can configure it to store files based on extension types to suite your environment. (Eg: jpg, js, css etc)

The BLOB cache is turned off by default. You will have to enable it from the web.config file of your web application if you want to use it.

To enable it, open the relevant web.config file and find the following line:

<BlobCache location="C:\blobCache" path="\.(gif|jpg|png|css|js)$" maxSize="10" enabled="false"/>

change that line to:

<BlobCache location="C:\blobCache" path="\.(gif|jpg|png|css|js)$" maxSize="10" max-age="86400" enabled="true" />

a. location is the location on the hard disk where your cache will be stored.
b. path is the regular expression used to determine the type of data to be stored
c. maxSize is the size in GB of the cache
d. max-age specifies the maximum amount of time (in seconds) that the client browser caches files. If the downloaded items have not expired since the last download, the same items are not requested again when the page is requested. The max-age attribute is set by default to 86400 seconds (that is, 24 hours), but it can be set to a time period of 0 or greater.
e. enabled turns the caching on if true and turns it off if false.

2) Page Output Cache

SharePoint also uses ASP.NET output cache to store page output. This requires the publishing features to be enabled on the Site Collection and hence it is only available in SharePoint Server 2010 and not SharePoint Foundation. This cache is stored in the Memory of the Web Front End and hence is reset when the application pool recycles.

SharePoint supports something called as cache profiles in the output cache. This means that different profiles of the page are created for groups with different levels of access to the page. The page is rendered initially when the first request is made and cached. Now if another user with the same access rights loads the page, then it is served from the cache. This is done for each group with different set of permissions. Find more information about the Page output cache here.

3) Object Cache

Object Cache can be said as the most popular of the SharePoint caches. It is a Memory based cache. This means that the data is stored in the RAM of the Web Front End Server. As a result of this, this cache is reset if the application pool of the web app is recycled.

The publishing features of a Site Collection need to be enabled for this cache to become available. And due to this, it is available only in SharePoint Server 2010 and not SharePoint 2010 Foundation.

A variety of functionality in SharePoint 2010 uses the object cache internally. Mostly it is used to store data retrieved from Cross List Queries. Classes such as the PortalSiteMapProvider and CrossQueryListIfo use the object cache internally to store information returned. Other elements of SharePoint such as the Content Query WebPart and the Navigation also use the object cache for storing retrieved data.

Once the Publishing Features are enabled, you can configure the object cache from Site Actions-> Site Settings -> Site Collection Object Cache.

The default size of the object cache is set to 100 MB and the expiry time is set to 60 Seconds. You can adjust these values to suite your environment after careful consideration and testing. Ideally it should not be kept under 3 MB otherwise it will start affecting the performance.

4) Web Storage of the Browser

And last but not the least, we have the Web Storage of the Browser itself. This is not a SharePoint specific cache but it can be used effectively with SharePoint none the less. It contains about 10 MB of space allocated on the Client Side. So even the request to the Web Front End does not have to be made as the data is already present on the client side. Some JavaScript plugins like jStorage wrap around the Web Storage and provide an excellent interface to access it. Find more about the Web Storage here.

Show Special Characters in XSLT WebParts.

Are you are working with XSLT WebParts (eg: People Search Core Results WebPart) and the special characters like ä, ë, é, ö, etc are getting replaced with a question mark (?) or a Square Box ? Let's change that then:

So basically the encoding of the XSLT is set to "iso-8859-1" by default and we will have to change it to "utf-8." Here is how to change the encoding: Find in your XSL file, the following line:
and change it to:
Now all the special characters should be visible perfectly.

Paging in SharePoint JavaScript Client Object Model

Paging can be of great help when you want to improve the performance of your code especially when you are working on front-end development and want to reduce the page response time. Let us see how can be implement paging when working with the JavaScript Client Object Model.

The important parts to note in this code are the RowLimit element in the CAML query and the SP.ListItemCollection.get_listItemCollectionPosition(); property. Please have a look at the comments to know more details about the individual lines of code.

The ListItemCollectionPosition.pagingInfo determines the id of the last item fetched along with the filter and sorting criteria. It specifies information, as name-value pairs, required to get the next page of data for a list view.

RegisterClientScriptBlock for SharePoint Sandbox Solutions

So we had this requirement where we had to check if a script was already loaded on the page before we push it. So my natural choice was to use the RegisterClientScriptBlock method. But this being a Sandbox solution, like always, things were much more difficult than they initially appeared.

The code executed without throwing any error so I thought I was good to go but the script was not getting registered and also the IsClientScriptBlockRegistered method was not doing its job. So after some searching around, I found the following page which explained my scenario:
http://blog.a-dahl.dk/post/Sharepointe28093Where-is-my-Page-object.aspx

So turns out that sandbox solutions runs in a "sandbox" mode with separate context and no access to the rest of the page. So to my huge disappointment, the ClientScriptManager class was out of bounds. Now it was up to me to figure out a workaround for this issue.

So I thought, why not push some good old JavaScript to the page to check the loading of the script? The challenge before me was that since I was pushing the script from server side to the page, the code would be executed before my DOM was loaded. Also, I could not use any jQuery here because it was included in my script which was to be checked and  loaded. So 1) I had to make sure that my code would get executed only after the page was loaded and  2) I had to do it using pure JavaScript.

The first problem could have been solved by using window.load = function( ) {} but due to the function's browser incompatibility, I decided against it. Thankfully, SharePoint provides an Out of the Box mechanism called _spBodyOnLoadFunctionNames in which we can push functions to be executed when the body tag of the document completes loading.
Being using jQuery very heavily in the past, using pure JavaScript was also an exciting challenge which was fun to do. So after about an hour of fiddling with this issue, I managed to put together a function which would check if a script with the particular id was loaded and if not, then only load it on the page. Here is my SandboxRegisterClientScriptBlock function:

Use pure html pages (instead of .aspx) in SharePoint 2010

So I was working on one of my unit testing projects which displayed the results in a plain old .html page. When integrating it with SharePoint 2010,  I realized that I could not navigate to .html pages. When I entered the URL of a html page, the browser asked me whether I wanted to download the html file instead of displaying it in the browser.

After some digging around I came across this very informative post:
http://social.technet.microsoft.com/wiki/contents/articles/8073.sharepoint-2010-browser-file-handling-deep-dive.aspx

So basically there are two modes for file handling in SharePoint 2010. "Strict" and "Permissive". Strict mode entails that only the trusted filetypes in the web application are opened in the browser. For all the rest of the filetypes the response will include a "X-Download-Options: noopen" header. This header will basically instruct the browser not to open the file inline.
When the mode is Permissive, no such restriction will be placed on the files. If a file lives inside SharePoint, then it will be displayed inline by the browser.

You can create a hybrid approach by keeping the Browser file handling mode as "Strict" and using the
SPWebApplication.AllowedInlineDownloadedMimeTypes property of the web application to specify which file types are trusted in your web application.

By default the Browser File Handling property of the Web Application is set to "Strict". To change it to permissive, follow these steps:

Go to Central Administration > Manage Web Applications > [Highlight a web application] > click General Settings in the Ribbon > Scroll down in the General Settings window to see Browser File Handling. Set as desired. Save settings.

Note: The recommended option from Microsoft regarding Browser File Handling is "Strict"

(Quick and Dirty hack: You can keep the extension of a file as .aspx and include pure html inside it and SharePoint will run it even if the Browser File Handling is set to "Strict")