Category Archives: sharepoint
Prerequisite components error when creating a Visual Studio 2012 SharePoint 2013 App project
Yeah, I know… it’s a horrible blog title. But I hope Google/Bing/whatever brings you here in case you experience this error.
So you’re ready for doing some Office 2013 / SharePoint 2013 App development and happily installed Visual Studio 2012 and the Microsoft Office Developer Tools for Visual Studio 2012. You then quickly fire up Visual Studio 2012 (remember: using administrative privileges!), select the new “App for SharePoint 2013” template, work your way through the App for SharePoint settings wizard and finally press “Finish”….
BANG! The following error dialog appears:
For SEO purposes I will repeat the dialog text here:
“An error occurred while trying to load some required components. Please ensure that the following prerequisite components are installed:
Microsoft Web Developer Tools
Microsoft Exchange Web Services”
Very weird, especially since the Web Platform Installer should have taken care of these two prerequisites. Since I encountered this error yesterday, I spent some time investigating it. I actually found some references to it here and here. As you can read in those threads the culprit seems to be a pre-installed instance of the Exchange Web Services API. I remembered having installed that API a week ago to do some testing. Apparently the Web Platform Installer doesn’t correctly handle a pre-installed version of the Exchange Web Services API very well.
The solution was simple: just uninstall BOTH the Exchange Web Services API and the Microsoft Office Developer Tools for Visual Studio 2012. Then reinstall (only) the Office Developer tools. This time the Web Platform Installer will ensure the correct Exchange Web Services API is also installed. If all went well you should be able to create a new “App for SharePoint 2013” project without any problems!
The Return of the Search Application Topology Component Health State Error
Today I was prepping a SharePoint 2013 VM and noticed the Search Service Administration page in Central Admin didn’t display the Search Application Topology health indicators. Instead it showed an error I hadn’t seen in a while:
“Unable to retrieve topology component health states. This may be because the admin component is not up and running”
I had encountered this error several times during the SharePoint 2013 preview phase. Then it turned out to be a genuine bug and fixing it required the installation of several hotfixes as detailed in the SharePoint Server 2013 Known Issues article. However, on this particular VM I had installed the RTM versions of Windows Server 2012, SQL Server 2012 and SharePoint 2013. I also had installed the latest updates and the SharePoint 2013 Prerequisites Installer should have taken care of other missing stuff. So this bug shouldn’t have happened again.
Just to be sure I tried installing the four hotfix packages, but (of course) this failed as they were either already installed or not relevant anymore. Now, I was pretty sure I had seen fully working Search Application Topology health indicators the night before (yeah, we SharePointies are nightly creatures). So what could have changed?
Then I remembered I had performed a little tweak to minimize SharePoint 2013’s memory usage. As you may know SharePoint 2013 has some very high memory requirements, especially around Search. Specifically the Search Engine’s NodeRunner.exe processes are memory hungry beasts. A SharePoint 2013 server configured for Search typically has five such NodeRunner.exe instances running, each consuming hundreds of megabytes of memory. For production environments this may be just fine, but on my development and demo VM’s I like them a little less greedy.
From earlier blog posts I learned it is possible to limit the amount of memory a NodeRunner.exe instance uses, by adjusting the memoryLimitMegabytes parameter in the C:\Program Files\Microsoft Office Servers\15.0\Search\Runtime\1.0\NodeRunner.exe.config XML file. In fact, in the SharePoint 2013 Preview version the NodeRunners suffered from a memory leak and adjusting this config was a quick hack to fix this leak. One of the last things I did last night was change this value from 0 (unlimited) to 100 MB. However, I hadn’t actually come around to testing the outcome of this change (yes, I do need some sleep).
...
<nodeRunnerSettings memoryLimitMegabytes="100" />
...
So the first thing I did was starting SysInternals Process Explorer (which I always use instead of the built-in Task Manager) and searched for the NodeRunner.exe processes.
To my surprise there weren’t any…
The NodeRunner.exe instances are spawned by SharePoint’s Search Host Controller Service, so the first thing I did was go to the “Manage Services on Server” page in Central Admin and restart that service. Thanks to Process Explorer’s handy ‘Difference Highlighting’ feature it was clearly visible that several NodeRunner instances got started, but almost immediately stopped running.
To get a little more information I started SysInternals Process Monitor (another indispensable tool) and logged the system while restarting the Search Host Controller Service. From Process Monitor’s ‘Process Tree’ dialog it was clear (too) many NodeRunner instances were started, but somehow weren’t able to survive for long.
Process Explorer also showed me the NodeRunner processes were started using the following command line parameter:
"C:\Program Files\Microsoft Office Servers\15.0\Search\Runtime\1.0\NodeRunner.exe" --noderoot "C:\Program Files\Microsoft Office Servers\15.0\Data\Office Server\Applications\Search\Nodes\9E4952\IndexComponent1" --addfrom "C:\Program Files\Microsoft Office Servers\15.0\Data\Office Server\Applications\Search\Nodes\9E4952\IndexComponent1\Configuration\Local\Node.ini" --tracelog "C:\Program Files\Microsoft Office Servers\15.0\Data\Office Server\Applications\Search\Nodes\9E4952\IndexComponent1\Logs\NodeRunner.log"
From the bold piece above I learned NodeRunners keep a trace log. When I checked that file, the cause for the failing of the NodeRunners became pretty clear:
Caught exception in node activator: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown.
at Microsoft.Ceres.CoreServices.Node.NodeActivator.ActivateNode(IDictionary`2 configuration)
--- End of inner exception stack trace ---
Since I figured this must be due to me changing NodeRunner’s memory limits, I reset the NodeRunner’s config file (hey, always keep a backup!) and again restarted the Search Host Controller Service. This time the NodeRunner instances continued to run just fine. So it became clear to me there apparently is some minimum amount of memory a NodeRunner instance needs to be able to run and in my case it needed more than 100 MB.
With the NodeRunner instances running just fine, the Topology Health indicators also worked again, showing my farm’s Search stuff was in perfect health. I experimented with the NodeRunner memory limits some more and finally settled for a 250 MB limit. Not as small as I’d liked them to be, but still a significant decrease when compared to their original memory footprint.
I do want to make clear that even with this 250 MB limit I experienced some NodeRunner crashes. The general advice is to NOT change the NodeRunner memory limit configuration. And NEVER EVER do this in a production environment!
Hopefully this blog post helps out other people who might stumble upon this problem.
SharePoint 2009 Comes With Ribbon Interface?
The next version of SharePoint, aka SharePoint 2009 or Office Server 14, is scheduled for release sometime during the second half of 2009. Various blogs have already listed some of the presumed new features, like these:
- 64-bit only
- Silverlight UI / Web Parts
- Better support for dealing with large lists (must-have!)
- Groove integration
Recently I heard of a new feature that I hadn’t seen on any of these lists: SharePoint 2009’s default web interface will be using the (in)famous Ribbon interface. I was told this information comes from a SharePoint Product Manager at Microsoft, so it should be reliable.
Now I don’t really know what to think about this. I still have a love-hate relationship with the Ribbon ever since Microsoft released it with Office 2007. For basic Office usage it works very well, but for some tasks it find myself scrolling between Ribbon tabs like a madman.
On the other hand, SharePoint 2007’s UI isn’t that good either. The menus are all over the place and rather complicated, especially for first time users. Use of a Ribbon could improve on this. And considering the fact that SharePoint (i.e. Microsoft Office SharePoint Server) belongs to the Office family, it makes perfect sense to give it an Office-like interface. This would definitely enhance the integrated experience.
Now that I think about it, Microsoft’s Office website has been using a Ribbon-like interface for some time now and I must admit it looks nice. Maybe that’s the exact same Ribbon that’s going to end up in SharePoint 2009? Who knows… Maybe they’ll even implement it using Silverlight, so it will respond to my mouse’s scroll wheel, so I can continue that scrolling between Ribbon tabs like a madman 😉
Update: I’ve received several e-mails from people claiming they already have the Office 14 alpha bits and they all confirm SharePoint 2009 / Office Server 14 is using the Ribbon for its menu’s.
RIP: Patrick Tisseghem
I just heard the shocking news that Patrick Tisseghem, co-founder, managing director of U2U and Microsoft SharePoint MVP, has passed away last week. This is a great loss for the SharePoint community. The U2U website has this to say:
It is with deepest regret that we have to announce the death of Patrick Tisseghem, co-founder of U2U. Patrick suddenly passed away on Wednesday 3 September 2008 around 18 hours in Gothenburg Sweden due to a heart failure. Our sympathy and thoughts go out to his wife Linda, their daughters Anahi and Laura, and to his family. We are all deeply saddened by this tragic loss. We remember him as caring father as well as a driven and warm hearted colleague and friend. We miss you Patrick.
The last time I spoke to Patrick was a few months ago at the Dutch Microsoft DevDays 2008 in Amsterdam. After one of his sessions he helped me out with some SharePoint custom security trimmer problems I had.
I think he was a great guy and I always liked attending his presentations. Especially the funny, sarcastic, remarks used to make about SharePoint. My deepest condolences to his wife and daughters. Goodbye and thank you, Patrick!
Building a SPQuery ViewFields string
If you’re querying SharePoint content using a CAML query from code it’s a good habit to always populate the SPQuery instance’s ViewFields property. Otherwise the returned SPListItem instances might not contain any data for certain fields and throw an exception when you try to access those fields.
Specifying ViewFields involves creating a string of CAML FieldRef elements. For instance if we want our query to return items that contain data for the Title, Created and ID field we use this:
1: <FieldRef Name='Title'/><FieldRef Name='Created'/><FieldRef Name='ID'/>
As you can see there’s some overhead of boilerplate markup involved. I’ve written a small piece of code that I always use to make my life a little easier. Today I happened to post this code in a reply I wrote on the MSDN forums and also decided to submit it as Community Content to the official SPQuery docs on MSDN. Then I thought I might as well share it with you here. So here it is:
1: public static string BuildViewFieldsXml(params string[] fieldNames)
2: {
3: const string TEMPLATE = @"<FieldRef Name='{0:S}'/>";
4: StringBuilder sb = new StringBuilder();
5: foreach (string fieldName in fieldNames)
6: {
7: sb.AppendFormat(TEMPLATE, fieldName);
8: }
9: return sb.ToString();
10: }
11:
12: // Use it like this:
13: SPQuery query = new SPQuery();
14: query.ViewFields = BuildViewFieldsXml("Title", "Created", "ID");
15:
16: // Note that you can specify a variable amount of string parameters, i.e.
17: query.ViewFields = BuildViewFieldsXml("Title", "Created", "ID", "Author", "Gender");
Yeah, you’re right. This piece of code isn’t exactly rocket science. But you might appreciate it anyway 🙂
SharePoint Frustrations #1: The undocumented “IncludeTimeValue” CAML attribute
I’m planning on doing some posts about frustrating things I have encountered (and still do!) during my SharePoint development efforts. Here’s the first one:
Last year while working on a MOSS 2007 project for one of our customers I stumbled on what I thought was a bug in SharePoint 2007. I had created a custom list that was filled with Electronic Program Guide (EPG) information for the streaming video media that that site contained. I then created a Webpart that used ASP.Net AJAX to continually show the actual EPG information below the video stream.
In order to obtain the EPG items I used a CAML query to query the EPG list. The list was simply a custom list containing amongst others a column of type DateTime that was called "ProgramEnd". As the name suggests it contained the time the program ended. I then used the following code to create a query that was supposed to obtain the currently broadcasted item and all future items.
1: const string EPG_QUERY_TEMPLATE = @"
2: <Where>
3: <Geq>
4: <FieldRef Name='ProgramEnd' />
5: <Value Type='DateTime'>{0}</Value>
6: </Geq>
7: </Where>";
8:
9: SPQuery query = new SPQuery();
10: query.Query = String.Format(EPG_QUERY_TEMPLATE,
11: SPUtility.CreateISO8601DateTimeFromSystemDateTime(DateTime.Now));
12: // ...
To my surprise this query always returned too many items. Further investigation showed that time part of the query seemed to be ignored completely, so it returned the items as if no time was specified! So instead of getting the current item and all future items it returned all items broadcasted for that day.
After wasting a lot of time debugging, using the U2U Caml Query Builder and looking for an answer / solution on the internet I gave up and wrote a quick hack around it, which fortunately wasn’t very difficult. It would just run the query and run the results through some additional code that checked the ProgramEnd DateTime field and filter out the wrong items, like this:
1: SPListItemCollection results = ...; // The results from the query mentioned above
2: // Trim the results to only include the current and future items
3: List<SPListItem> trimmedItems = new List<SPListItem>();
4: foreach (SPListItem result in results)
5: {
6: DateTime programEnd = (DateTime)result["ProgramEnd"];
7: if (programEnd >= DateTime.Now)
8: trimmedItems.Add(result);
9: }
Fortunately this worked just fine and the customer was happy. I was not… 😦
Today while surfing the Net I stumbled on this entry in the MSDN forums, from which I learned it wasn’t a bug, but that you need to included the "IncludeTimeValue" attribute to the CAML query, like this:
1: <Where>
2: <Eq>
3: <FieldRef Name='programEnd' />
4: <Value Type='DateTime' IncludeTimeValue='TRUE'>
5: 2008-07-30T12:00:00Z
6: </Value>
7: </Eq>
8: </Where>
If only I had known it was this simple… What bothers me is that this little, but very important attribute seems to be totally undocumented. I couldn’t find any information about it in the WSS / SharePoint SDKs.
Ofcourse once I knew what to look for I found some other blogs and forums mentioning this issue. It turns out the UCSharp blog had already blogged about this way back in October 2007, only a few months after I searched for it. Even Karine Bosch, U2U’s "CAML Girl" and author of the famous U2U CAML Query Builder, says she only recently found out about this. Fortunately she has included support for the "IncludeTimeValue" attribute in her latest version of the U2U Caml Query Builder, which I know a lot of SharePoint developers use to construct and test their CAML queries.
I also noticed that someone called puneetspeed has added some Community Content to the online SharePoint SDK’s SPQuery docs explaining this issue. So hopefully Microsoft will add information about the "IncludeTimeValue" attribute to the official SDK text in the near future.
Do not reuse SPQuery!
Last week I was refactoring some of my SharePoint code. I stumbled on a loop that created a new SPQuery instance for each iteration. The code was something like this:
1: SPList list = GetCommentsList();
2: const string VIEWFIELDS = "";
3:
4: foreach (string param in params)
5: {
6: // Create fresh new SPQuery instance...
7: SPQuery query = new SPQuery();
8: query.ViewFields = VIEWFIELDS;
9: query.Query = BuildQuery(param);
10:
11: // And use it...
12: SPListItemCollection items = list.GetItems(query);
13: ProcessItems(items);
14: }
As the value of the ViewFields property remained the same for each iteration I decided to create just one SPQuery instance and reuse it, like this:
1: SPList list = GetCommentsList();
2: const string VIEWFIELDS = "";
3:
4: // Create just one SPQuery instance...
5: SPQuery query = new SPQuery();
6: query.ViewFields = VIEWFIELDS;
7:
8: foreach (string param in params)
9: {
10: // And reuse it...
11: query.Query = BuildQuery(param);
12: SPListItemCollection items = list.GetItems(query);
13: ProcessItems(items);
14: }
To my surprise this code didn’t work! The first time the SPQuery instance was used it worked just fine. However, during the next iterations of the foreach loop it didn’t seem to get updated.
So, what have we learned today? Never reuse SPQuery instances!
Well… That’s not entirely true. You can reuse SPQuery instances for a very valid reason. If you use the RowLimit property you can limit the number of items returned in the query, which is useful for paging as seen in this sample code (taken from MSDN):
1: using (SPWeb oWebsiteRoot = SPContext.Current.Site.RootWeb)
2: {
3: SPList oList = oWebsiteRoot.Lists["Announcements"];
4: SPQuery oQuery = new SPQuery();
5: oQuery.RowLimit = 10;
6: int intIndex = 1;
7:
8: do
9: {
10: Console.WriteLine("Page: " + intIndex);
11: SPListItemCollection collListItems = oList.GetItems(oQuery);
12:
13: foreach(SPListItem oListItem in collListItems)
14: {
15: Console.WriteLine(oListItem["Title"]);
16: }
17: oQuery.ListItemCollectionPosition =
18: collListItems.ListItemCollectionPosition;
19: intIndex++;
20: } while(oQuery.ListItemCollectionPosition != null);
21: }
So, only reuse SPQuery instances if you use paging. If you change the actual CAML query you should create a new SPQuery instance for it.
Beware of the SharePoint Memory Leaks!
Beware of the SharePoint Memory Leaks!
You might not know it, but when developing for SharePoint (either WSS 3.0 or MOSS 2007) it is very easy to cause memory leaks, which can ultimately thrash your SharePoint server’s performance. The reason for this is that even though your own code might be written using only managed code, the SharePoint API still uses unmanaged code in some places. These unmanaged resources have to be explicitly disposed of, especially considering the fact they are living inside an ASP.Net web application (SharePoint) and potentially can have a long lifetime.
The problem is that the SharePoint API doesn’t always make clear when exactly you have to dispose of objects explicitly. Sometimes it may look like you’re just inspecting a value of a property, while in the background a whole new object is instantiated, which holds valuable unmanaged resources that should be freed by the caller (you!). Other times you might find yourself disposing an object, only to find out you weren’t supposed to…
Way back in June 2006 Microsoft employees Scott Harris and Mike Ammerlaan released their article Best Practices: Using Disposable Windows SharePoint Services Objects on MSDN, which can be regarded as the mother of all articles on this subject. I think this article is often overlooked and should be considered essential reading material for every serious SharePoint developer out there. Also read their more recent article called Best Practices: Common Coding Issues When Using the SharePoint Object Model, which also handles topics like data and object caching and writing scalable code.
Recently two other Microsoft employees also wrote interesting pieces on this subject. Stefan Goßner did a piece called Dealing with Memory Pressure problems in MOSS/WSS, in which he explains what a "Memory Pressure Situation" is and he lists some common causes and solutions for it. The other interesting read came from Roger Lamb. His entry is called SharePoint 2007 and WSS 3.0 Dispose Patterns by Example and in it he shows some very clear code samples and patterns on how to properly handle SharePoint objects.
Very cool material, guys!
Return of SmartPart V1.3 released
Yesterday Jan Tielens released a new version of his famous SmartPart to the community. It is now at version 1.3 and here’s the changelog:
- Added a setup wizard to install the Return of SmartPart.
- Added sample user controls (including connectable user controls and AJAX user controls).
- Added localization support for ASP.NET AJAX user controls.
- Various minor bug fixes.
- Nice 2-minute screencast on how to deploy and test the SmartPart.
- 64 bit version available.
Great work, Jan! I also like the fact you’ve used Lars Fastrup‘s SharePoint Solution Installer for deploying SmartPart.
LeonZandman.com 