Updating Legacy SharePoint Customizations to the Add-in Model

Course Overview
Hi everyone, my name is Danny Jessee. Welcome to my course, Updating Legacy SharePoint Customizations to the Add-in Model. I am a Senior SharePoint Developer based in the Washington DC area. Many organizations using SharePoint on-premises maintain large portfolios of custom code solutions that leverage different legacy development approaches advocated by Microsoft through the years. Unfortunately, most of the custom code developed for earlier versions of SharePoint cannot be directly migrated to SharePoint Online in Office 365. In this course, you will learn how the SharePoint Add-in model allows you to develop maintainable, cloud-ready customizations that have traditionally been accomplished using custom server-side code. Some of the major topics that we will cover include, taking inventory of the server-side code customizations deployed in your environment, branding a SharePoint site without the need for custom master pages, and using remote provisioning to deploy assets to SharePoint. By the end of this course you will be able to categorize the types of customizations you may have performed with farm and sandboxed solutions in the past, and understand how to approach developing each of them using techniques from the Add-in model. Before beginning this course, you should be familiar with the Add-in model introduced in SharePoint 2013. I hope you'll join me on this journey to learn how to make your existing SharePoint solutions cloud ready with this course, Updating Legacy SharePoint Customizations to the Add-in Model, at Pluralsight.

Getting Started
Hi, this is Danny Jessee, and I would like to welcome you to this course, Updating Legacy SharePoint Customizations to the Add-in Model. You can reach me on Twitter @dannyjessee. Maybe you've been a SharePoint developer for a while now. You know your way around a WSP file and can package and deploy features and custom layouts applications. You've learned how to make your own custom master pages, you know ASP. NET and the SharePoint server object model like the back of your hand. You even know when to dispose of all your SP web objects. You can meet any business requirement they throw at you with server-side code. Life is good, until, surprise, your CEO has just announced that your organization will be moving its on-premises SharePoint farm to SharePoint Online in Office 365. No big deal, right? Did you know that all those user interface customizations and web parts you built with server-side code can't be deployed to the cloud? And forget about those timer jobs. What's a developer to do?

Moving User Interface Customizations to the Add-in Model
Hi, this is Danny Jessee, and I would like to welcome you to module 2 of this course, Moving User Interface Customizations to the Add-in Model. In this module, we will describe the ways that front-end user interface customizations deployed via farm or sandboxed solutions can also be performed using Add-in model techniques. The benefits of using the Add-in model are undeniable. By moving custom server-side code outside of SharePoint, and leveraging JavaScript and SharePoint's client-side object models wherever possible, SharePoint runs with a much greater degree of reliability. You will see how remote provisioning can be used to deploy things like custom master pages, page layouts, and branding assets without requiring any file system footprint. You will also learn how to avoid the need for custom master pages in the first place, by making all of your front-end customizations via JavaScript, jQuery, and custom CSS that can also be deployed and configured without using farm or sandboxed solutions. You will see how composed looks and themes can be used as a way to implement simple branding changes for team sites. Finally, we will see how custom web parts can be moved to the Add-in model through the use of app parts and app script parts.

Moving Declarative Customizations to the Add-in Model
Hi, this is Danny Jessee, and I would like to welcome you to module 3 of this course, Moving Declarative Customizations to the Add-in Model. In this module we will describe the ways that declarative customizations can be implemented using Add-in model techniques. When we talk about declarative customizations, we are referring to customizations that involve items that are defined using XML, such as site columns, content types, and list instances, rather than the front-end file-based customizations you saw in the last module. These types of customizations are frequently deployed as sandboxed solutions, although they can also be deployed as farm solutions. If you've been following along up to this point, you won't be surprised to hear that remote provisioning plays an important role in the preferred modern approach to handling declarative customizations. We will use the SharePoint client object model and the PnP Core component to remote provision declarative customizations to our SharePoint Online site. Up to this point we have leveraged simple, standalone solutions from the Office Developer PnP Team to handle the remote provisioning of assets such as master pages, JavaScript, and CSS files. In this module we will introduce the PnP Provisioning engine, which provides a more structured, holistic approach to remote provisioning everything from site columns, content types and list definitions, to composed looks, pages, and much more in a repeatable manner using provisioning templates.

Moving Timer Job Customizations to the Add-in Model
Hi, this is Danny Jessee, and I would like to welcome you to module 4 of this course, Moving Timer Job Customizations to the Add-in Model. In this module, we will learn how back-end SharePoint processes currently implemented as timer jobs can be implemented using Add-in model techniques. Time jobs are configured to execute on a schedule, and automate back-end processes that operate on data stored in SharePoint sites. They are useful for performing a wide variety of tasks ranging from basic site governance to more resource-intensive operations that are best suited to being run outside of peak farm usage hours. Perhaps not surprisingly, the code you write to replace a custom timer job with what is known as a remote timer job, will require the use of the SharePoint client object model, and will be packaged in an application that runs on a server external to SharePoint, because this application will need to run in an automated manner on a schedule, without user intervention. We will also discuss how to properly and securely handle authenticating your remote time job. We will introduce the Office Developer PnP timer job framework, which like other PnP solutions we have seen in this course, provides a supported, repeatable approach to developing remote timer jobs. We will then look at options for deploying our remote timer jobs by leveraging an on-premises server with the Windows Task Scheduler, as well as a pure cloud-based solution that utilizes Azure WebJobs. In either case, our overarching objective is to develop an executable application that talks to SharePoint using the client object model and is deployed to a platform external to SharePoint that allows this application to be run in an automated manner on a defined schedule.