What’s wrong with SharePoint 2010 Incoming Links?

To help you manage links on your website, SharePoint 2010 ships with the Incoming Links functionality. According to its description it should allow you to view the list of pages linking to the current page. Using the Incoming Links report is very intuitive: you go to the Publishing Page for which you want to see the incoming links and click the Incoming Links button on the Ribbon. While it all sounds so simple, it really isn’t. Let me show you why.

In the following scenario I have a Press Release called PressRelease_0001.aspx in the Press Releases sub site and another page called Lorem-ipsum.aspx located under the root web. The Lorem ipsum page has a link to the press release.

So according to the description of the Incoming Links report, I should see the Lorem ipsum page in the list of incoming links. Unfortunately if you navigate to the list of Incoming Links for the PressRelease_0001.aspx page, you will see an empty list.

What the description doesn’t tell you is, that the standard Incoming Links report provided with SharePoint 2010 works only for links that come from the same site. If I create a link to the PressRelease_0001.aspx page from PressRelease_0002.aspx it will appear on the list of incoming links as expected.

As you can imagine, such report is pretty useless in probably every real-life WCM scenario. Luckily, just because it isn’t there out of the box, doesn’t mean it cannot be done. SharePoint 2010 is a highly extensible framework for delivering Web Content Management solutions and this is just one of many examples how you can use the extensibility capabilities of the SharePoint 2010 framework to make the CMS work for you.

Better Incoming Links report with Mavention Incoming Links

Mavention Incoming Links is a simple SharePoint 2010 Solution that solves the issue of the Incoming Links report displaying only local links. After installation the Mavention Incoming Links Site Collection Feature appears in your site. After you activate it you won’t see any changes in the User Interface: Mavention Incoming Links replaces the standard SharePoint 2010 Incoming Links report with one that displays incoming links from other sites as well.

Summary

SharePoint 2010 ships with a report that allows you to view Incoming Links for Publishing Pages. The shortcoming of that overview is that it shows only links coming from the same site where the given page is. Mavention Incoming Links solves that issue by overriding the report and including all incoming links. By replacing the standard report it full integrates with the existing experience and allows content editors to use the new report without any learning curve.

Download: Mavention Incoming Links (8KB, WSP)

The Microsoft Silverlight 4 and SharePoint 2010 Integration book covers the basics of developing Silverlight applications on the SharePoint 2010 platform. The book begins with a global overview of what Silverlight is and what integration capabilities provided with SharePoint 2010 are: all of this supported with some easy to follow samples. Through the next chapters the book discusses the integration capabilities in more detail and focuses on different pieces such as the Silverlight Object Model, Business Connectivity Services (BCS) and the SharePoint Data Services.

Although the book targets developers who have previous SharePoint experience it provides in-depth explanation of new capabilities of SharePoint 2010, so if you haven’t done that much with the newest version of SharePoint, you won’t feel lost. The detailed explanation of different pieces of the sample solutions makes it easy to learn from the examples and the clear chapter structure makes it possible to skip the pieces that you are already familiar with.

Because the book doesn’t cover the basics of SharePoint and Silverlight development, it isn’t really suited for beginner developers. Having understanding of how development on both platforms looks like is required before you start reading this book. On the other hand the Microsoft Silverlight 4 and SharePoint Integration book doesn’t cover more advanced topics such as decoupling the data layer from the UI or discussing different deployment capabilities for Silverlight applications in SharePoint 2010 and when to use which, what doesn’t make it a book for advanced developers. In fact it’s a book that provides an intermediate-level overview of how you could leverage Silverlight 4 to create RIAs on the SharePoint 2010 platform.

Microsoft Silverlight 4 and SharePoint 2010 Integration is an interesting and easy to read book that explains the new capabilities of SharePoint 2010 for creating Rich Internet Applications using Silverlight 4. It provides good overview of both SharePoint 2010 and Silverlight 4 and is a good starting point for exploring more advanced RIA topics. If you are interested in leveraging Silverlight for creating rich applications on the SharePoint 2010 platform but you haven’t done that much with Silverlight yet, it’s a book you should read.

Check out Microsoft Silverlight 4 and SharePoint 2010 Integration at Packt Publishing.

Earlier this year there was the SharePoint Connections 2010 conference that was the unofficial launch of Microsoft SharePoint 2010 in Europe and based on the great feedback that Microsoft and Penton Media got, they decided to organize a second SharePoint conference here in the Netherlands.

SharePoint 2010 has been on the market for a few months now and there is some great content that will be presented on the conference based on the real-life experience of the speakers. No matter if you are developer, IT-Pro or a customer who is just interested in SharePoint 2010, you will find some great content on the SharePoint Connections 2010 Autumn. Microsoft and Penton Media lined up for you some of the best speakers in the SharePoint community, like Andrew Connell, Richard Taylor, Spencer Harbar, Mirjam van Olst and Wouter van Vugt just to name a few.

Additionally, once again I have the honor of being at the Ask the Expert booth. Together with my colleague here at Mavention Robert Jaakke who is one of the few Microsoft Certified Masters (MCM) for SharePoint 2007 we will be there to answer all of your questions about the SharePoint platform, so don’t forget to drop by and say hi.

If you haven’t registered yet, go ahead and sign up for the SharePoint Connections 2010 Autumn, The Hague on 28 & 29 September. The agenda looks really impressive and I’m sure it’s going to be a great conference with a lot of great people from the SharePoint community. See you there!

What is Mavention Meta Fields?

Mavention Meta Fields is a SharePoint solution that allows you to easily add meta tags to Publishing Pages. If you haven’t included meta tags initially as a part of your information architecture or you’re looking for an easy way to add meta tags to Publishing Pages, Mavention Meta Fields is the right solution for you.

Configuring Mavention Meta Fields

Upon deployment Mavention Meta Fields install a Site Collection Feature called Mavention Meta Fields. All you have to do to use Mavention Meta Fields is to activate this single Feature. That’s it. You don’t have to do any changes to your Master Pages or Page Layouts to use Mavention Meta Fields.

In order to use Mavention Meta Fields with your existing Publishing Pages you have to add new columns to your existing Content Types. Those columns will store the contents of meta tags for Publishing Pages. There are two things that you have to consider while adding those columns. First of all the display name of the field determines the name of the meta tag that will be included in your page. Secondly, in order for the field to be picked up by Mavention Meta Fields as a meta tag field, it has to be added to the Publishing Meta Tags group. In my example I’ve added two Site Columns called description and keywords.

Once the columns are in place you have to add them to the Content Types. In this example I’ve added them to the out of the box available Welcome Page Content Type.

And that’s all. You can start using Mavention Meta Fields now.

Editing meta tags with Mavention Meta Fields

When you navigate to a Publishing Page you won’t see much difference. But as soon as you edit the page, the meta tags editor will appear on the right side of the page right under the Status Bar:

After you click the show page metadata link, the edit panel will slide down and you will be able to edit the values for your meta tags:

Once you’re done, save the changes. The meta tags editor will disappear again, but if you view the HTML source of the page you will notice two meta tags added with the values that you have just added using the meta tags editor:

Summary

Mavention Meta Fields is a great solution for managing meta tags for Publishing Pages. Because it doesn’t require you to do any changes to your Master Pages and Page Layouts it’s a great solution for adding meta data to your Publishing Pages even if you haven’t taken it into account while designing the website and its intuitive interface makes it really easy for the content editors to manage the meta tags. Depending on your requirements you might need to include some additional information in the meta tags. Using the Mavention Meta Fields solution you can easily add additional fields by including them in the Publishing Meta Tags groups.

Download: Mavention Meta Fields (31,8KB, WSP)

Mavention Replaceable Parameters Snippets is a collection of Visual Studio Code Snippets that contain every Replaceable Parameter available out of the box. After the installation they allow you to quickly choose the right token from a list:

Before you start

Before you install the Mavention Replaceable Parameters Snippets you have to create a folder where you will install the snippets. In fact you will need two folders: one for snippets that can be used in all XML files, like Element Manifests and Web Parts and one for HTML snippets that can be used in ASPX pages and User Controls (ASCX).

To create the folders start up Visual Studio 2010, and choose Tools > Code Snippets Manager from the menu:

In the Language box choose HTML and click the Add button. In the Select Folder dialog create new folder called HTML and inside it create another folder called SharePoint 2010. Click the Select button: the newly created SharePoint 2010 folder should appear in the tree view:

Next you have to do the same for the XML snippets:

Now you’re ready to install the Mavention Replaceable Parameters Snippets. Double click the .vsi file. On the first page of the wizard click the Next > button.

When prompted about no signature, ignore the warning by clicking the Yes button.

Next select all snippets and then select the SharePoint2010 folder in the Location window:

Next do the same for the XML snippets. If you don’t uncheck the My Xml Snippets folder under Microsoft Visual Studio Tools for Applications 2005 the Mavention Replaceable Parameters Snippets will be copied to two folders.

Once you’re ready click the Finish button to start the installation process.

Once finished, close the wizard and start Visual Studio. Open one of your SharePoint projects, open an SPI such as Web Part and try to insert one of the Replaceable Parameters. You can do this by either selecting Edit > IntelliSense > Insert Snippet… from the menu, selecting Insert Snippet… from the context menu or pressing CTRL+K, CTRL+X on the keyboard. In the list of available snippets you should be seeing SharePoint2010:

And that’s all! With Mavention Replaceable Parameters Snippet you will never have to think twice again about what the exact name of that token was.

Download: Mavention Replaceable Parameters Snippets (VSI, 19,3KB)

Important
After downloading the file verify if its extension is .vsi. Depending on your browser it might get changed to .zip. In that case rename the file and change its extension to .vsi to be able to install the Code Snippets automatically.

What is Mavention Virtual Pages?

Mavention Virtual Pages is a custom SharePoint 2010 Solution that allows you to publish the content of Publishing Pages in multiple locations on your site.

Upon deployment Mavention Virtual Pages installs a new Site Collection Feature called Mavention Virtual Pages.

Upon activation the Mavention Virtual Pages Feature will install a new Content Type called Virtual Page and will provision a sample Page Layout called Mavention Virtual Page. The idea here is that the Content Type ships with the basic publishing capabilities for Publishing Pages and additional field that allows you to select a Publishing Page that you want to display.

The Mavention Virtual Page Page Layout is a sample Page Layout that you can use for creating your own Page Layouts to support the reuse of pages in your site.

How Mavention Virtual Pages work

The working of Mavention Virtual Pages is very simple. When you look at the sample Page Layout you might not notice anything odd: it contains all the regular pieces that every Page Layout in SharePoint has. The only difference is that the sample Page Layout is attached to the Mavention.SharePoint.VirtualPages.VirtualPage class which makes creating virtual pages possible. So if you start creating your own Page Layouts for Virtual Pages this is one thing that you shouldn’t forget otherwise it will not work.

Using Mavention Virtual Pages: a step-by-step guide

To better illustrate you the working of Mavention Virtual Pages let’s follow a simple scenario where we will create a Publishing Page in one place on the site and will the publish the same page in a different site. This manual assumes that the Mavention Virtual Pages Solution has already been deployed and that the Mavention Virtual Pages Feature has been activated. In this case we will use the sample Mavention Virtual Page Page Layout shipped with the Mavention Virtual Pages Solution.

First, let’s create a Publishing Page somewhere on the site. For this purpose we will use the Article Left Page Layout available with the standard SharePoint Server 2010 Publishing Site. Also let’s include some sample content that we will reuse later on.

The next step is to reuse the page that we have just published. Let’s go to another place in the site and create a new Publishing Page.

Before you do this, you might want to ensure that you are allowed to use the Mavention Virtual Page Page Layout in your site. You can do this by navigating to Site Actions > Site Settings > Look and feel > Page layouts and site templates and see if the Mavention Virtual Page is on the list of Allowed Page Layouts.

After creating the page let’s change the Page Layout to Mavention Virtual Page:

The next step is to link the Virtual Page to the page that we created earlier. You can do this by specifying the link in the Linked Page field:

The last thing is to publish the Virtual Page. After that you should see the contents of the page that you have linked the Virtual Page to.

Notice that the Page Title in the title bar, in the page and in the breadcrumbs contains the title of the Virtual Page, while the content of the page is being retrieved from the linked page.

Now let’s see how Mavention Virtual Pages deal with changes. Let’s go to the original page and change something in its contents.

If you navigate to the Virtual Page you should see the refreshed contents of the Publishing Page.

Benefits of using Mavention Virtual Pages

Mavention Virtual Pages is a great solution if you need republishing capabilities in your Web Content Management solution based on the SharePoint Server 2010 platform.

Mavention Virtual Pages works using a simple concept and contains just a few lines of custom code of which all is within the supported public API of SharePoint Server 2010. This makes the Solution robust and reliable. Mavention Virtual Pages use standard controls shipped with SharePoint to render the content so there is no data loss while using Virtual Pages.

Although retrieving the data from linked Publishing Pages happens dynamically, there is no performance penalty when combined with caching and all the content of the Publishing Page linked to a Virtual Page is being retrieved from cache just as it was a part of the Virtual Page itself.

Mavention Virtual Pages is a great Solution if you have a lot of similar pages that you want to publish in multiple locations on your website. As it’s based on Page Layouts it allows you to quickly republish existing pages in other locations. Additionally as it works with anonymous users, it makes a great Solution for your Internet-facing website.

Future considerations

This is the first release of Mavention Virtual Pages. While it successfully covers the most common scenario’s there are few things that you should consider before using it in your solution.

Web Parts in content

SharePoint 2010 allows you to include Web Parts in content. And although from the content editor point of view seems like the Web Parts are a part of content that is being retrieved by Virtual Pages, they actually live outside of the content. While rendering the content, SharePoint replaces markers in text with the Web Parts that physically live in a hidden Web Part Zone. This is why at this moment Mavention Virtual Pages don’t support Web Parts in content.

Virtual Pages are Page Layout-based

Mavention Virtual Pages are based on Page Layouts to render the contents of linked pages. While it gives you a consistent experience from the development point of view, it might seem limiting from the content editor point of view. To link to multiple types of pages, like press release or event, you need multiple Page Layouts linked to the Virtual Page Content Type. Because a press release will very likely contain different set of information than an event, you will have to create two separate Page Layouts to display the information.

Usage reporting

Intensively using Virtual Pages might turn into a nightmare from the content management point of view. While it gives you to great ability of reusing content that is already there in your website, it doesn’t provide you with an overview of which page has been linked to and from where. So when you delete a page published in one page, you might break something in another without even knowing it. Providing an overview of pages that are reused somewhere else in the site is definitely a great idea for a future improvement.

Deployment

As you might know by now, the Publishing capabilities of SharePoint Server 2010 are not yet available in the Sandbox. This mean that you need your IT department to get this deployed. Hopefully this is something that we will see changing in the future releases of SharePoint, but at this moment this Solution is available only as a Farm Solution.

Download: Mavention Virtual Pages (WSP, 7KB)

Updated Aug 30, 2010: the code sample of Step 2 has been updated. There was an issue that was causing SharePoint throw exception while trying to edit Variation Labels that were created programmatically.

Programmatically provisioning Variations

The process of provisioning Variations consists of three steps:

1. Configuring Variation Settings (Site Actions > Site Settings >Variations)
2. Configuring Variation Labels (Site Actions > Site Settings > Variation labels)
3. Creating Variation Hierarchies (Site Actions > Site Settings > Variation labels > Create Hierarchies)

So in order to programmatically provision Variations in a repeatable fashion, you have to cover all three steps in your code.

Before you read further keep in mind that there is still no public API for creating Variations available in SharePoint 2010. As you will notice earlier, the code examples I show in this article, use internal properties. And although you don’t have to use reflection anymore this approach is still unsupported.

Step 1: Configuring Variation Settings

Configuring Variation Settings can be done using the Site Actions > Site Settings > Variation page.

As you can see this page hasn’t really changed since MOSS 2007 and contains the same settings as previously what makes it easy for us to write the code for:

private static void ConfigureVariationsSettings(SPWeb rootWeb)
{
    Guid varRelationshipsListId = new Guid(rootWeb.AllProperties["_VarRelationshipsListId"] as string);
    SPList varRelationshipsList = rootWeb.Lists[varRelationshipsListId];
    SPFolder rootFolder = varRelationshipsList.RootFolder;
    // Automatic creation
    rootFolder.Properties["EnableAutoSpawnPropertyName"] = "true";
    // Recreate Deleted Target Page; set to false to enable recreation
    rootFolder.Properties["AutoSpawnStopAfterDeletePropertyName"] = "false";
    // Update Target Page Web Parts
    rootFolder.Properties["UpdateWebPartsPropertyName"] = "true";
    // Resources
    rootFolder.Properties["CopyResourcesPropertyName"] = "true";
    // Notification
    rootFolder.Properties["SendNotificationEmailPropertyName"] = "false";
    rootFolder.Properties["SourceVarRootWebTemplatePropertyName"] = "CMSPUBLISHING#0";
    rootFolder.Update();

    SPListItem item = null;
    if (varRelationshipsList.Items.Count > 0)
    {
        item = varRelationshipsList.Items[0];
    }
    else
    {
        item = varRelationshipsList.Items.Add();
        item["GroupGuid"] = new Guid("F68A02C8-2DCC-4894-B67D-BBAED5A066F9");
    }

    item["Deleted"] = false;
    item["ObjectID"] = rootWeb.ServerRelativeUrl;
    item["ParentAreaID"] = String.Empty;
    item.Update();
}

The Variations Setting are being stored in a hidden List in the Root Web. Because this List is provisioned dynamically, you can get a reference to it by getting the value of the _VarRelationshipsListId property. For every setting from the Variations Settings page there is a corresponding property in the Property Bag of the Root Folder of the hidden List. Probably the most confusing setting here is the Recreate Deleted Target Page setting, which has to be set to false in order to enable the recreation.

Among the properties you can also find the SourceVarRootWebTemplatePropertyName property which contains the name of the Site Definition used to provision new Variation Hierarchies. This corresponds to the Source Variation settings while configuring Variation Labels.

Next to the settings from the Variations Settings page, the hidden List contains one List Item which contains the configuration of the Variation Home setting.

Using the code snippet above you can provision the Variation Settings in a repeatable way.

Step 2: Configuring Variation Labels

Configuring Variation Labels in SharePoint Server 2010 is exactly the same as in MOSS 2007. You need to create a Variation Label for each variation in your site and once you’re done, you have to create the Variation Hierarchies.

Variation Labels can be provisioned using the following code snippet:

private static VariationLabel[] labels = {
    new VariationLabel
    {
        Title = "nl-nl",
        FlagControlDisplayName = "Nederlands",
        Language = "nl-NL",
        Locale = 1043,
        HierarchyCreationMode = CreationMode.PublishingSitesAndAllPages,
        IsSource = true
    },
    new VariationLabel
    {
        Title = "en-us",
        FlagControlDisplayName = "English",
        Language = "en-US",
        Locale = 1033,
        HierarchyCreationMode = CreationMode.PublishingSitesAndAllPages
    }
};

private static void CreateVariations(SPWeb rootWeb)
{
    Guid varListId = new Guid(rootWeb.AllProperties["_VarLabelsListId"] as string);
    SPList varList = rootWeb.Lists[varListId];

    foreach (VariationLabel label in labels)
    {
        SPListItem item = varList.Items.Add();
        item[SPBuiltInFieldId.Title] = label.Title;
        item["Description"] = label.Description;
        item["Flag Control Display Name"] = label.FlagControlDisplayName;
        item["Language"] = label.Language;
        item["Locale"] = label.Locale.ToString();
        item["Hierarchy Creation Mode"] = label.HierarchyCreationMode;
        item["Is Source"] = label.IsSource.ToString();
        item["Hierarchy Is Created"] = false;
        item.Update();
    }
}

Similar to MOSS 2007, configuration of each Variation Label is stored as a List Item in a hidden list (different than the Variations Settings), so for every Variation Label you need to in fact create a List Item and fill it with the required information.

Running the code snippet above will create two Variation Labels in your Site Collection:

Step 3: Creating Variation Hierarchies

This is the piece that has changed in SharePoint Server 2010 making creating Variation Hierarchies more stable and reliable. In MOSS 2007 Variation Hierarchies were created using a Long Running Operation in the w3wp.exe process. There were scenario’s when, if something went wrong, you had to perform IIS reset. As you can expect this would only break the whole process even further. In SharePoint Server 2010 creating Variation Hierarchies has been moved to a Timer Job which runs separately from the w3wp.exe process, which makes the whole thing more stable.

As the approach of creating Variation Hierarchies changed, the code that we used before became useless. The great thing about the new approach is, that because it relies on a Timer Job, it is easier to start and to control. You can programmatically create Variation Hierarchies using the following code snippet:

private static void CreateHierarchies(SPSite site, SPWeb rootWeb)
{
    site.AddWorkItem(Guid.Empty, DateTime.Now.ToUniversalTime(), new Guid("e7496be8-22a8-45bf-843a-d1bd83aceb25"), rootWeb.ID, site.ID, 1, false, Guid.Empty, Guid.Empty, rootWeb.CurrentUser.ID, null, String.Empty, Guid.Empty, false);
    SPWebApplication webApplication = site.WebApplication;
    SPJobDefinition variationsJob = (from SPJobDefinition job in
                                     webApplication.JobDefinitions
                                     where job.Name == "VariationsCreateHierarchies"
                                     select job).FirstOrDefault();

    if (variationsJob != null)
    {
        DateTime startTime = DateTime.Now.ToUniversalTime();
        variationsJob.RunNow();

        // wait until the job is finished
        while ((from SPJobHistory j in webApplication.JobHistoryEntries where j.JobDefinitionId == variationsJob.Id && j.StartTime > startTime select j).Any() == false)
        {
            Thread.Sleep(100);
        }
    }
}

The first thing that needs to be done is to add a work item. This is needed as the Timer Job responsible for creating Variation Hierarchies is a work-item timer job. Once it’s in place, you can start the job. To do that you need a reference to the Timer Job which is scoped to Web Application.

In the code sample above I use a pause routine that waits until the job finishes. This is important in scenarios when provisioning Variation Hierarchies is not the last step and there are some other steps in the queue which depend on the Variations. You are free to skip this part if you don’t need it in your scenario.

And that’s it. After running this last piece of code the Variation Hierarchies have been created:

Summary

Variations are a great mechanism for delivering multilingual solutions. Provisioning Variations is a part of the configuration process and you should try to include it in your structure and repeatable deployment process. Although Variations in SharePoint Server 2010 have been improved and made more reliable, there is still no public API available for programmatically configuring and provisioning Variations. Although you don’t need to use reflection anymore in SharePoint Server 2010, you have to use hidden properties, which Variations depend upon, what makes any solution for programmatically provisioning Variations unsupported.

Determining the Claims Authentication Type used for logging in is very simple using the Claims API provided with SharePoint 2010 and can be done using the following code snippet:

string info = null;
SPClaimProviderManager mgr = SPClaimProviderManager.Local;
if (mgr != null)
{
    SPClaim userLogonNameClaim = mgr.DecodeClaim(SPContext.Current.Web.CurrentUser.LoginName);
    SPOriginalIssuerType issuerType = SPOriginalIssuers.GetIssuerType(userLogonNameClaim.OriginalIssuer);
    string issuerIdentifier = SPOriginalIssuers.GetIssuerIdentifier(userLogonNameClaim.OriginalIssuer);

    info = String.Format("type: {0}<br />identifier: {1}", issuerType, issuerIdentifier);
}

First you will need a reference to the current Claims Provider Manager (2). The next step is to turn the login name of the currently logged in user into a claim. This can be done using the DecodeClaim method (5). The type and the ID of the Claims Authentication Type used for authenticating the user is stored in the SPClaim.OriginalIssuer property. You can retrieve the type of the claim using the GetIssuerType method (6) and the identifier using the GetIssuerIdentifier method (7). Let’s have a look at a sample case.

Imagine you were logged in with a Forms Based Authentication user called myuser. The FBA Membership Provider registered with the Web Application is called myprovider. So after logging in the login name of the user would be something similar to: i:0#.f|myprovider|myuser. After using the code snippet above the issuerType would be set to SPOriginalIssuerType.Forms and the issuerIdentifier would contain the id of the FBA Membership Provider – myprovider.

In another scenario, when you would be logged in using a Windows account, using the same code snippet as presented above would return SPOriginalIssuerType.Windows for the type and an empty string for the identifier.

And that’s all you need to know in order to determine which Claims Authentication Type has been used for authenticating the user. Being able to distinct users using different authentication types can help you target and/or secure content or functionality in your solution.

It turns out that retrieving the user name from its claims representation is pretty straight forward and can be done using the following code snippet:

string userName = null;
SPClaimProviderManager mgr = SPClaimProviderManager.Local;
if (mgr != null)
{
    userName = mgr.DecodeClaim(SPContext.Current.Web.CurrentUser.LoginName).Value;
}

First we retrieve a reference to the Claims Provider Manager configured with the current Web Application. Then, using the DecodeClaim(string) method, we convert the string into SPClaim and retrieve its value, which contains the login name of the current user.

So, assuming you were logged in with the myuser account and the value of the SPContext.Current.Web.CurrentUser.LoginName property was something similar to i:0#.f|myprovider|myuser, calling the code snippet above would return myuser.

Claims back and forth

In some scenario’s you might want to do the exact opposite: you might be starting off with a login name and will need to turn it over into the claims-based name. Just like in the previous scenario this can be easily done using the SPClaimProviderManager:

string userName = null;
SPClaimProviderManager mgr = SPClaimProviderManager.Local;
if (mgr != null)
{
    SPClaim claim = new SPClaim(SPClaimTypes.UserLogonName, "myuser", "http://www.w3.org/2001/XMLSchema#string", SPOriginalIssuers.Format(SPOriginalIssuerType.Forms, "myprovider"));
    userName = mgr.EncodeClaim(claim);
}

Just as in the previous example we start off by getting a reference to the current Claims Provider Manager. The next step is to create a claim based on the login name of the current user. You can do this using the constructor of the SPClaim class. As the type you have to provide SPClaimTypes.UserLogonName, as the value – the login name of the user, as the value type, the XML type for string and finally, as the originalIssuer the name of your Membership Provider. In this sample I used a custom Forms Based Membership Provider but you might need some other type depending on your scenario.

In our example, if you needed the claims representation for the the myuser claims account, calling the above code snippet would return i:0#.f|myprovider|myuser.

And that’s it: converting the login names to claims and vice versa is that simple. And using the DecodeClaim and EncodeClaim methods makes it more reliable than parsing or building the strings manually.

The solution

Let’s start with looking at a working code sample that allows you to create a Site Collection using a Web Template:

SPWebApplication webApp = SPWebApplication.Lookup(new Uri("http://win2008"));
using (SPSite site = webApp.Sites.Add("/sites/site1", "SharePoint", null, 1033, null, "administrator", "Administrator", "admin@contoso.com"))
{
    SPWeb rootWeb = site.RootWeb;

    // Get Solutions Gallery
    SPDocumentLibrary solutions = (SPDocumentLibrary)site.GetCatalog(SPListTemplateType.SolutionCatalog);
    // Upload Solution File with the Web Template
    SPFile solutionFile = solutions.RootFolder.Files.Add("test.wsp", File.ReadAllBytes(@"..\..\test.wsp"));
    // Activate Solution
    SPUserSolution solution = site.Solutions.Add(solutionFile.Item.ID);
    // Activate Features
    Guid solutionId = solution.SolutionId;

    // Activate Site Collection Features
    SPFeatureDefinitionCollection siteFeatures = site.FeatureDefinitions;
    var features = from SPFeatureDefinition f
                   in siteFeatures
                   where f.SolutionId.Equals(solutionId) && f.Scope == SPFeatureScope.Site
                   select f;
    foreach (SPFeatureDefinition feature in features)
    {
        site.Features.Add(feature.Id, false, SPFeatureDefinitionScope.Site);
    }

    // Get Web Template
    SPWebTemplateCollection webTemplates = site.RootWeb.GetAvailableWebTemplates(1033);
    SPWebTemplate webTemplate = (from SPWebTemplate t
                                 in webTemplates
                                 where t.Title == "test"
                                 select t).FirstOrDefault();
    if (webTemplate != null)
    {
        site.RootWeb.ApplyWebTemplate(webTemplate.Name);
    }
}

In order to create a new Site Collection you need a reference to the Web Application (1). You can create a new Site Collection by calling the SPSiteCollection.Add method (2). The important part of creating a Site Collection that uses a Web Template is, that you have to create a blank Site Collection at first and apply the template later. Todd discussed this in detail in his post.

After you create an empty Site Collection you can proceed with uploading the WSP file that contains the Web Template. You can do this by retrieving the reference of the Solutions Gallery (7) and adding the file to the Root Folder (9). While adding the file you need to store the reference to the SPFile object. Later on you will be needing the ID of the created List Item in order to activate the Sandboxed Solution.

The next step is to activate the Sandboxed Solution. You can do this by calling the SPUserSolutionCollection.Add method passing the ID of the solution file stored earlier (11). Important difference while activating a Sandboxed Solution programmatically and using the web UI is, that when using code no Features are getting activated. So in order to be able to use your Web Template you need to activate the Site Collection Features from the Sandboxed Solution.

In order to activate the Site Collection Features from the Sandboxed Solution you need the Solution ID (13). Using this ID you can find out which Features are a part of the Sandboxed Solution and should be activated. You can easily retrieve the Features using LINQ (16-20). The things that you have to check for are the Solution ID and Feature’s Scope (19): only Site Collection scoped Features must be activated. Site scoped Features are getting activated automatically by the Web Template itself when applied to the Site. If you activate Site scoped Features you will get error while applying the Web Template to your Site. While activating the Features it’s important to use the Add(Guid, bool, SPFeatureDefinitionScope) overload (23). By setting the third parameter to SPFeatureDefinitionScope.Site you let SharePoint know that the Feature is a part of a Sandboxed Solution. If you use a different overload or pass a different value you will get an exception during the Feature activation process.

The next step is to retrieve the Web Template that you want to apply to your empty Site Collection. You can do this by searching the list of available Web Templates (27) for a Web Template with the name provided while saving the Site as Template (test in this example; 30).

The last step is to apply the Web Template to the Site Collection. While using Web Templates you have to use the SPWeb.ApplyWebTemplate(string) overload (34). Web Templates are represented in the SharePoint API using the SPFeatureWebTemplate class which is internal and cannot be used in your code. By providing the name of the Web Template instead, you let SharePoint find the right Web Template for you. If you try to use the SPWeb.ApplyWebTemplate(SPWebTemplate) overload you will end up with a broken Site.

And that’s it. Using the code above allows you to programmatically create Sites and Site Collections based on Web Templates.