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.

Do's and don'ts for Office 365 development


Published on

A session I gave at the European SharePoint Conference 2015. Abstract: The "rules" of SharePoint development have changed - although MSDN documentation often lags behind, the Office 365 Product Group tell us we're no longer supposed to use custom master pages, WebTemplates or deploy our fields and content types in XML. This means core concepts and guidelines that have been around for 7 or 8 years no longer hold true! Clearly this is a massive change - but do we always need to adhere to these new rules? Or are there times when it's OK to use less-preferred (but still supported) approaches?

In this session we look at the reasons behind Microsoft's change of position, and the associated thinking you need to do in the real world.

In this session you will learn:
1. A discussion of the key changes in developer guidance
2. A technical deep-dive (with demos) into the new approaches Microsoft recommend
3. Consideration of the circumstances where you might choose NOT to adhere to the guidance, and why

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Do's and don'ts for Office 365 development

  1. 1. Do’s and Dont’s for Office 365 Development Chris O’Brien - MVP
  2. 2. Independent Consultant Head of Development, Content and Code @ChrisO_Brien About me
  3. 3. Agenda • The Office 365 dev landscape – things you CAN’T do • The DON’T list: • 4 fundamental don’ts • 4 “more debatable” don’ts  • The DO list • Remote provisioning • Office 365 apps/auth over SharePoint Add-ins • App script parts • Summary
  4. 4. Office 365 dev – things you CAN’T do Farm solutions (WSPs) • No feature receivers • No timer jobs • No event receivers Non-sandbox SharePoint API code • No custom field controls • No site definitions • Etc.. The following are 100% NOT SUPPORTED in Office 365:
  5. 5. Fundamental “don’ts”
  6. 6. Don’t #1 - don't use the sandbox APIs Why not: • Microsoft are likely to disable server- side code in SharePoint Online What you CAN do: • Use client-side code (e.g. JavaScript) • Use remote server-side code (e.g. the add-in model)
  7. 7. Don’t #2 - don't customize the suite bar Why not: • Microsoft need to “own” this – new functionality may appear here • JavaScript/CSS hacks may conflict with Microsoft changes • Consistency across tenants What you CAN do: • Add a logo/ background image • Change the color via Office 365 themes
  8. 8. Don’t #3 - don't rely on Office 365 HTML* Why not: • Microsoft need to change this from time to time • It is NOT an API or contract What you CAN do: • Provide your own HTML – master page, layouts, display templates etc. (*or at least, be VERY careful!)
  9. 9. Don’t #4 - don't customize ODFB sites Why not: • Microsoft need to “own” this – new functionality may appear here • Now considered part of the service, like Delve • Becoming more like a doc lib, rather than full site Guidance webcast: •
  10. 10. Fundamental “don’ts” summary: 1. Don’t use the sandbox APIs 2. Don’t customize the suite bar 3. Don’t rely on Office 365 HTML 4. Don’t customize ODFB sites
  11. 11. Do’s: 1. Do use Office 365 themes/suite bar options 2. Do use remote APIs: 1. CSOM (.NET) 2. JSOM 3. REST 4. Android/iOS
  12. 12. More controversial don’ts 1. Don’t use a custom master page 2. Don’t use a custom web template 3. Don’t use Features to provision fields and content types ..also: 1. Don’t use web parts
  13. 13. More debatable/controversial don’ts: #1 Don’t use a custom master page
  14. 14. Don’t use a custom master page! WHAT?? • This is the recommended approach to branding since SharePoint 2007! • Easy way to control all pages in a site (e.g. global navigation, footer etc.) Why not: • Microsoft will update OOTB master pages with new functionality
  15. 15. Office 365 updates and your master page Time OOTB Master Custom Master<< Copy >> Service updates for introducing new version of the out of the box master page with some new capabilities or bug fixes. Significant differences on the outcome unless custom master page been updated during the releases. New custom master page is created by copying oob master or starting from scratch using oob master as the reference master Seattle.master Version 1.0 master Seattle.master Version 2.0 master Seattle.master Version 3.0 master contoso.master Version 1.0 master contoso.master Version 1.0 master contoso.master Version 1.0
  16. 16. Untested updates can be dangerous! The scenario: • Intranet with 50,000 users • OOTB master page, with some custom CSS/JavaScript Untested O365 change = broken intranet
  17. 17. Strategies for dealing with this 1. Explicitly CHOOSE to use a custom master page – SOME protection? N.B. This involves “paying the customization tax” – you need to copy any Microsoft updates 2. Always have a First Release-enabled tenant
  18. 18. Deciding whether to use a custom master page Other factors: • Responsive design? • Can CSS achieve the requirements?
  19. 19. More debatable/controversial don’ts: #2 Don’t use custom WebTemplates
  20. 20. Don’t use custom WebTemplates! Why not: • It’s the same deal as custom master pages – Microsoft will want to update e.g. the team site definition
  21. 21. Maintenance challenge with web templates Time Team Site Custom Web Template <xml> onet.xml X feature activations <xml> onet.xml X feature activations <xml> onet.xml X feature activations +2 <xml> onet.xml X feature activations +4 <xml> onet.xml X feature activations <xml> onet.xml X feature activations << Copy >>
  22. 22. More debatable/controversial don’ts: #3 Don’t use Features to provision fields/content types etc.
  23. 23. Don’t use Features for provisioning Why not: • Provisioned artifacts have dependency on Feature XML (in content database) • Microsoft don’t like this for running Office 365 BUT: • Is that the implementer’s problem? 
  24. 24. Do’s: #1 Do use remote provisioning
  25. 25. Remote provisioning – the alternative to WebTemplates • Better APIs for remote provisioning now • OfficeDev Patterns and Practices site provisioning framework: • XML for defining custom site “template” definition • Remote code (PowerShell or .NET) to create sites – Azure WebJob • Full engine/framework for creating sites from a SharePoint list item • Ability to “extract template” from an existing site
  26. 26. Custom sites via remote provisioning in Office 365 DEMO
  27. 27. Do’s: #2 Use Office 365 apps in preference to SharePoint Add- ins
  28. 28. Using Office 365 APIs • SharePoint add-in authentication sucks! • Less and less reason to build a SharePoint add-in. Consider: • SP add-ins need to be installed to sites • SP add-ins must be accessed from SharePoint – not standalone • Office 365 app authentication can now talk to SharePoint. Technique: Authenticate to Office 365/Azure AD Get access token Use token with CSOM/REST Office 365 app? SharePoint Add-in?
  29. 29. Options for Azure AD auth “User + app” authentication • Authorization Code Grant Flow • Implicit Grant Flow “App-only” authentication • Client Credentials Grant Flow
  30. 30. Using an Office 365 auth token to talk to SharePoint DEMO
  31. 31. More debatable/controversial don’ts: #4 Don’t use web parts
  32. 32. Do’s: #3 Use app script parts (cloud-friendly web parts)
  33. 33. App script parts Web part definition = Script Editor Web Part + custom JavaScript Output a DIV onto page JavaScript injects content into DIV
  34. 34. App script parts (modern web parts) DEMO
  35. 35. App script parts - advanced • Sometimes you need “web part properties” • This involves: • Storing the data • Presenting the UI • Options: • Persist somewhere custom • Persist to Script Editor config (hidden field) – see
  36. 36. Do’s: #4 Create multiple tenancies (if doing development)
  37. 37. Using multiple Office 365 tenancies for dev/test/prod • YES it costs more! • BUT, several SharePoint elements are global: • Change something here whilst developing in a tenant = changed for everyone! • TIPS – use small number of users, and maybe lower plan level
  38. 38. Summary – what to take away • BUT, consider whether guidance is 100% appropriate for your case • A custom master page and/or web template is NOT crazy for a publishing intranet! (But it might be for collaboration sites) Old approach Consider.. Custom master page Office 365 themes. Custom CSS file. Web templates/features for provisioning Remote provisioning Web part App script part
  39. 39. Resources • Training section on • PnP remote provisioning solution - webcast • • Avoid customizing ODFB sites – webcast: • • App script web part with properties: • • (By Ole Martin Pettersen)
  40. 40. Hackathon WINNING TEAM GETS
  41. 41. THANK YOU! ANY QUESTIONS? Chris O’Brien