The road to RTM is littered with dead features…

Now that the Office 15 bandwagon has started it’s journey, information is bound to crop up here and there. Can you trust this information? Maybe. I would not be making any life altering decisions based on it until just before the SharePoint Conference in November. At that point in time, the relase should hopefully be so close that they have locked down the feature set. Until then, anything is up for grabs, or in this case, ends up on the cutting room floor. The only thing we can be fairly sure about is that the stuff that worked in SharePoint 2010 will most likely be around in SharePoint 15.

One of the central features of SharePoint is the user profile system; this allows you to import information from Active Directory and present it through the My Site feature. In SharePoint 2007 it was trivial to add new user profile properties. When SharePoint 2010 was launched, the API’s had changed considerably. Now it looks like an overengineered grapefruit. The reason for this can be found in Central Administration; Organization profiles. It looks like the idea was to introduce profiles for Organizations that leveraged the same property structure as user profiles. The only reference to Organization profiles is in Central Administration, nowhere else. By the look of things, this was something they were working on, and had to cut in order to ship in time. If this will be completed in SharePoint 15 or completely removed again is anybody’s guess.

The fact that something exists in a version doesn’t guarantee that it will continue in the next. The first version of Windows Home Server had a feature called Drive Extender; this allowed you to merge a lot of physical disks into one big logical one. In the latest version of WHS, this feature is no longer present. Apparently it was causing some issues with some other functionality, so they decided to cut it. A lot of people were not happy.

Late last year I attended a course on Duet Enterprise; an integration product between SharePoint and SAP. One of the core pieces this code depends on is the claims based authentication. The instructors told us that at one point during the development cycle, the SharePoint team was considering to cut claims authentication. Since the SAP integration was an important strategic choice, they managed to keep it. Just imagine what we wouldn’t be able to do had the decision fallen the other way.

It’s rather appropriate that the next conference is in Las Vegas. Until then it’s pretty much a betting game if features will make it or not. Since SharePoint 15 will include everything from on premise to cloud solutions, it’s not unthinkable that something gets cut if it prevents one or the other from working. If the community shouts loud enough, any missing pieces might make it into a feature pack or service pack. At this point in time, who the hell knows. I doubt even Microsoft knows.


SharePoint 15; a peek under the covers

First of all, at the time of writing this post, I do not have access to any of the SharePoint 15 TAP bits, or have received any presentations related to SharePoint 15. All the information is based on public information released by Microsoft.

On January 30th, they released SharePoint 15 Technical Preview Managed Object Model Software Development Kit, This contains a CHM file that outlines the changes to the SharePoint API’s. Looking at the API changes, we can get some idea of what is planned.

Since they have started to document the API’s already, maybe SharePoint 15 will be fully documented when released đŸ™‚

NOTE: As it is a long time until it ships, and Betas are available, Microsoft could choose to cut or change things completely.

Support for Apps

There are several API changes that indicate that SharePoint will be getting App support.

SPApp: Represents an app loaded onto Microsoft SharePoint Server and ready to be installed.
SPAppInstance: Represents an SPApp object installed to a specific SPWeb site
SPAppCatalog: Represents all of the SPAppInstance objects installed on an instance of Microsoft SharePoint Server. It provides querying capabilities for discovering installations.
SPWeb.LoadAndInstallApp(): Uploads and installs an app package.
PackageSource enum: Specifies the source of the package that is associated with a provisioned database. Some of the valid values are StoreFront, CorporateCatalog, and DeveloperSite
IDatabaseProvider interface: Provides methods to manage the lifecycle of database

What do these changes mean for Sandboxed Solutions? When do you chose what approach to use? What are the capabilities of an App? PackageSource.StoreFront is described as MarketPlace, so it looks like Microsoft will set up some central repository for apps.

Since we already have Web Applications (web apps), I’m just looking forward to the confusion when people start talking abouts apps. What type of app do they mean?

Multiple compatibility levels

Several API’s have been introduced to handle compatibility levels.

SPFarm.GetPersistedFeatureDefinition method (Guid featureId,int compatibilityLevel): Returns the SPFeatureDefinition object for the given compatibility level based on the featureId parameter value.
SPUtility.GetLayoutsFolder (): Returns the versioned layouts folder for the specified site collection/site
SPUtility.ContextLayoutsFolder: Gets the versioned layouts folder for the context site.
SPSite.CompatibilityLevel: Gets the major version of this site collection for purposes of major version-level compatibility checks.

Since the system supports multiple compatibiliy levels of features and layouts folder, it will be interesting to see what the file structure will look like for the rest of the system. Are they moving to a single file structure where each release has seperate folders? It wouldn’t surprise me if this functionality was driven by Office 365; that way they can use the same farm to host multiple versions and let customers upgrade when they are ready.

Licensing framework?

SPWebApplication.IsUserLicensedForEntity():Checks if the currently logged in user has the proper license to access the specified entity.

Could this indicate generic licensing framework that we can leverage in our solutions?


With the amount of changes Microsoft implemented between 2007 and 2010, the information currently available in the API documentation is probably just a thimble of a vast ocean of changes planned for the next release. It will be very interesting to see what else will be coming down the road.

At least it looks like us ‘boring’ SharePoint developers can become ‘cool’ by putting ‘app developer’ on our resume.