SharePoint: Customization Evolution

In all the versions there are various architecture-level upgrades highlighted in this article.





Full trust solutions

You're missing control, since we basically grant full access rights for the code across our application and in servers. In previous versions you could have limited provide access, but that was difficult to do and was not used that often. In general deployment always causes a service break on the servers, since there's really no way to update the server without at least recycling the application pool.

Sandbox

Our customization story basically grew up a little bit or from an administrative perspective when we gained some control. This was introduced in 2010 but was too strict from the server-side API level that developers have been used to use and client-side APIs were also so limited that even though you could have implemented some.

App model

The Model is growing up with key objectives being on control, trust and management.

SharePoint Application Evolution:

• 2007: Everything is an application
  
  
  • Push to embrace SharePoint for LOB applications
  • Experience was to write custom server-side code
    
    
• 2010: Choose the right application
  
  
  • SharePoint and Developer Tools come together
  • Silverlight, CSOM and other new capabilities
  • Partially trusted code reduces impact and risk to the Farm
    
    
• 2013: Redefine application as app
  
  
  • Client-side experience via HTML or iFrame
  • Leverage CSOM and REST APIs from Azure and other clients
  • Investments in app discovery and management via SharePoint store