SharePoint 2013 Declarative (no code) Sandbox Solutions presentation delivered Nov 5 at the Houston SharePoint TechFest. 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!

1. Sandbox Solutions for On Premise and Office 365
Ed Musters
SharePoint Architect, Infusion
@TechEdToronto

2. 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

3. { About.Me() }
• 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!
https://mvp.support.microsoft.com/profile/Ed.Musters

4. 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

5. 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”

6. 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.

7. 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

8. 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

9. 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

10. 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

11. 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!

12. Site Columns and Content Types

13. 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!

14. Deployment and Features

15. 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!

16. 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

17. List Definitions and Instances

18. 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”)

19. Custom Actions
RIBBON BUTTONS AND JAVASCRIPT

20. 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

21. Branding
DEPLOYING SITE ASSETS

22. 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

23. Site Pages using Angular JS

24. 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

25. Web Templates

26. 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

27. Question and Answer

28. 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!

29. Question and Answer
Ed Musters
emusters@infusion.com
@TechEdToronto

30. Thank You