CSOM – ContentType and CAML Queries

To retrieve the ContentType of a ListItem from the ListItemCollection using the GetItems method, there are two approaches that work.

  1. If you are not specifying ViewFields in your CAML query then in your Load method you need to Include the ContentType. e.g.

clientContext.Load(listItems, items => items.Include(item => item.ContentType));

  1. If you CAML query includes ViewFields then two modifications are required. The ViewFields needs to include the ContentTypeId field and the Load method needs to include the ContentType. e.g.
<ViewFields><FieldRef Name='ContentTypeId' /></ViewFields>

clientContext.Load(listItems, items => items.Include(item => item.ContentType));

SharePoint Client – Folder and Files

If you know the relative Url of the folder within SharePoint there is a straight forward way to access the files within that folder.

using Microsoft.SharePoint.Client;
using (ClientContext clientContext = new ClientContext(&amp;quot;https://something.sharepoint.com/sites/mysite/&amp;quot;))
    Folder folder = clientContext.Web.GetFolderByServerRelativeUrl(&amp;quot;/sites/mysite/root_folder/sub_folder&amp;quot;);

    // Load the Folder and Files into the ClientContext so we can access them

    foreach (var item in folder.Files)
        // Load each file into the ClientContext to access the file information

SharePoint Deployment – Access is denied!

I got the following error while trying to upgrade a site feature in SharePoint:

The copying of this file failed: Feature.xml. 
Access to the path 'C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\
Template\Features\<MyFeature>\Feature.xml' is denied.

I hadn’t changed any of the SP settings and the process for doing the deployment hadn’t changed so what was SP getting upset about now??? Taking a look at the directory where the Feature.xml was supposed to be installed provided me with the answer. For some reason, yet to be explained by computer science, the directory was left in a state of limbo. I couldn’t open it to view the content, see the security settings or rename/delete it. First of all I tried resetting IIS to see if that would release its grip on this defunct directory but this gave me no further progress. In the end I restarted the machine, the phantom directory disappeared and I was able to continue on with my deployment process as normal.


Feature activation error

The element of type ‘Module’ for feature ‘<feature name>‘ (id: 03fffd3f-5b80-4507-87ed-ab8797883b04) threw an exception during activation: Cannot complete this action.  Please try again.

Whilst trying to activate a new feature I had deployed to SharePoint I got this error (above). My feature worked fine during development but the activation just kept throwing an error. The error wasn’t very helpful either and the stack trace in the Unified Logging Service didn’t really give me any more clues.

My Elements.xml file had two Modules specified. One for a web page and one for the web parts that were going to sit on the web page. I tinkered with the Elements.xml file and commented out the page module to see if that was the problem. Low and behold when I tried the activation this time the process completed successfully. Somewhere in the web page module there was a conflict!

<Module Name="WebPages" Path="" Url="" RootWebOnly="True">
 <File Url="MyPage.aspx" Type="Ghostable" IgnoreIfAlreadyExists="True">
 <Property Name="Title" Value="MyPage" />
 <NavBarPage Name="MyPage" ID="1003" Position="End" />

It turns out that the problem was the ID attribute value for the NavBarPage element. This feature was being inserted into a site with an existing entry in the navigation area called ‘MyPage’ with an ID of 1002. The solution was to got to the Top Link Bar option under the Site Settings and remove the unnecessary link.

Having done that and changed the ID value to match the existing value I was able to successfully activate the feature.

Redundant MOSS Features

Finding & removing SharePoint features.
I had been trying to upgrade an existing solution using STSADM as it contained some additional features. Unfortunately, the command was giving me the following error:
The solution can not be deployed.  Directory “<feature name>” associated with feature ‘351cc41f-19b9-48f2-8654-7f29da7b89b2’ in the solution is used by feature ‘5cb0e7cd-75ed-4faa-9cec-914b01338a45’ installed in the farm. All features must have unique directories to avoid overwriting files.
I needed a way to find out what this existing feature {5cb0e7cd-75ed-4faa-9cec-914b01338a45} was and where in the farm it was being used. After the usual search for enlightenment I found the FeatureAdmin tool to help me identify the location of this feature. In this case, it happened to be redundant feature that was not being used anywhere on the farm but had been left hanging around. The FeatureAdmin tool was able to uninstall the feature definition and allow me to perform the upgrade successfully.

I have persmission to do this…trust me!

Prompted for cedentials when accessing SharePoint library documents
At our office we have a number of MOSS 2007 document libraries. One of the issues I found with Vista is that it would constantly display the prompt for my credentials when I was trying to view any of these documents. I had already configured my Security Zones settings so that access to the document library was done through the Local Intranet zone including setting the automatic logon. Other people in the office using Windows XP were not experiencing the same issue.
After a few minutes surfing I came accross this Knowledge Base article that resolved my problem – http://support.microsoft.com/kb/943280 . The article explains the reasons for the problem so I won’t repeat it here however there are a couple of points worth highlighting;
  • If you have already installed Windows Vista SP1, which I did, then you do not need to download the hotfix, just apply the changes to the registry.
  • Once I had made the change to your registry I needed to reboot my machine in order for the change to be affective.

Needless to say, my issue was resolved and I am no longer getting prompted to provide my credentials when I access documents stored in our SharePoint document libraries.

Locale differences within WSS 2.0

‘The language is not supported on the server’ and SharePoint development.
I have recently been developing a C# Console Application to automate the upload process of existing documents from a folder structure into WSS 2.0. My development and testing had been going well especially considering this was my first taste of developing against SharePoint. When I ran my application on a test server the documents, and the relevant folder structures were created and uploaded successfully. The problems started to occur when I ran the application on the client’s server.
The application would not even create the initial site required to store the Shared Documents and just returned an error – The language is not supported on the server. Having been burned by so called ‘language’ issues before I first checked the Regional Settings for the server and they were identical to my test machine. Plan B – surf the net for a fellow techie who had encountered the same problem and solution. Although this error was well documented on the net it was more to do with the installation of SharePoint rather than developing against it. However, it did lead me down the righ path, namely then InstalledLanguages registry entry.
I tweaked my console application to display the list of sites within a SharePoint web and the associated Locale ID and it highlighted the reason for my error. On my test server the sites were configured with a Locale ID of 1033 (English – United States) but on the live server they were configured to use 3081 (English – Australia). The question was, how can I convince SharePoint to use the locale id of 3081.
The answer comes in two parts;
  1. first of all I updated the registry on the live server. The key HKEY_LOCAL_MACHINESOFTWAREMicrosoftShared ToolsWeb Server Extensions6.0InstalledLanguages already had a REG_SZ value for 1033 so I added a second one for 3081.
  2. The next task was to create the relevant folders in the SharePoint virtual directory for the site templates. To do this I made the following changes;
    • Make a copy of the C:Program FilesCommon FilesMicrosoft Sharedweb server extensions60TEMPLATE1033 folder including all its contents and rename it to 3081.
    • Make a copy of the C:Program FilesCommon FilesMicrosoft Sharedweb server extensions60TEMPLATEADMIN1033 folder including all it contents and rename it to 3081.
    • Make a copy of the C:Program FilesCommon FilesMicrosoft Sharedweb server extensions60TEMPLATELAYOUTS1033 folder including all of its contents and rename it to 3081.
  3. Restart IIS.

This now provides SharePoint with the template structure it needs to create new sites using the Locale ID of 3081. When I ran my Console Application this time the sites were created successfully and my Shared Documents folders now contained the uploaded files.