The move from SharePoint solutions development to
SharePoint app development represents a significant change in
development technique and perspective. However, Microsoft is not making
this change just for the sake of making a change; there are very valid
technical reasons that warrant such a drastic shift in the future of
the SharePoint development platform.
To fully understand Microsoft’s
motivation for beginning to transition away from SharePoint solutions
to the new SharePoint app model, you must first understand the problems
and pain points of SharePoint solutions development. Therefore, this
section will begin by describing the limitations and constraints
imposed by SharePoint solution development. After that, the discussion
turns to the design goals and architecture of the new SharePoint app
model and addresses how this architecture improves upon the limitations
and constraints imposed by SharePoint solution development.
Understanding SharePoint solution challenges
The first problem with SharePoint solutions development is that most
of the custom code written by developers runs within the SharePoint
host environment. For example, managed code deployed in a farm solution
runs within the main SharePoint worker process (w3wp.exe). Managed code deployed by using a sandboxed solution runs within the SharePoint sandboxed worker process (SPUCWorkerProcess.exe).
There are two primary reasons why Microsoft wants to get rid of
custom code that runs within the SharePoint environment. The first
reason has to do with increasing the stability of SharePoint farms.
This one should be pretty obvious. Eliminating any type of custom code
that runs within the SharePoint environment results in lower risk,
fewer problems, and greater stability for the hosting farm.
The second reason has to do with the ability to upgrade an
on-premises farm to newer versions of SharePoint. SharePoint solutions
are often developed with full trust and perform complex operations.
These solutions are often tightly bound to a particular feature set,
which means that they might not move gracefully to the next version of
SharePoint. Fearing a complete rewrite of dozens of solutions, many
customers delay upgrading their SharePoint farms.
Microsoft has witnessed many of their biggest SharePoint customers
postponing the upgrade of their production on-premises farms for months
and sometimes years until they have had time to update their SharePoint
solution code and test it against the new version of
Microsoft.SharePoint.dll. Because this is a problem that negatively
affects SharePoint sales revenue, you can bet it was pretty high on the
priority list of problems to fix when Microsoft began to design
SharePoint 2013.
Another significant problem with SharePoint solution development has
to do with security and permissions. The root problem is that code
always runs under the identity and with the permissions of a specific
user. As an example, think about
the common scenario in which a site administrator activates a feature
from a SharePoint solution that has a feature receiver. There is a
security issue in that a SharePoint solution with a feature receiver is
able to execute code that can do anything that the site administrator
can do. There really isn’t a practical way to constrain the SharePoint
solution code so that it runs with a lesser set of permissions than the
user that has activated the feature.
Most SharePoint professionals are under the impression that code
inside a sandboxed solution is constrained from being able to perform
attacks. This is only partially true. The sandbox protects the farm and
other site collections within the farm, but it does not really protect
the content of the site collections in which a sandboxed solution is
activated. For example, there isn’t any type of enforcement to prohibit
the feature activation code in a sandboxed solution from deleting every item and every document in the current site collection.
Another issue with sandboxed solutions is that there’s no ability to perform impersonation.
Therefore, custom code in a sandboxed solution always runs as the
current user. This can be very limiting when the current user is a
low-privileged user such as a contributor or a visitor. There is no way
to elevate privileges so that your code can do more than the current
user.
Farm solutions, on the other hand, allow for
impersonation. This means a developer can elevate privileges so that
farm solution code can perform actions even when the current user does
not possess the required permissions. However, this simply replaces one
problem with another.
A farm solution developer can call SPSecurity.RunWithElevatedPrivileges, which allows custom code to impersonate the all-powerful SHAREPOINT\SYSTEM
account. When code runs under this identity, it executes with no
security constraints whatsoever. The code can then essentially do
whatever it wants on a farm-wide basis. This type of impersonation
represents the Pandora’s Box of the SharePoint development platform
because a farm solution could perform an attack on any part of a farm
in which it’s deployed, and it must be trusted not to do so. As you can
imagine, this can cause anxiety with SharePoint farm administrators who
are much fonder of security enforcement than they are of trust.
In a nutshell, the security
problems with SharePoint solutions stem from the fact that you cannot
effectively configure permissions for a specific SharePoint solution.
This limitation cannot be overcome, because the SharePoint solution
development model provides no way to establish the identity of
SharePoint solution code independent of user identity. Because there is
no ability to establish the identity of code from a SharePoint
solution, there is no way to configure permissions for it.
The last important pain point of SharePoint solution development centers around installation and upgrade. The installation of farm solutions is problematic because it requires a farm administrator, and it often requires restarting Internet Information Services (IIS)
on all the front-end web servers, causing an interruption in service.
Although the deployment of a SharePoint solution doesn’t involve these
problems, it raises other concerns. Business users often have trouble
with the process of finding and uploading sandboxed solutions in order
to activate them. Furthermore, a business user has very little to
indicate whether or not to trust a sandboxed solution before activating
it and giving its code access to all the content within the current
site collection.
Of all the issues surrounding SharePoint solution development, nothing is more prone to error and less understood than the support for upgrading
code from one version of a SharePoint solution to another. Even though
Microsoft added support for feature upgrade and assembly version
redirection in SharePoint 2010, almost no one is using it. The required
steps and the underlying semantics of the feature upgrade process have
proved to be too tricky for most developers to deal with. Furthermore,
the vast majority of professional SharePoint developers have made the
decision never to change the assembly version number of the assembly
dynamic-link library (DLL) deployed with a SharePoint solution. That’s
because creating and managing the required assembly redirection entries across a growing set of web.config files is just too painful and error prone.
You have just read about the most significant pain points with
respect to SharePoint solution development. Here is a summary of these
points.
-
Custom code running inside the SharePoint host environment poses risks and compromises scalability.
-
Custom code with dependencies on in-process DLLs causes problems when migrating from one version of SharePoint to the next.
-
A permissions model for custom code based entirely on the identity of the current user is inflexible.
-
User impersonation solves the too-little-permissions problem but
replaces it with the too-many-permissions problem, which is even worse.
-
SharePoint solutions lack effective support and easily understood semantics for distribution, installation, and upgrade.
