R&D – Détails sur la mise à jour des solutions avec le SharePoint Framework (Article en anglais)

Share This Post

Partager sur facebook
Partager sur linkedin
Partager sur twitter
Partager sur email

Details on updating SharePoint Framework solutions

New SharePoint, new way of customizing sites: the SharePoint Framework. There’s a complete wiki on the Office365 developer site explaining how to develop and deploy webparts. But how does it work behind the scenes?

SharePoint Framework solutions are deployed in three parts:

  • Code files
  • Application package for tenant’s app catalog (.sppkg)
  • Application instance on each site

For a quick how to, there’s a complete page on the official wiki.

Code files

The generated solution handles code files generation out of the box: gulp –ship command. Gulp tasks are contained in the node package @microsoft/sp-build-web. Webpack is the bundling tool in the process.

Code files SharePoint framework

f you are not familiar with Gulp or Webpack, I strongly recommend going through their tutorials.

Two folders are generated:

  • Dist, with webpack’s bundled code
  • Temp/deploy with files that will be deployed

Here is an important part to understand. Files are deployed to a CDN, so updating webparts in your solution would require some time before users can see your update. Common solution is to change files names with each release. But you then force a reload of all files, even if there was no change. The final solution is described in this article on long term caching of static assets with webpack.

A different bundle is generated for each webpart, and a hash is added in the end of each bundle. You can generate the project multiple times: the hash will remain the same as long as there is no change in the code.

You end up with a CDN where you have a file for each version of each webpart :

Bundle généré pour chaque webpart

That brings an important step in updates: Application package must be updated even if there was no change in webpart’s manifest. We will see how it works in the next step.

Application package

Application package is generated with the gulp package-solution –ship command. It is a .sppkg which, when renamed to .zip and extracted, contains solution’s and webparts manifests.

Application package

If you look at any webpart’s manifest, you will find that the complete code file name (with hash) is referenced.

Wepbart Manifest

That’s why you need to load your new version into the app catalog.

Application instance

Once an updated version of your package is available in the app catalog, site administrators can then update the version installed in their site. That’s where the magic happens: new webparts version will only be used once this update is done.

My thoughts on this system

This system seems great:

  • Files are cached in the CDN for performance
  • You are not bothered by cache when doing updates
  • You can have multiple versions of your solution coexisting, with each client or each site administrator choosing when to get the latest update

And while you usually should set up this kind of system in every new project, it is now handled out of the box. Clever work by SharePoint Dev Team!

And then?

Then you can set up continuous deployment. Close from everything can be automated with great stuff from the community:

Stéphane Magne



Navigation globale dans la Digital Workplace

Une navigation globale dans la Digital Workplace est un enjeu majeur pour l’entreprise. L’utilisateur doit accéder rapidement aux différentes ressources proposées par son entreprise. Et