Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

SharePoint 2013 Sandbox Solutions for On Premise or Office 365

3,847 views

Published on

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!

Published in: Technology
  • Be the first to comment

  • Be the first to like this

SharePoint 2013 Sandbox Solutions for On Premise or Office 365

  1. 1. Sandbox Solutions for On Premise and Office 365 Ed Musters SharePoint Architect, Infusion @TechEdToronto
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 12. Site Columns and Content Types
  13. 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. 14. Deployment and Features
  15. 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. 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. 17. List Definitions and Instances
  18. 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. 19. Custom Actions RIBBON BUTTONS AND JAVASCRIPT
  20. 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. 21. Branding DEPLOYING SITE ASSETS
  22. 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. 23. Site Pages using Angular JS
  24. 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. 25. Web Templates
  26. 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. 27. Question and Answer
  28. 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. 29. Question and Answer Ed Musters emusters@infusion.com @TechEdToronto
  30. 30. Thank You

×