SharePoint 2013 Explorer

UPDATE: Newer version of the tool now available here.

Here is one of the first developer utilities specifically built for SharePoint 2013. It will let you peek and poke at the internals of your SharePoint 2013 site collections, either on-premises or in the cloud.

The tool is based on SharePoint Explorer 365, read this post for the full details of its origin, capabilities and usage instructions. The changes in this new version are as follows:

• Updated passive authentication code for Office 365 Preview as detailed in this post.
• Compiled against SharePoint 2013 versions of Microsoft.SharePoint.Client.dll and Microsoft.SharePoint.Client.Runtime.dll, which provide a range of additional objects, properties and methods compared to the 2010 versions (see below screenshots).
  Because of this, this version of the tool will not work against SharePoint 2010 site collections.
• Compiled against the .NET Framework 4.0, so this needs to be installed if you want to run the tool.

Here is the download, read my previous post on SharePoint Explorer 365 regarding disclaimers and such.

You can see the expanded capacity of the 2013 version of the Client Object Model by comparing screenshots of the tool compiled with 2013 assemblies with screenshots of the same tool compiled with the 2010 assemblies.

Site Collection objects and properties in 2010 Client OM assemblies

Site Collection objects and properties in 2013 Client OM assemblies

Methods available against the Site Collection in 2010 assemblies

Methods available against the Site Collection in 2013 assemblies

This expansion of Client OM capabilities in SharePoint 2013 is great news, especially for Office 365 developers. The screenshots above relate to site collections, but there are new capabilities for webs, lists, and other SharePoint objects as well. This tool, or a .NET reflection tool, provides great insights into these new capabilities.

Note that SharePoint 2013 is in Preview and is liable to change as it matures (this is especially true of the Online version), so the tool may stop working at any time. In the meantime, have fun with it!

Thanks again to Stefan Stanev for building such an easily extendible SharePoint utility and providing the source code to the SharePoint community!

How to Passively authenticate into SharePoint 2013 Online using the .NET Client OM

In my last post I mentioned that the Passive authentication method for the .NET Client Object Model into SharePoint Online (Office 365) as outlined in this MSDN code sample is not compatible with SharePoint Online Wave 15 preview.

It turns out that there is a slight difference in the HTTP responses returned by the Wave 15 version of SharePoint Online compared with the 2010 version. Some of the URLs returned appear in triplicate, separated by commas. Discarding the multiple copies of the URLs brings the code back into working order.

The MSDN sample code can work in the new version of SharePoint Online, once you edit the ExtraHeadersFromResponse method in the ClaimsWebAuth class like so:

        private bool ExtraHeadersFromResponse(WebResponse response, out string loginUrl, out Uri navigationEndUrl)
        {
            loginUrl = null;
            navigationEndUrl = null;

            try
            {
                // For some reason, SharePoint Online Wave 15 Preview seems to return these responses in triplicate, separated by commas
                // Let's just get the first one

                string returnUrl = response.Headers[Constants.CLAIM_HEADER_RETURN_URL];
                if (returnUrl != null && returnUrl.Contains(","))
                {
                    returnUrl = returnUrl.Substring(0, returnUrl.IndexOf(",", StringComparison.InvariantCultureIgnoreCase));
                }
                navigationEndUrl = new Uri(returnUrl);

                loginUrl = (response.Headers[Constants.CLAIM_HEADER_AUTH_REQUIRED]);
                if (loginUrl != null && loginUrl.Contains(","))
                {
                    loginUrl = loginUrl.Substring(0, loginUrl.IndexOf(",", StringComparison.InvariantCultureIgnoreCase));
                }

                return true;
            }
            catch
            {
                return false;
            }
        }

Once this change is made, the code works in both the current and the next versions of SharePoint Online.

SharePoint Online 2013 Preview: Programmatic Authentication

UPDATE: There is a solution to this issue described below, see this post.

As I'm sure you're all aware, SharePoint 2013 Preview (a.k.a. Wave 15) is now upon us!

I thought it would be a great time to confirm programmatic authentication into SharePoint Online, based on the Passive and Active authentication methods we have come to rely upon in the current 2010 based release of SharePoint Online (a component of Office 365).

The Passive technique requires the user running the code to interactively log in (or to have authenticated within the last 8 hours and still have an unexpired cookie available). This method is outlined here on MSDN and this was the basis of the SharePoint Online capable version of SharePoint Explorer.

Unfortunately this authentication method doesn't appear to work against the new version of SharePoint Online from my initial testing. Once the user is authenticated, the WebBrowser window that is created as part of the process looks like this:

What is interesting is that clicking the "GO BACK TO SITE" link (what's with the sudden Microsoft Metro obsession with ALL-CAPS?) actually brings up the SharePoint Preview site in the temporary WebBrowser object window. This makes me think that the approach can potentially work with a bit of Fiddling (pun intended)...

The Active authentication method described here appears to work just fine, thanks Wictor!

Note that you can create your own Preview tenancy of the upcoming version of SharePoint Online here. You need to go with an Enterprise tenancy as the other options won't grant you SharePoint Online. Have fun with it!

SharePoint Explorer 365

UPDATE: Newer version of the tool now available here.

Ever wanted to see what is happening under the UI in your SharePoint Online (Office 365) environment? Read on for a download link to a tool that may come in handy...

I recently came across Stefan Stanev's very useful SharePoint Explorer, which is a bit like the SharePoint Manager tool that many SharePoint developers would be familiar with. The key difference with SharePoint Explorer is that it uses the .NET Client Object Model to connect to SharePoint, so it can run on any machine with connectivity to your SharePoint environment!

The Client OM is available in SharePoint Online, but one major difference is the authentication system which I have been playing around with recently for some project work. It's not too difficult to shoe-horn the MSDN sample code for authenticating into SharePoint Online into the source code for SharePoint Explorer (which Stefan has graciously shared with the SharePoint community). Now we can get a quick and easy view of object properties which are generally hidden from view.

Disclaimer:
This tool is best used for examining the state of SharePoint objects and making quick development changes in non-production environments. As always, be careful! Although it is restricted by the boundaries of the Client OM, this tool has enough power to turn your site collection into a nasty state of affairs (e.g. if you ask it to delete your root web, it will comply and then your site will be completely broken). With this in mind:

• Don't log in with higher privileges than you absolutely need;
• Don't log in to production if you can avoid it;
• Don't make any updates (especially in production) if you can avoid it;
• Don't use it as a short cut for proper deployment methodologies; and
• Use at your own risk!

OK, so now you've gotten past the disclaimer, here's the download for the Office 365 version of SharePoint Explorer.

When you connect (see below), there is an option to specify whether you are connecting to a SharePoint Online environment. If you are, the remaining authentication details are ignored and the code provides you with a login screen into Office 365. If the current user has an active cookies from recently logging in to Office 365 in Internet Explorer, then the tool will reuse the cookie so no additional login is required.

See Stefan's blog post entry for detail on how the tool works once you're connected. Massive thanks to him  for making the SharePoint Explorer source code available!

Specifying to connect to a SharePoint Online site on Office 365

The login form you will use if you don't already have an active cookie available for the tool to reuse

The tool in action

Let me know how you go with the tool, I've found it quite handy to track down and delete orphaned hidden Taxonomy columns created by SharePoint whilst testing my content type provisioning feature. Much faster than having to write sandbox code or custom Client OM code!

SharePoint Saturday Perth - Customising SharePoint Online Resources

Hi all,

Here are the resources referenced in my SharePoint Saturday Perth presentation on Customising SharePoint Online:

SharePoint Online Restrictions:
http://msdn.microsoft.com/en-us/library/gg615454.aspx

Sandbox Logging:
http://spsl.codeplex.com 

Client Object Model Authentication:

http://www.wictorwilen.se/Post/How-to-do-active-authentication-to-Office-365-and-SharePoint-Online.aspx

Free 30-day trial Office 365 tenancy:

http://www.microsoft.com/en-us/office365/free-office365-trial.aspx

Office 365 Service Descriptions:

http://www.microsoft.com/download/en/details.aspx?id=13602

Office 365 Developer Training Course :

http://msdn.microsoft.com/en-us/hh181605

SharePoint Online Developer Resource Centre :

http://msdn.microsoft.com/en-us/sharepoint/gg153540.aspx

Thanks to Brian and all the SharePoint Saturday Perth sponsors, presenters and attendees!

Feature Stapling in SharePoint Online (Office 365)

I've been working with sandbox solutions lately and I've come across something rather unexpected: it looks like you can't use feature stapling (the FeatureSiteTemplateAssociation element) in the cloud.

I created a sandbox version of the branding solution I've used a few times in the past to apply a custom master page and some custom CSS to a site. The sandbox version of the solution contains a site collection scoped feature that staples a web scoped feature to a wide range of SharePoint site definitions. This works as expected in my on-premises development environment: when the site collection feature is active, newly created sites have the custom web feature already activated.

However, when I apply the exact same sandbox solution to my SharePoint Online tenancy, the feature stapling doesn't seem to apply. Everything else works except for the stapling. The only information I have been able to find is this link on the Office 365 community site where a Microsoft support team member seems to indicate that feature stapling isn't available in SharePoint Online.

So it seems that for now we'll need to find alternative ways to automatically customise newly created SharePoint Online sites. I'm interested to hear if anyone else has any more info on this or perhaps has found a way to get feature stapling working in Office 365.

Update:
I've just checked the site definition being used for my SharePoint Online site - I had a suspicion that perhaps Online uses slightly different site definitions because this would explain why the feature stapling wasn't being applied. However, the WebTemplate and WebTemplateId properties are both identical in my SharePoint Online site and my on-premises site. So this doesn't explain the difference in behaviour between the two environments.

I've also tried using the GLOBAL value for TemplateName which should staple to all site definitions (except where the AllowGlobalFeatureAssociations property is false), and I still don't see any feature stapling.

Why is my document forgetting its content type?

Background:
For our MOSS project we had a series of document libraries that used custom content types, each with its own document template. For ease of maintenance and administration, we placed all of these document templates into a common document library.

Issue:
Users would go to their document library, click the New dropdown and select the appropriate content type. This would open up the template in Word as expected. Users would then save their document and set the properties.

However, when users then navigated to the document library, they found that their document didn't retain the content type that they originally selected from the dropdown. The document had somehow 'converted' to the default content type for that library. Why?

Discussion:
The key is SharePoint's property promotion and demotion. All a document's properties including the name and ID of its content type are stored within the document as well as in the document library. You can see this by renaming a .docx file to a .zip file and examining the contents.

Whenever a document in a document library is modified, either via its contents or its document library properties, SharePoint detects this change and synchronises the properties. So, if the property value is changed in the document, SharePoint 'promotes' that change into the document library column to match, and if the document library column is changed, SharePoint 'demotes' that change into the document contents. This is most visible in the Document Information Panel or when your documents contain Quick Parts.

How is this relevant? Our template documents were all stored in a central document library, and when we created this initially we didn't allow content type management because it wasn't considered necessary. Hence the document library internally used only the SharePoint default Document content type (which has the ID 0x0101). So, the instant we placed our document templates into this library, SharePoint converted the documents from our custom content types into Document. It also updated the internal contents of these document templates - via property demotion - to reflect that fact.

When users created new documents from these templates and saved them into a document library, the internal information stored within the template was retained, and SharePoint recognised that the documents were actually of the Document content type. It then promoted that information into the document properties at the document library level, overriding the selection made by the user from the New dropdown! Because of the way our custom content types and libraries operated, our document libraries didn't have the Document content type enabled. SharePoint couldn't match the content types accurately and (fairly sensibly) just went with the default content type for the library.

Solution:
We needed a way to make sure that the content type information was always preserved for our custom content types, so we enabled content type management for the document library containing the templates. We then ensured that each template was an instance of the content type for which it was the template. Then, there was no conflicting content type information to confuse SharePoint and the entire process worked perfectly.

Summary:
The key is that if you're going to store content type templates in SharePoint, make them instances of their respective content type. This is easy enough but it has a few implications:

• It will be difficult to reliably reuse a template across multiple content types
• If you're reusing content types across multiple site collections, make sure your content type IDs match - the SP2010 content type hub is useful in this case

SharePoint's property promotion is a pretty amazing thing, but it can edit your documents in ways you're not expecting - I've even seen it conflict with custom event receivers! When troubleshooting unexpected document metadata issues, remember that the process is always there, synchronising silently in the shadows...