Speaker : Ricky Kirkham

Updating a SharePoint app is necessary, of course, to fix a bug, but also to bring new functionality. In the past, solutions and features were rarely updated. Mainly because it was simpler to replace, and recycling the farm was required. But a replace strategy was less cost effective.

Because the developers don’t know who are their customers (store apps), there is a need for notification when there is an update of the App. For non-store apps, migrations is harder. App web domains are different from an old and a new app.

App update is deployed in an app package, but has a different version number. A message says to the user that there is an update for an app. It is possible to directly update an app by going in the callout of the app.

It is not possible to force users to update. In some situations, the users may not have sufficient permissions. You can’t assume that all instances of the app are in the previous version. Only one version of the app can be in the store. A consequence is that in an update scenario, it can’t be assumed that the update is not an install. The app package has to support an initial install AND an update from any version. The version number is the only way for an app to see if there is a previous version of the app is deployed. If the update process does not successfully add a component, it simple won’t be installed. It means that there are potentially inconsistencies even if the app has the same version, because an update on an instance failed to install a simple component. But, they will all have the same version number ! It is, by mistake, possible that different updates add the same column twice or more.

Best Practices 1 : Test the update with all the different previous versions of the app. So, install each version in different subweb of the test site and test the update on every one of them.

Best Practices 2 : Napa does not support updating app. VS is a must use. Rollback on error, and for all components, and data. It is almost automatic, but the developer has to help. The version number of the app manifest must be changed and the app package must be uploaded. It may be necessary to update the AppPermissionRequests and AppPrerequisites sections.

All app web components are in a single feature. Updating an app web means updating the manifest. The VS feature designer does not display the elements the update, so it is necessary to disable the feature designer.

Best Practice 3 : Use the same version for the feature that you use for the app. <ElementManifests> is only processed on a clean install. <UpgradeActions> is processed on both clean install and update. <CustomUpgradeActions> are not applicable to apps. Update actions should not reoccur in further versions. That is the purpose of the <VersionRange> markup.

Best Practice 4 : Do not use a BeginRange attribute. There are two ways to update the host web : descriptive markup or code. Only two kinds of components that can be deployed via markup : app part and custom action. But the good side, is that it is using a complete replace of the previous version.

Best Practice 5 : When updating an app part, change the Namr property of the ClientWebPart. Whole-for-whole replacement logic is only application when there is no risk of data loss. For provider-hosted app, the update of the remote component is a separate update of the SharePoint app.

Best Practice 6 : Changes to remote components must not break older versions of the app. For example, if the new version of the remote page introduces new features, it will be available directly to the users, but will break as not all SharePoint components will be available.

Best Practice 7 : Pass the app version number as a query to the remote page in the URL query. This is to avoid the issue of the previous point. If all the changes are on remote components, don’t update the SharePoint app. When on a single-tenant provider hosted app, updates is part of the same event. An Updated Event Handler is a remote event receiver, and, using CSOM or REST can do anything. It is registered in the app manifest and executed at the end of the update process. It can provide custom logic to update remote databases or host web components.

Best Practice 8 : Catch all errors in the update event handler. Because the update infrastructure does not know about exceptions raised in the event handler. The code has to rollback the updates.

Best Practice 9 : When there is an error, the code must rollback what the update did. This is typically done in the catch block of the remote event handler. If lucky, the backup and restore mechanism can be used. But, the rollback needs to take in account that the previous version was not necessarily the latest. Therefore, more than one rollback block is required, similarly to the update path.

Best Practice 10 : If you add a component to an app in an Upgraded Event Handler handler, be sure to add the same code to an Installed Event handler. Because a component that must be deployed during an update must also be deployed during a brand new installation. But, in the full install code, there is no need for testing the version number


Speaker : Richard Harbridge

Solutions should be rapidly deployed and easy to update. It is important to have a SharePoint solution available externally and working on any device. In order for a solution to be adopted, it needs to be regularly updated and iterated. Also, it must be available anywhere on any device. Now, a solution that is not on mobile will get less or no adoption. In order to answer fast to the demand, the existing must be leveraged.

Doing a pros-cons of buy vs build is not that helpful as when it comes to SharePoint, it is not so simple. So, there is a need to map the needs of the organization to the best technologies. But it is not easy as well, as there is a plethora of technologies. SharePoint has multiple options, such as online and on-premises, different versions or edition. Moreover, there are 3.4 million of developers, which means a huge number of partners. In addition to that, there are so many products, filling sometimes the same gaps. Instead of doing a buy vs build, go through an assessment process, in which the needs are evaluated as well as the capability of the organization. Capability also means internal resources. If not, is there an existing piece that exists on the market, and investigate if it is possible to use it. More important, it is to know how to build and how to buy pieces. A solution and its ecosystem need to be constantly evaluated.

Two kind of solutions : user driven or IT driven. Implementing SharePoint is to allow business users to develop and implement solutions without the involvement of IT. The best way is to start simple. Because now everything is now an app, it helps user to get empowered. From an IT perspective, SharePoint is highly extendable.

Do not build a SharePoint solution if an Office App can do the job, or the data should not be stored in SharePoint. A typical scenario is storing relational data in a list rather than a database. If there are many to many relationships, it definitely has to be stored in a database. When implementing a solution that could be fit by another product, clearly define the limit from which it would be better to go with the product and no longer implement it in SharePoint. SharePoint can still be used to validate some concepts.

Before buying a 3rd party solution it is crucial to understand the needs. After, is there a practical OOB solution ? The process of buying a 3rd party solution can be compared to a sales qualification process. First, identify the needs, define if there are OOB options that can be used. If not, establish a type of products that would help and vendors that would be candidate. In order to compare in a right way, questionnaire must be established, before, maybe entering into negotiations and purchasing.

Nice web sites are available giving reviews of SharePoint solutions : PinPoint, SharePointReviews or even the Office Store. To get feedbacks on products, analysts, customers and consultants are valuable, as well as vendor whitepapers that can sometimes be biased.



Speakers : Laura Rogers, Jennifer Mason

Adoption is all about knowing the users.

Tip 1 : Create meaningful navigation for users. The goal is to help users finding quickly what they are looking for. To facilitate the navigation, it is possible to edit the quick links directly from the browser. The default Seattle layout can be switched to the Oslo site layout. The Oslo layout removes the quick launch navigation helping focusing on the content. Managed navigation uses the managed metadata and term set. It can be used to have cross site collection navigation. Promoted links list help users navigating into the site.

Tip 2 : Create a personal experience. Different methods are available to personalize content : audience targeting, filtered views and out of the box web parts. Audiences can be used to show or hide webparts to specific group of users. But, audience is not security. All the filtered content can be surfaced on a single page, similarly to a dashboard where the webparts are using filtering.

Tip 3 : Drive process and automation of common tasks using workflow. Some automations that can be put in place are email notifications and scheduled reminders. SharePoint Designer is shown to describe how to create workflows in order, for example, send notification when something important happens. In SharePoint 2013, it is possible to have workflows with loops, which enables having reminder workflows.

Tip 4 : Design your site to encourage social interaction. Home page, social features, ratings and likes can help for this topic.

Tip 5 : Utilize existing content and apps within your solutions. The goal here is to really reuse apps that are available in the SharePoint store and not reinventing the wheel.

Tip 6 : Take advantage of Office integration with SharePoint. Using Office Client Links, Office Web Apps and Live Co-Authoring. The embedded content available in the document callout can be used to surface the preview of the document in a page.