Downloaded 54 times
Uploaded byJeremy Thake
Getting started with Office 365 SharePoint 2010 online development
This document discusses getting started with application development for SharePoint 2010 Online. It covers the application development platform, sandboxed solutions, application lifecycle management, and migrating applications. The key points are that development should occur in a sandboxed environment using Visual Studio, source control is important, and third party tools can help migrate applications between environments.
More Related Content
Similar to Getting started with Office 365 SharePoint 2010 online development
More from Jeremy Thake
Getting started with Office 365 SharePoint 2010 online development
- 1. Getting started withSharePoint 2010 Online development Jeremy Thake Chief Architect, AvePoint Inc.
- 2. Jeremy Thake ©2012 AvePoint, Inc. All rights reserved. No part of this may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written consent of AvePoint, Inc.
- 3. Agenda • Application Development Platform • Getting Started • Sandboxed Solutions • Application Lifecycle Management • Migrating Apps
- 4.
- 5. Building Blocks • Authentication & Authorization • Customization & Personalization • Branding • Disaster recovery • Availability • Site collections & Sub sites
- 6. No more… • installing SQL • configuring IIS • deploying components to server • writing service level agreements • writing disaster recovery plans
- 7. List Building Blocks • Attachments • Metadata • Versioning • Views • Full API: Web services, REST, RSS… • Security • Event Receivers • Workflow • Publishing
- 8. What to worryabout • UI pattern consistency • Don’t bend it the wrong way – If you question whether its right, it probably isn’t • Performance considerations • Monitoring – Resource Usage – No ULS logs, Event Viewer
- 9.
- 10. Approaches • Web parts on pages Web UI • Site / List Settings • Branding SharePoint Designer • Business Connectivity Services Visual Studio • “ANYTHING” 2010
- 11. Don’t work directlyon Production • Develop in Development environments!!! • Great for version 1.0, not so great for 1.1 whilst live users in environment – 24 hour SLA on recovering a site collection • SharePoint Designer encourages this
- 12. Development Environment • Musthave Visual Studio where SharePoint installed for server side development • Use a “development” site collection in your Office 365 SharePoint 2010 Online environment – Client Object Model • Install SharePoint 2010 locally on Windows 7
- 13. Use a virtualmachine • VMWare Workstation/Sun VirtualBox on Windows 7 • HyperV on dual boot Windows Server 2008 R2/Windows 7 • HyperV on Windows 8 RC • Steal some of IT private cloud to run one ;-) • Azure, CloudShare, fpWeb, Rackspace
- 14. TIPS • Use SandboxSolutions (default) as can’t use Full-Trust Solutions in SharePoint 2010 Online • Won’t get compile time warnings on incorrect API usage, only on upload to SharePoint – Use the FxCop rules http://o365fxcoprules.codeplex.com/
- 15.
- 16. Sandboxed Solutions • RestrictedAPI due to multi-tenant environment • No LOB: Web Services, ATOM, ODBC • No file access • Current site collection scope only • No Page object (JavaScript reg) • Deployed via Site Collection Site Settings http://msdn.microsoft.com/en-us/library/gg615454.aspx
- 17. *smile* • Office 365customizations • Faster deploys – Doesn’t require IISRESET as assemblies not in GAC • No Farm access required
- 18. WARNING • No “Fulltrust proxies” in Office 365 • Only Site Collection Admins can activate if managed code in packages • Site Collection Admins can deploy these! • Can use Silverlight to overcome some restrictions
- 19. Visual Studio 2012RC • Create Silverlight Web Parts • Publish SharePoint Solutions to Remote SharePoint Servers • Test SharePoint Performance by Using Profiling Tools • Create Sandboxed Visual Web Parts • Support for JavaScript Debugging and IntelliSense for JavaScript http://msdn.microsoft.com/en-us/library/ee290856(VS.110).aspx
- 20. Web Part example •displayed data from a list • perform a SharePoint database query • 20 database queries sandboxpoint the = 1 resource is • turned off until displayed 20 times • site collection would have used 1 resource point of daily reset 300 points available • could be displayed 6,000 times in a 24 hour period
- 21. Resource Quota Resources Resource Units Limit per Point AbnormalProcessTerminationCount count 1 1 CPUExecutionTime seconds 3,600 60 CriticalExceptionCount Events 10 3 InvocationCount Events <TBD> <TBD> PercentProcessorTime % 85 100 ProcessCPUCycles cycles 1 x10^11 1 x10^11 ProcessHandleCount items 10,000 1,000
- 22. Resource Quota Resources Resource Units per Point Limit ProcessIOBytes items 0 1 x10^8 ProcessThreadCount Thread instances 10,000 200 ProcessVirtualBytes Bytes 0 1.0x10^9 SharePointDatabaseQueryCount Query instances 20 100 SharePointDatabaseQueryTime seconds 120 60 Unhandled exception UnhandledExceptionCount 50 3 instances Unresponsive process UnresponsiveProcessCount 2 instances
- 23.
- 24. Application Lifecycle Management(ALM) is a continuous process of managing the life of an application through governance, development and maintenance. WikiPedia
- 25. ALM is themarriage of business management to software engineering made possible by tools that facilitate and integrate requirements management, architecture, coding, testing, tracking, and release management. WikiPedia
- 26. Three aspects ofALM David Chappell (2008)
- 27.
- 28.
- 29.
- 30. Today’s poll question •I am developing Visual Studio SharePoint projects • I am packaging all custom code as a WSP • I am using source control • I am using a build server • I am using SPDisposeCheck • I am doing unit testing
- 31. SharePoint Designer • Promotionbetween environments • Should certain artifacts be packaged as a WSP? • Manual copying and pasting files • Restricting use by policy • Using third party tools to manage deployments
- 32. One farm, manyfeature versions active SITE A SITE B SITE C SPDevWiki SPDevWiki SPDevWiki V1.0.0.0 V3.0.0.0 V3.0.0.0 V2.0.0.0 V3.0.0.0 SPDevWiki SPDevWiki SPDevWiki V1.0.0.0 V2.0.0.0 V3.0.0.0
- 33.
- 34.
- 35. Where are you? Automated Automated Deployment Testing Automated Builds Source control No Source Control
- 36.
- 37. Web UI • Sideby side windows – Site Settings – List Settings – Page content • Windows Explorer – Document Content
- 38. SharePoint Designer • Sideby side across windows – Business Connectivity Services – Web Parts – Content Types • Copy & Paste across windows – Master Pages – Page Layouts – Workflows (no custom activities)
- 39. Sandboxed Solutions • Willwork in SharePoint 2010 Online just like Standard or Enterprise
- 40. Full-Trust Solutions • APIs used • Switch to “Sandboxed” and just try it • Run FxCop against it • Change assembly target for Visual Studio 2010
- 41. Custom crap! • Remember, no access to servers AT ALL • So everything must be in Solution Package • No manual deployment of files to file server • We’ve been teaching you this since ‘06
- 42. 3rd Party Tools •Graphical User Interface to move Site Collection artifacts and content • Lots of players – AvePoint – Axceler – MetaVis – MetaLogix
- 43.
- 44. References • Sandboxed Solutions •Office 365 Developer Hub • NothingButSharePoint.com
Editor's Notes
- #2 Getting started with SharePoint 2010 Online developmentJeremy Thake, SharePoint MVP, will introduce SharePoint 2010 Online as an application development platform inside Office 365. The session will explain how to get started with the different approaches from web UI configurations, to SharePoint Designer 2010 customizations to full blown Visual Studio development with Sandbox Solutions. Jeremy will introduce the concepts of how Application Lifecycle Management can be introduced to this along with migrating existing applications across from on-premise. From this session you should walk away with:Using SharePoint Online 2010 as an Application Development PlatformGetting Started with SharePoint Online 2010 developmentApplication Lifecycle Management with SharePoint Online 2010 in Office 365Migrating SharePoint 2010 Apps to SharePoint Online 2010
- #5 Using SharePoint Online 2010 as an Application Development PlatformMicrosoft launched Office 365 (O365) in June 2010, including SharePoint 2010 Online, as an update to its existing Business Productivity Online Services (BPOS) suite that offered SharePoint 2007 Online. SharePoint is a platform that presents many different workloads such as: collaboration, enterprise content management (ECM), search, communities, line-of-business (LOB) integration and business intelligence. As a rapid application development platform, it allows business owners to build business solutions without the need for development resources and other IT department interaction.SharePoint has had a major release every three years, with SharePoint 2007 being the first to be made available as a software-as-a-service offering in BPOS. It has been available on-premise since 2000, when it was affectionately known as Tahoe. It is worth noting, though, that there is functionality available on-premise that is not available in BPOS/O365.SharePoint is a web-based platform, and being hosted in the cloud provides a highly accessible platform from anywhere on the internet securely. The key benefit to a platform is that it provides a common framework for solutions to build on, rather than each solution being built by different teams using different frameworks which subsequently leads to maintenance and operational issues. From a business user perspective, it also offers a common user interface and allows co-existence of solutions and high interoperability between them. Microsoft has invested considerable effort to ensure that integration with the rest of the stack is exceptional, with strong stories in Microsoft Office client suite, Lync, Dynamics CRM, SQL, and Exchange. If your organization already has some, or all, of these products being used, it is very quick to get productivity gains for solutions due to the familiarity already existing out there in the field.SharePoint provides the ability for solutions to be built using the common framework – here are some of the areas that are leveraged:Security model – both authentication and authorization (including claims based) are heavily leveraged in solutionsLists and Libraries – the ability to add strongly typed metadata to items in a list or library with additional versioning, workflow, event receivers, alerting, and RSS feedsPublishing – a WYSIWYG interface for web pages that allows adding of Web Parts to pages to build strong mash ups between solutionsService Applications – the ability to leverage the User Profile Service (UPS) to store/retrieve user data across solutions, have a centralized taxonomy/folksonomy with the Managed Metadata service (MMS), or integrate LOB applications using Business Connectivity Services (BCS)APIs – there are various APIs available to consume including a Representational State Transfer (REST) interface for all lists and libraries, a client object model for various areas of the framework and a sandboxed server object model to reach deeper areas of the frameworkOne thing to consider is that SharePoint is not recommended for all solutions. In the field, the areas that seem to start stretching the platform’s capabilities are: highly relational data and large datasets (millions rows) due to performance implications, and wanting a “non-SharePoint” looking user interface without risking supportability issues in upgrade to the next major version.In the next article, we will discuss getting started in building a solution on SharePoint 2010 Online.
- #10 Getting Started with SharePoint Online 2010 DevelopmentAs discussed in the previous article, SharePoint is a rapid application development platform. What brings real power to the organization, however, is that there are different tiers available to build solutions:Beginner – many solutions can be built purely from the web user interface SharePoint provides by creating new sub sites, lists, and libraries as well as modifying configuration settings and content within pagesIntermediate – in addition to the web user interface, SharePoint Designer 2010 provides a rich client that further richens solutions with complex declarative workflows, declarative line-of-business integration with BCS and the ability to customize the user interface with ASP.NET, JavaScript, HTML, and CSSAdvanced – in addition to the later, more advanced development skills within Visual Studio 2010 you can build complex solutions leveraging managed code to construct event receivers, imperative workflows, custom web parts, and package these for re-use across SharePointThe benefit of both the beginner and intermediate tiers is that it can be done remotely from any personal computer with a browser and SharePoint Designer 2010 rich client, respectively. It is worth highlighting that when building solutions, they should be constructed in a development environment rather than directly into production. The primary reason for this is so that when v1.0 of the solution is in production and used by the business, you can make changes without affecting the business operation and then release v1.1 once quality assurance has occurred and a change management release window has been agreed upon.Microsoft Office 365 has no concept of a development or staging environment, only offering production; this immediately encourages the wrong practice. The easiest approach is to create a development site collection from the Office 365 administration panel and ensure that, in terms of security, it is restricted. This approach will not allow for remote debugging of managed code required by advanced tiers, but will suffice for beginner and intermediate tiers.Another cloud approach to development environments would be to use a third-party dedicated server provider to spin up a SharePoint 2010 environment. One of the major risks here is that this will be an on-premise instance and has slightly different functionality in certain scenarios. If you steer clear of the server object model and stick to the Representational State Transfer (REST), client object model, and sandboxed server object model, you should prevent the mistake of leveraging unsupported features when deploying to SharePoint 2010 Online.True on-premise options for development environments require hardware that may not be readily available or may take time to procure and provision. The options are:Install on Windows 7 workstation – will require additional software on your workstation such as SQL and some functionality will be missing, such as user profile service applicationVirtualization on workstation – leverage virtual machines on your existing workstation to give added benefit of isolation, snapshotting, cloning, and sharing VMs with your teamDedicated servers (virtual/physical) – typically the slowest route to obtaining an environment but will mean an “always on” environment accessible by all in the team and better performing than workstation environments.In the next article, we will discuss how you can introduce application lifecycle management (ALM) into SharePoint 2010 Online development processes.
- #16 Application Lifecycle Management with SharePoint Online 2010 in Office 365As discussed in the previous article, the original promotion of a v1.0 solution from development to production is relatively easy out of the box by saving the site as a template and restoring it. The problem with this, however, is that when you modify v1.0 in development to make v1.1 and are ready to promote it, you cannot use this approach because it will overwrite anything in production and therefore lose all production data. The only out-of-the-box approach to promote subsequent versions is to repeat all the steps made in development in the production environment. This in itself introduces risks, such as incorrectly repeating steps with misconfiguration or simply omitting steps that are later discovered.Some artifacts can be exported individually and imported into existing sub sites relatively easily:Copying and pasting file contents from one SharePoint Designer 2010 window to another, from one sub site to anotherExporting web parts from pages and importing them onto the target pagesExporting and importing a declarative SharePoint Designer 2010 workflow from one sub site to the otherConfiguration settings in existing sub sites, content types, lists, and list items require a manual export/import out of the box. For simple solutions, this could be a matter of minutes. However, in more complex solutions this may require too many steps and lead to downtime of the existing solution in production, potentially causing business disruption issues. A way to automate these changes from one version to another is to leverage the advanced tier of Visual Studio 2010 development of sandboxed solutions. One thing to take into account with this approach is that this will still require you to declaratively in XML, and imperatively in managed code, write the incremental changes to go from one version to the next.Sandboxed solutions are really a sub set of full trust solutions that are built on on-premise environments. Why? Certain managed code server side APIs are not available for use, such as elevated security permissions. There are two important reasons for this: First, there are security concerns that the Office 365 SharePoint 2010 Online multi-tenant environment and managed code accessing site collections not owned by the customer. Second, the managed code contained in Sandboxed solutions are executed in their own worker process and monitored for certain resource counters such as the number of exceptions thrown and CPU cycles consumed. This allows SharePoint to disable sandboxed solutions that consume more than their limit, and therefore do not affect other site collections and customers within the same SharePoint multi-tenant farm.Visual Studio 2010 SharePoint Sandbox solutions support Team Foundation Server (TFS) as well as other source control providers for source control. One of the core tenants of application lifecycle management is continuous integration with automated builds based on source control check-ins. This immediately becomes very complex in SharePoint 2010 Online and simply cannot be done without the advanced tier. In addition to the sandboxed solutions, a strong knowledge of PowerShell is required to remotely automate these builds into environments.There are vendors that produce products that will automate this promotion of artifacts from one environment to the other for those without the appropriate resources.In the next article, we will discuss migrating solutions from SharePoint 2010 on-premise to SharePoint 2010 online. third-party providers? Server providers? Could use a really quick 2-3 word descriptor here
- #24 Application Lifecycle Management with SharePoint Online 2010 in Office 365As discussed in the previous article, the original promotion of a v1.0 solution from development to production is relatively easy out of the box by saving the site as a template and restoring it. The problem with this, however, is that when you modify v1.0 in development to make v1.1 and are ready to promote it, you cannot use this approach because it will overwrite anything in production and therefore lose all production data. The only out-of-the-box approach to promote subsequent versions is to repeat all the steps made in development in the production environment. This in itself introduces risks, such as incorrectly repeating steps with misconfiguration or simply omitting steps that are later discovered.Some artifacts can be exported individually and imported into existing sub sites relatively easily:Copying and pasting file contents from one SharePoint Designer 2010 window to another, from one sub site to anotherExporting web parts from pages and importing them onto the target pagesExporting and importing a declarative SharePoint Designer 2010 workflow from one sub site to the otherConfiguration settings in existing sub sites, content types, lists, and list items require a manual export/import out of the box. For simple solutions, this could be a matter of minutes. However, in more complex solutions this may require too many steps and lead to downtime of the existing solution in production, potentially causing business disruption issues. A way to automate these changes from one version to another is to leverage the advanced tier of Visual Studio 2010 development of sandboxed solutions. One thing to take into account with this approach is that this will still require you to declaratively in XML, and imperatively in managed code, write the incremental changes to go from one version to the next.Sandboxed solutions are really a sub set of full trust solutions that are built on on-premise environments. Why? Certain managed code server side APIs are not available for use, such as elevated security permissions. There are two important reasons for this: First, there are security concerns that the Office 365 SharePoint 2010 Online multi-tenant environment and managed code accessing site collections not owned by the customer. Second, the managed code contained in Sandboxed solutions are executed in their own worker process and monitored for certain resource counters such as the number of exceptions thrown and CPU cycles consumed. This allows SharePoint to disable sandboxed solutions that consume more than their limit, and therefore do not affect other site collections and customers within the same SharePoint multi-tenant farm.Visual Studio 2010 SharePoint Sandbox solutions support Team Foundation Server (TFS) as well as other source control providers for source control. One of the core tenants of application lifecycle management is continuous integration with automated builds based on source control check-ins. This immediately becomes very complex in SharePoint 2010 Online and simply cannot be done without the advanced tier. In addition to the sandboxed solutions, a strong knowledge of PowerShell is required to remotely automate these builds into environments.There are vendors that produce products that will automate this promotion of artifacts from one environment to the other for those without the appropriate resources.In the next article, we will discuss migrating solutions from SharePoint 2010 on-premise to SharePoint 2010 online. third-party providers? Server providers? Could use a really quick 2-3 word descriptor here
- #27 Like a human life, an application’s lifecycle is demarcated by significant events. It begins with an idea: Why don’t we build something that does this? Once the application is created, the next big event is deployment, when the application goes into production. And finally, when it no longer has business value, the application reaches end of life and is removed from service.
- #34 Devs“It works on my machine”“Can’t find the source control for this version”“Haven’t got the source control”“I’ve made changes in SharePoint Root”“I copied it to the GAC manually”Admins“We don’t know where to deploy it!”“What version is in Production?”
- #35 Automate building of WSPEnforce that all artefacts get deployed via WSP.No manual copying of files to SharePoint RootDisaster RecoveryCheck in policyBuild StampingBuild ServerSeparate serverDon’t install SharePoint on it!Get administrators to push to environments…or automate it (PowerShell 2.0 remoting)
- #37 Migrating SharePoint 2010 On-Premise Applications to SharePoint 2010 OnlineAs discussed in the previous article, the promotion of solutions from one environment to another can prove complex. To add to this complexity, when organizations decide to move from SharePoint 2010 on-premise to SharePoint 2010 online, any full trust solution packages used in the advanced tier cannot be deployed into the multi-tenant environment. To migrate these solution packages, they need to be manually converted to a sandbox solution in Visual Studio 2010. This is as simple as changing the property in the Solution property pane, but don’t be fooled by building your solution and it compiling. It will only fail once it is deployed and executed at runtime. There is an additional CodePlex project with FXCop rules that will do this at compile time for you, as well.In some circumstances, developers can get lucky and find that they have only used functionality within the limits of sandboxed solutions. In other cases, where they have used APIs outside of these limits or are consuming too much CPU time, developers will need to start looking at approaches to work around this. I have also worked with customers that have de-scoped functionality to get around the limitations.There are a few key approaches to handling solutions that require functionality that is blocked when using sandboxed solutions:Client side code – Script blocks built within the ASPX pages can call out to external web services, which cannot be done by sandboxed managed code. The SharePoint client object model is a sub set of the server side API, consumed by JavaScript, and allows for very similar actions as what can be done via server side API.Azure Service Bus – For functions requiring complex calculations that would reach the limits of the resources measured in the sandboxed solution, organizations are moving these calculations to the Azure Service Bus.SQL Azure – In some cases, where on-premise solutions accessed SQL databases inaccessible by SharePoint 2010 online, organizations are also moving their data into the Azure cloud.Azure Web Application – In some cases, the user interface (UI) layer and business logic are completely pulled into an Azure application. Often, the data layer is left inside SharePoint lists and libraries. The UI of the application is then added to SharePoint 2010 as an IFRAME. The other issue with migrations, often with large amounts of data, is the time it takes to actually do the full migration. Sometimes the initial move of all the content into SharePoint 2010 Online does not occur within the outage window available. Organizations find themselves doing an initial migration of the bulk of the content, but then take a full outage of the production solution to do an incremental migration of the changes from when the bulk was done to present and then switch to SharePoint 2010 online solution. In this instance, third-party products are the only real viable approach.