SharePoint 2013 Development–Microsoft has their Heads in the Clouds

Published on: Author: Rob Windsor 2 Comments

The SharePoint 2013 Preview has been out for a couple days and I have it all figured out – not! But I have seen enough to get the general feel of the release, at least from a developers perspective.

The App and Solution Models

The vast majority of the material that has been released over the last couple days is on the new App model. For the purposes of this post I’m going to assume you have a general idea of what the App model is and how it will be used. If you don’t and you want an overview go to Apps for SharePoint overview, if you want details go to (SharePoint 2013) Developer Training.

I get why there’s a need for the App model. We need a development model for clients who are multi-tenant hosted (read Office 365) or who have very locked down systems that doesn’t involve pushing files into the file systems of the SharePoint servers. From what I’ve seen of the App model it is a very well thought out way to solve that problem. However, these clients make up a pretty small percentage of the total number of clients using SharePoint. I’m pretty certain it’s under 25% and I might be willing to wager a penny or two that it’s under 15%. For the rest of the clients we still have the existing Solution model to use when building SharePoint applications – or do we?

As I’ve been going through the material on MSDN and TechNet (and kudos to everyone involved for getting so much material out so quickly) I’ve seen things that me go hmmmmmmm. Here are some examples:

From What you can do in an app for SharePoint (2013)

With previous versions of SharePoint, farm administrators sometimes refused to install any custom SharePoint extensions because of the danger of errant code. In SharePoint 2013 Preview, that problem is essentially eliminated because the client object models have been greatly expanded. This means that you as a developer do not have to use the server object model anymore. All your custom business logic moves "up" to the cloud or "down" to a client machine, and it uses one of the client APIs discussed in an earlier section. Because the app does not (actually cannot) contain custom code that executes on the SharePoint servers, administrators are assured of its safety.

From Apps for SharePoint compared with SharePoint solutions

The most important guidance we can give you is to develop an app for SharePoint rather than a classic solution whenever you can. Apps for SharePoint have the following advantages over classic solutions

From Apps for SharePoint compared with SharePoint solutions

SharePoint sandboxed solutions are deprecated in SharePoint 2013 Preview in favor of developing apps for SharePoint, but sandboxed solutions can still be installed to site collections on SharePoint 2013 Preview. This topic compares apps for SharePoint with farm solutions.

[RW: This text was changed after the original release of the document. The original text read: SharePoint sandboxed solutions are deprecated in SharePoint 2013 Preview. This topic compares apps for SharePoint with farm solutions.]

From Choose the right API set in SharePoint 2013

Developing new sandboxed solutions against SharePoint 2013 Preview is deprecated in favor of developing apps for SharePoint, but sandboxed solutions can still be installed to site collections on SharePoint 2013 Preview.

[RW: This text was changed after the original release of the document. The original text read: Developing new sandboxed solutions against SharePoint 2013 Preview is not supported, but sandboxed solutions developed against earlier versions of SharePoint can be installed to site collections on SharePoint 2013 Preview]

From SharePoint 2013 customization options and management (Module 10 – Video 4)

Client OS installations are not anymore supported [sic]

[RW: This means that Solutions development for SharePoint 2013 will need to be done on Windows Server]

It’s ALL about the Cloud

These resources and some others I’ve seen have led me to believe that Microsoft doesn’t consider the App model as a companion to the Solution model, they see it as a replacement for the Solution model. If that’s true then the vision moving forward is that the vast majority of SharePoint applications will be implemented using the JavaScript Client Object Model or by JavaScript that calls out to custom web services hosted outside of SharePoint that communicate back to SharePoint using the .NET Managed Client Object Model.

I think this would be fine if most clients were on Office 365, but they aren’t. As I said earlier, my experience tells me that more than 75% of companies out there don’t have an issue allowing Solutions to be deployed to their servers. If this is a case, why would they choose to use the App model over the Solution model? Client Object Model code is not as easy to write; even though Microsoft has made great strides to expand the Client Object Model APIs, they are still not as robust as the Server Object Model APIs; and, oh ya, there are all those service calls being made when you use the Client Object Model. IMHO, it doesn’t make sense.

What Me Worry?

I think that a majority, maybe even a vast majority, of development during the SharePoint 2013 timeframe will use the Solutions model. What concerns me is that Microsoft is so committed to the idea that everyone is going to the cloud that they are going to spend all their resources on developing and evolving the App model when most of the developers in the community (including me) would benefit by some of that time being spent to improve the Solutions model.

2 Responses to SharePoint 2013 Development–Microsoft has their Heads in the Clouds Comments (RSS) Comments (RSS)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>