Archive

Archive for March, 2009

Tip for custom Quick Launch Navigation

March 11, 2009 Leave a comment

When creating custom headings within the Quick Launch navigation, whether using the object model or a site definition, always ensure that there is a target URL for each navigation element otherwise the custom heading will be displayed as highlighted.

By way of example, the Microsoft SharePoint Guidance uses the following code to create a custom heading called ‘Dashboards’ in the Quick Launch navigation:

groupNode = new SPNavigationNode("Dashboards", String.Empty);
web.Navigation.QuickLaunch.AddAsFirst(groupNode);

Note that there is no target for this navigation heading, instead String.Empty is being passed in. This results in the ‘Dashboards’ being highlighted within Quick Launch regardless of the actual mouse pointer focus:

Highlighted heading within Quick Launch

Sometimes, as in the case above, there isn’t a obvious target for the heading. However it would still be better to supply a URL rather than leave the target blank as thus avoid the heading being permanently highlighted. To do this, use some code similar to the following:

groupNode = new SPNavigationNode("Dashboards", web.Url, true);

Note the use of the third parameter that specifies that the link is an external node, this is required to make use of the SPWeb.Url property which returns the absolute URL of the web site.

Advertisements

SharePoint Guidance Package and VSeWSS 1.3 CTP

March 10, 2009 Leave a comment

Update

This appears to be fixed with the February release of the VSeWSS 1.3 CTP. Download it here.

A quick tip to get the Microsoft patterns & practices SharePoint Guidance to deploy correctly when using VSeWSS 1.3 January CTP, based upon the November 2008 release of the SharePoint Guidance package…

Using the instructions given here, when attempting to deploy the Contoso.TrainingManagement project the following error may be encountered:

The feature name Contoso.TrainingManagementSiteElements already exists in the current Solution. You need to rename the feature before deployment can succeed.

This problem arises because the TrainingManagementSiteElements feature doesn’t yet exist in the Contoso.TrainingManagement/pkg folder and, when VSeWSS creates the new feature.xml for this, it incorrectly assigns a new Guid to the feature id. Instead the TrainingManagementSiteElements feature should use the same id as specified in feature element in the solution.xml file:

  
    <feature id="4352f7c6-0036-419e-9502-4680b318972c">
      <featureElements>
        <featureElement id="9d3e4ec3-da66-496c-b159-12d06681c09a" 
           name="Contoso.TrainingManagementSiteElements" />
      </featureElements>
    </feature>

To correct this issue, edit the feature.xml file in the Contoso.TrainingManagement/pkg/TrainingManagementSiteElements folder and replace the id with the feature id from the solution.xml file, e.g. “4352f7c6-0036-419e-9502-4680b318972c” based upon the example above.

Associated Groups for a SharePoint site

March 5, 2009 1 comment

When setting the group associations for a SharePoint site using the object model, don’t use the obvious method of using the AssociatedMemberGroup and similar properties:

web.AssociatedMemberGroup = group;

Instead use the property bag of the SPWeb object to set each association:

web.Properties["vti_associatemembergroup"] = group.ID.ToString();

and ensure that the property bag is updated after setting these values:

web.Properties.Update();

Enter the weirdness

Why not use the SPWeb.AssociatedMemberGroup property? Simply because it appears not to work.

In a recent project, setting each of the AssociatedMemberGroup, AssociatedOwnerGroup and AssociatedVisitorGroup properties resulted in only the Owner and Visitor Groups actually retaining their values. Debugging the code showed each property being correctly set – and the read-only property AssociatedGroups also being updated – only for the associations to be lost once the owning SPWeb object went out of scope.

A quick search on this topic revealed that several blog posts contained code that set the equivalent property bag values rather than using the public properties of the SPWeb class. Alas none of the posters actually explained why they’d taken this course of action.