Sandbox Solutions for On Premise and Office 365

Ed MustersSharePoint Architect, Infusion

@TechEdToronto

Presentation Summary

Were Sandbox solutions not “deprecated”?  In this session you will learn that for the developer, Declarative (No Code) Sandbox solutions are still an extremely valid and completely supported way for you to create solutions that are either targeted for On Premise or Office 365.  We will look at the types of features and solutions you can create with Visual Studio 2013 and the practical scenarios they enable.  Examples include deployment of site columns, content types, list definitions,  ribbon buttons, design assets, site pages with JavaScript, web templates, and more!

Audience: Developer

Level: 100

Pre-Requisites: Knowledge of SharePoint configuration, basic SP developer knowledge

{ About.Me() }

https://mvp.support.microsoft.com/profile/Ed.Musters

• Current SharePoint MVP – TENTH year!• Author for two SP development books• SharePoint Architect for Infusion• Speaker at International Conferences on

SharePoint, at user groups, and at SharePoint Saturdays

• Certified Trainer for the industry leading SharePoint training from Critical Path Training

• Holds all MS certifications for SharePoint 2010 (in progress for SP 2013!)

• Harley-Davidson ™ Enthusiast!

Agenda

• Introduction• Site Columns and Content Types• Deployment and Features• List Definitions and Instances• Custom Actions (Ribbon Buttons)• Branding• Site Pages using Angular JS• Web Templates• Q&A

What is a “Sandbox Solution”?• A means of providing features available only to a single site

collection!• Visual Studio packages SharePoint Solutions into a deployment

file that has a WSP extension. • The packaging format is a CAB (cabinet) file.• It contains a manifest file, has one or more features, and will

deploy included files into the content database• Element.xml files contain provisioning instructions to create

SharePoint artifacts, such as site columns, content types, list definitions, list instances• “Declarative” or “No Code” Sandbox solution means there is no

DLL file contained in the WSP (i.e. no compiled C# code!)• You can still deploy and use client-side JavaScript with JSOM or REST –

does not count as “code”, which really means “server side code”

Compared to a “Farm Solution”?• Farm Solution is only a ONE BOOLEAN SETTING difference in VS

from a Sandbox Solution!• Farm Solutions deploy to the 15 (SharePoint Root) folder instead

of the site collection solutions gallery• Sandbox Solution features are scoped to a specific site collection.• Farm Solution features are available from any site collection.• Both Farm and Sandbox provision files to the content database

(for example, master pages) when the corresponding feature is activated, and not when the solution is added.• Take for example a Site Columns feature, the result in the site

collection is identical when feature activated. It does not matter if the WSP was deployed as a Farm solution or Sandbox solution.

Sandboxed Solutions Deprecated?

• But wait! Isn’t the Sandbox deprecated?• Deploying executable code (DLL) in a Sandbox is deprecated (i.e. no longer

allowed)• Deploying “declarative” solutions is still perfectly valid

• Designer Manager output is a Sandbox Solution• “Save As Template” creates Sandbox WSPs• That is, even SP 2013 uses the Sandbox!

• The Sandbox is an excellent method of deploying Site Collection level assets• Statement from SharePoint product group:

• http://blogs.msdn.com/b/sharepointdev/archive/2014/01/14/deprecation-of-custom-code-in-sandboxed-solutions.aspx

What about Imperative Provisioning?Jeremy Thake says you should do imperative (with code) provisioning, not declarative, in his Top 10 tips for shifting to the App Model

http://www.jeremythake.com/2014/09/top-10-tips-for-preparing-for-the-shift-to-the-sharepoint-app-model/  

Tip 6 – Encourage imperative not declarative

From my early days in SharePoint development at Pretzel Logic in Western Australia, I was encouraged by my fellow .NET peers to make sure I had an continuous integration story. One big goal here was to have a fully automated provisioned developer environment for whatever business solution I was working on. Very early on I realized that I was using Visual Studio’s wizards to create all my artifacts (Content Types, Lists, Sites) with declarative XML and soon hit the wall of wanting to update the instances of these artifacts once they were provisioned. Updating instances of artifacts is not possible with the declarative XML approach (except for adding fields to Content Types) and so you have to resort to imperatively coding this using CSOM or REST. A big stance I took early on was to not only update my artifacts imperatively, but also to provisioning them. The benefits this gave me with: debugging through code rather than horrible XML parser errors; reusability with helper classes; cleaner code (list schema is 2000+ lines of XML vs a few lines of CSOM code); compile time errors; strongly typing; method extensions to CSOM speed things up (like on SPList and SPWeb); and much more.

• Notably see Office Patterns and Practices for excellent examples of all kinds, including provisioning

Declarative or Imperative?

• If you are provisioning, say, a custom team site and plan to deploy thousands of instances, deploying thousands of copies of a sandbox solution is not practical or maintainable – go imperative.• If you are a coder comfortable with Provider Hosted Apps, and agree

with the benefits that Jeremy provides – go imperative• If you want a supported alternative to SharePoint Hosted Apps that

overcomes some of the App limitations – go declarative• If you want an easy way to provision site collection level assets – go

declarative• If you are developing a custom solution for a given site collection – go

declarative• E.g. For our current customer, back end is provider hosted apps and Web Api,

front end publishing solution entirely provisioned with Sandbox and PowerShell

Sandbox Solution Benefits• Sandboxed solutions can be added to a production SharePoint

Server environment without the risk of affecting processes outside the sandbox• Which is a similar benefit to the App model

• Site collection administrators can deploy sandboxed solutions. This frees farm administrators from this task.• The solutions are more “localized” to the specific site collection in

which they are being deployed

• Use SharePoint Configuration tools, then “extract” the SharePoint Items to your Sandbox Solution in Visual Studio• In browser customizations, save as site template (import WSP),

SharePoint Designer (e.g. Page Layout), Design Manager (Master Page, design assets)

• Work equally well On Premise or in Office 365• Lowers the development bar to delivering customizations

On to Declarative Provisioning Examples!

• Maybe the answer for you might ultimately be a bit of both Imperative and Declarative provisioning• Before you decide, let us go through the many cases where

declarative provisioning can apply… you might be surprised!

Site Columns and Content Types

Site Columns and Content Types

• Schema in SharePoint is defined by Site Columns and Content Types• Content Types are typically added to lists, and lists can support

multiple content types• Your content type can include, for example, a document

template• Note in this case you will also need to deploy the document

template file as well

• The Content Type designer in Visual Studio hides all of the complex XML from you!

Deployment and Features

Deployment and Features

• Back to the Feature! • Talking about Features and deployment is a recurring theme for me.

• Visual Studio will create a WSP package

• The WSP file is uploaded to the Site Collection Solutions Gallery

• You can activate / deactivate the Sandbox solution from the gallery

• Features only appear in / are available from the Site Collection in which the Sandbox solution is deployed! (unlike a Farm Solution)

• You can easily automate the WSP deployment via PowerShell, very much like the commands for a Farm Solution

• If you need to supplement your Sandbox provisioning with “Imperative coding”, you can always use PowerShell scripting!

Important Notes

• Ensure that the “Include Assembly in Package” is FALSE in your Visual Studio Project!• Don’t fear the warning “Solutions can consume server

resources and my be temporarily disabled if your resource usage exceeds your quota”• Declarative solutions don’t consume any server resources, only DLLs

do.• If interested, see resource points at http://

msdn.microsoft.com/en-us/library/gg615462.aspx

List Definitions and Instances

List Definitions and Instances

• When you deploy a custom list definition to the site collection root, that list type will be available to create anywhere in the site hierarchy• You can include the creation of a list instance in your Sandbox,

including populating default data items• When you create a list instance, it can be a custom list

definition or and OOTB list definition (e.g. a Contacts list named “Customers”)

Custom ActionsRIBBON BUTTONS AND JAVASCRIPT

Custom Actions

• It’s all about the navigation• Declaratively add navigation items

• Global Navigation, Quick Launch

• Can add to SharePoint Menus• Site Actions, ECB Menu, Site Settings

• Add to SharePoint Ribbon

BrandingDEPLOYING SITE ASSETS

Branding

• Deploy and type of Site assets (files) into the content database

• Create these with Design Manager or SharePoint Designer

• Master Pages, Page Layouts, images, JS, CSS, Site Pages

• For a Publishing Site, DESIGN MANAGER used to create the brand!

• Create and edit Master Pages and Page Layouts

• Brand is 100% Design Manager compatible

Site Pages using Angular JS

Site Pages Using Angular JS

• If your Site Pages include JavaScript – including those using your favorite JS Framework such as Angular – these are NOT considered “code”. • They can be deployed using Sandbox solutions• They can call SharePoint APIs such as JSOM and REST• They can call custom Web API services (REST)

• Alternative to an App??• No IFrame overhead / limitations• How do you make an App Part responsive on a web page• No Cross Site Scripting Considerations• No security / permission considerations or authorization overhead• Easy to deploy – just a “copy” to the content database

Web Templates

Web Templates

• Creating Team Sites, then heavily modifying them before giving to user?• Let a web template do the work for you!• Can include provisioning of other Sandbox items we have

created• Mirjam Van Olst presented an entire session on this at SPC 14:

• http://channel9.msdn.com/Events/SharePoint-Conference/2014/SPC305

Question and Answer

Conclusion – Sandbox Solutions

• Lets the developer create, package, and deploy SharePoint Items at a site collection level

• Are a level in between no code solutions (SharePoint Designer, Design Manager) and Apps with Imperative Provisioning

• Are an official supporting packaging (WSP files) for deployment to SharePoint

• Are a great addition / alternative to provisioning your SharePoint customizations using Apps

• Are assisted by PowerShell for deployment or additional imperative provisioning• On Premise – traditional SharePoint Cmdlets• Office 365 – PowerShell and CSOM (limited online cmdlets now)• Hopefully more SharePoint PowerShell cmdlets for O365 coming in future!

Question and Answer

Ed Mustersemusters@infusion.com@TechEdToronto

Thank You