blog.atwork.at

news and infos about microsoft, technology, cloud and more

Why the new App Model in SharePoint 2013 outdates the old coding solutions

SharePoint 2013 is in the market since more than two years by now. And SharePoint 2016 is about to come soon. Beside all the standard features the SharePoint framework can be extended with custom solutions to automate processes within the system.

In 2013 we have a new App Model which solves a lot of issues we had with custom solutions in the previous versions of SharePoint. In this article I want to point out why using the App Model is a good idea and why I recommend using it. But let´s have a look into that step by step. We start with the types of solutions developers can build on top of SharePoint.

Types of custom solutions

In SP 2013 we still have support for the existing code models farm solution and sandbox solution plus the new App Model.

  1. SharePoint Farm solutions run in the SP host environment - in the main SharePoint worker process (w3wp.exe)
  2. Sandboxed solutions came with SP 2010, but are very restricted (everyone who programed sandbox solutions knows what this means...). They run within the SharePoint user code solution worker process (SPUCWorkerProcess.exe).
  3. The new App Model with remote app webs.

For the first two models the following statements are restricting their usage...

Reason #1: Stability

As you see in the list above the first two code models have their runspace within the SharePoint system (see also Differences Between Sandboxed and Farm Solutions). That´s why Microsoft wants to eliminate custom code in there: To increase performance and stability of the core SP system. Custom code shall not run in the same environment or in the same system - which makes sense.

Reason #2: Dependency

Code is based on references to a specific Microsoft.SharePoint.dll version and sometimes relies on a particular feature set.

This is a handicap when there´s a new SharePoint version available and often prevents companies updating their SP farm because they need to test (or migrate or rewrite) their custom solutions with the new version.

Reason #3: Security

In SP solutions there exist some ways of permissions/security for code.

  • Basically code always runs under the identity of a specific user. If a farm admin activates a feature, the code also runs with all permissions of that admin.
  • Likewise in farm solutions developers can request to run code as system account by using the SPSecurity.RunWithElevatedPrivileges method. Then there´s no code security and the code can perform all actions within the SP system.
  • In sandboxed solutions the SharePoint system itself is protected, but not the content of a site collection. A security feature of sandboxed solutions is that there´s no user impersonation possible. This can be a problem f.e. when the app needs to write back data but the user does not have rights to perform this operations.

Often SP solutions are developed using Full Trust to perform complex operations or provisioning components. SP-Admins cannot configure Security explicitly for a specific SP solutions. So all these concepts regarding permission and trust are not optimal.

Reason #4: Installation (and Upgrade)

The installation and upgrade of a farm solution needs to be done by a farm administrator (and sometimes requires an IIS restart). Business users cannot buy or install a solution on their own, they are dependent on the IT admins. Often Upgrades are not done because of the fear that some features may not work afterwards.

Now the good message: The new App Model

To make it short: All these issues are no longer existing with the new App Model coming with SP 2013 and Office 365. The App Model has been redesigned with a complete new architecture. The key components of the App Model are:

  • Apps run separate in a remote web (and are embedded in a SP host web) - and no longer in the SP processes. This also means scaling of the app can be done easily.
  • Apps are using predefined Web services (Endpoint addresses) for accessing data instead of references to specific DLLs to minimize version specific dependencies.
  • Since web services are used, Apps can be programmed in any language - an App is a website with a manifest (see here and our 6 part article series about Office & SP Apps here).
  • App permissions can be configured.
  • Apps are deployed easily through App catalogs (where the app manifests is known).
  • Apps can run in both worlds: in SP 2013 on premises farms as well as in Office 365.

Each of these (new) features is worth using the new App Model!

Two types of Hosting

Hosting for the "new" Apps must be chosen by the developer when creating a new project.

Today developers have the option to select SharePoint-hosted (Client side Script which runs in the user´s browser) or Provider-hosted App (which runs on any webserver or f.e. in Microsoft Azure). The Auto-hosted model is no longer available (see here).

image

Source: See Overview of apps for SharePoint in MSDN for more details.

If you are interested in how to Switch from SharePoint 2010 solutions to apps for SharePoint check out this article.

More details about SharePoint Apps will follow...

Loading