SharePoint Client Object Model: Adding a Site Column only if it does not already exist

Before creating a new Site Column, you should make sure that the column doesn't already exist. At the very least, make sure that the ID you are using isn't already taken. The sample below uses the FindField method from a previous post:

public static Field EnsureField(this ClientContext clientContext, Web web, Guid id, string name, string schema)
{
	var field = FindField(clientContext, web, f => f.Id == id);
	if (field != null)
		return field;

	var newField = web.Fields.AddFieldAsXml(schema, false,
		AddFieldOptions.AddToNoContentType | AddFieldOptions.AddFieldInternalNameHint);
	clientContext.ExecuteQuery();
	return newField;
}

SharePoint Client Object Model: Verifying if a Field is part of a Content Type

Before adding a field to a ContentType, it is important to check that the field is not already part of the Content Type. Here's an extension method to ClientContext that does just that:

public static bool ExistInContentType( this ClientContext clientContext, ContentType contentType, Field field)
{
	var fieldLinks = contentType.FieldLinks;
	var existingFields = clientContext.LoadQuery(fieldLinks.Where(fl => fl.Id == field.Id));
	clientContext.ExecuteQuery();
	var existingField = existingFields.FirstOrDefault();
	if (existingField != null)
		return true;
	return false;
}

SharePoint Client Object Model: Finding a field in a list

When working with the SharePoint Client Object Model, it is useful to find a field in a list, or a site column in the web. Below are some extension methods to ClientContext, to facilitate these:

public static class FieldClientContextExtensions
{
    public static Field FindField(this ClientContext clientContext, List list,                                       
        Expression<Func<Field, bool>> predicate)
    {
        var webFields = list.Fields;
        var matchingFields = clientContext.LoadQuery(webFields.Where(predicate));
        clientContext.ExecuteQuery();

        Field field = matchingFields.FirstOrDefault();
        return field;
    }

    public static Field FindField(this ClientContext clientContext, Web web, Expression<Func<Field, bool>> predicate)
    {
        var webFields = web.Fields;
        var allFields = web.AvailableFields;
        var matchingWebFields = clientContext.LoadQuery(webFields.Where(predicate));
        var matchingAllFields = clientContext.LoadQuery(allFields.Where(predicate));

        clientContext.ExecuteQuery();
        Field field = matchingWebFields.FirstOrDefault() ?? matchingAllFields.FirstOrDefault();
        return field;
    }
}

SharePoint Lists: Grouping/Paging by first letter

A very interesting blog entry, Alphabetical Paging on a SharePoint List View, by Tom Clarkson, talks about grouping/paging items in a SharePoint list based on their first letter. If you are just looking for the formula needed to create a calculated column that contains the first letter of the item's Title, here it is:

=IF(ISNUMBER(VALUE(LEFT(Title,1))), "0", LEFT(Title,1))

SharePoint 2007 Web Folders

I've been working with SharePoint 2007 for so long now on my office desktop and laptop, that it seems that I don't remember some of the SharePoint 2007 requirements. Working on a fresh virtual machine that has WSS 3.0 installed and running, I've tries to open a Pages Library as a Web Folder. The result was a nice error message telling me "Your client does not support opening this list with Windows Explorer." This seemed a bit strange, since I'm working on the SharePoint server itself, which is a fully updated Windows Server 2003 (all patch and updates installed), and I'm browsing using Internet Explorer 7 (again, fully updated). After googling a bit, it seems the resolution was hidden in a forum with a link on page 2 of Google. The topic forwarded me to the following Microsoft page: Software Update for Web Folders (KB907306) I'm not sure if I should say that this update should come as part of the Windows Update or not, but I'm sure glad I've found this!

Microsoft SharePoint Products and Technologies Team Blog : Don't miss the announcements by Bill Gates to kick off the SharePoint Conference!

From "The official blog of the SharePoint Product Group" come this entry: Microsoft SharePoint Products and Technologies Team Blog : Don't miss the announcements by Bill Gates to kick off the SharePoint Conference!

You can come and meet some of my colleagues at the Microsoft Office SharePoint Conference 2008, at the Tzunami booth.

Don't name the URL for a sub-site 'CON' in MOSS 2007 - mindykelly's blog

Now, I'm not the best person to speak about documentation and openness is code and products, but every now and then I find myself raising an eyebrow about someone else's behavior: Don't name the URL for a sub-site 'CON' in MOSS 2007 - mindykelly's blog I don't complain that Microsoft don't allow the "CON" as the URL of a WSS/MOSS site. But people, how about making this a public knowledge. How about putting up a one-stop repository for all SharePoint limitation and restrictions? Among the many sites that Microsoft pops-up every other week, I'd love to see a site that centralize all the information about naming convention and limitations in SharePoint. Starting from the list of invalid characters for any type of items, list of "illegal" endings (_files, -files, etc), invalid names and so on...

SharePoint Associated groups

When you create a new sub-site in SharePoint, and choose the "Use Unique Permissions" option, three groups are created at the site-collection level: Owners, Members & Visitors. These groups are "associated" to the sub-site that you've just created.

But what does "associated" actually mean?

First, I misled you a bit - the names of the groups are actually SiteName Owners, SiteName Members & SiteName Visitors (where SiteName is the name of the sub-site you're creating).

Next they all have a nice link in their description, directing you to the sub-site.

More interesting, those three groups get some permissions on the sub-site.

The less obvious "associations" are the fact that those groups will appear in the Quick Launch area when you go to the "People and Groups" section of the site. Also, if you delete the sub-site, the groups will be removed from the site-collection.

Lastly, when you add a user to the site, you can either assign the user an explicit permission level, or you can add her to onw of the associated groups of the site.

That's quite a lot of meaning for a single word. Let look a bit deeper into each meaning:

Title & Description: This is just some basic naming policy used by SharePoint. The SiteName is validated, the group type is appended, the description is generated with a link. Nothing fancy here.

Permissions: The permissions are obtained by assigning permission levels to each group. Again, nothing too interesting.

Quick Launch: The list of groups that appear in the Quick Launch is retained in the AssociatedGroups property of the SPWeb. This list can also be updated by modifying the vti_associategroups key in the AllProperties property of SPWeb. Setting a group as the AssociatedMemberGroup, AssociatedVisitorGroup or AssociatedOwnerGroup automatically adds the group to the list of AssociatedGroups. These properties can be also updated by modifying the vti_associatemembergroup, vti_associatevisitorgroup & vti_associateownergroup keys in the AllProperties property of SPWeb. These three properties are also reflected in the "Set up Groups" page of the sub-site.

Auto deletion: This issue is a bit more complex. When using the SharePoint UI, or when calling CreateDefaultSharePointGroups methods of SPWeb, this behavior is implemented automatically. However, creating a group, and even associating it with a site, doesn't reproduce it. Only after using Lutz Roeder's .Net Reflector, and examining the CreateDefaultSharePointGroups method, I've found that you need to add the group's ID to the vti_createdassociategroups key in AllProperties.

Adding Users: When adding a user to a sub-site, only the groups listed in AssociatedGroups are listed as possible groups for the new user.

MOSS Documents Libraries naming policy

When you create a new Documents Library in MOSS, you are asked to provide a title for that Library. The provided title will be later used to define the internal name of the Library, as well as its URL. This is where the problems start. It only makes sense that MOSS allows the user to enter any value for the Library's title. However, there are a lot of limitations on internal names, and even more on URLs. This result in MOSS doing some kind of encoding/validation on the title. The result might range from having the name exactly the same as the title, to the name being completely different and unrelated. After some digging, I came up with the following logic:

For each char:
  if char is valid
    add it to URL
  if char is invalid
    if URL already ends with '_' (underscore)
      don't do anything
    else
      add '_' (underscore)

Strip '_' from beginning and end of URL
If URL is empty
replace URL with a legal DocLibXXX value where XXX is a number

Invalid characters are the following:

1. Any character bellow 0x20
2. Any of the following characters: ~!@#$%^&*{}[]-=+\:"'<>,?/.
3. Any character that takes more than 1 byte (Unicode and such)

Comparison between the Deployer and another migration product

Jingmei Li, a Microsoft employee, did a comparison on her blog between the Tzunami Deployer 2.01, and DocAve 4.1 Migrator.

Scot Hillier's "Microsoft SharePoint: Building Office 2007 Solutions in C# 2005"

Scot Hillier, on of the gurus of Microsoft SharePoint, just shipped his new book about Sharepoint solutions, entitles "Microsoft SharePoint: Building Office 2007 Solutions in C# 2005". As with the rest of Scot's book, this is definetly a must-read for all SharePoint administrators and developers. Scot is an independent consultant focused on SharePoint, the Microsoft Office System, and .NET technologies. Scot has authored eight books on Microsoft technologies over the last ten years, as well as numerous articles appearing in magazines and online.