Blog

Mastering Office 365 Development Patterns and Practices

5 min read
5 min read

The Microsoft of even just a few years ago was a very different beast. Few would have imagined Word on an Android tablet, or the open sourcing of the .NET framework. Yet the end of Steve Ballmer’s reign, and the incoming Satya Nadella, has seemingly given the company a real boost and a host of fresh ideas.

.NET Core is a great example of these changes, and something we have watched with real interest. By publishing the stack as an open source repository, a much wider audience can contribute to the software and help to improve it. The .NET Framework has grown and improved over the years a great deal, but closed source software is only maintained by a team of internal developers. .NET Core is now a community project, and will ultimately be all the better for it.

Another great development by Microsoft was the release of the Office App Model and Samples on Codeplex sometime around the SharePoint Conference 2014. The project was initially a rogue initiative without funding by a team of very bright people within the Office 365 customer adoption team (namely Vesa Juvonen and Steve Walker) who wanted to create a repository of re-usable code, pattern and practices to help SharePoint developers with the transition to the App model.

Office 365 development patterns We’ve seen this resource grow and improve, and whilst it did contain a host of useful code examples, there was room for improvement. Microsoft have listened to feedback and have transformed it into the Office 365 Developer Pattern and Practices (Office 365 DevPnP). Further, with the move from CodePlex to GitHub the doors were opened to find new enthusiastic contributors and the project has now grown to the most active on the OfficeDev GitHub account. Very active contributors like just recently my fellow swedish MVP and SPS Stockholm co-organizer Erwin van Hunen can even join the “Core Team” helping to shape this project in the future.

In case you worry that too many cooks spoil the broth then read this statement from Microsoft themselves:

You can rest assured that if there is a sample here, it has the blessing of the Office Developer Platform team as a supportable approach for your solutions”.

I recommend any serious SharePoint and Office365 developer to join the PnP team on the monthly community call. I guarantee you that listening to the call and learning about all the samples discussed will save you many times from reinventing a probably inferior wheel.

In the rest of this post I will briefly look on a few examples what Office 365 development patterns and practices offers for developers.

Following best practice with ease

There have been a lot of changes over the last few years, and even months, when it comes to Office 365 development patterns and practices. For example, full trust solutions introduced in SharePoint 2007 are not longer supported in SharePoint Online. Also sandboxed solutions introduced in SharePoint 2010 have been deprecated – developers can still use them, but they are no longer recommended. Styling options have changed as well, with support being phased out for customizing master pages.

As a result it can be confusing for developers looking to create customizations for Office 365. That is where the Office 365 DevPnP comes into play. It contains examples for many common use cases, with each and everyone following current Microsoft best practices and guidelines. Faced with a challenge or problem, developers can look to the site for a solution or pattern – safe in the knowledge it is future proof.

A new way of branding

A good example of the new way of doing things in Office 365 is in the area of branding. During TechEd 2014 Steve and Vesa gave a presentation regarding development best practices in Office 365 and advised against custom master pages.

A custom master page is (or was) a highly customizable route that allowed for a range of styling options. In SharePoint 2007 and 2010 it was by far one of the most popular ways of changing the look and feel of SharePoint. So this announcement had quite a big impact, people were initially confused about how they should go about branding Office 365. This is where the Office 365 DevPnP comes in, containing as it does several examples of how to apply branding according to Microsoft’s best practices (Hint: use alternate CSS and logo or a custom theme and DO NOT customize the suite bar).

Provisioning Site Collections?

Provisioning Site Collections was another common task in previous versions of SharePoint, and was made more ‘difficult’ in Office 365. Many developers where confused. Without support for farm solutions, it was not clear how to do this easily with apps in Office 365. Again the Office 365 DevPnP comes to the rescue. The DevPnP contains several examples on how Site Collections can be provisioned (Hint: use a provider hosted app or with remote event receivers).

A new look Microsoft

When Satya Nadella became the new CEO of Microsoft, a new era started. Microsoft moved their focus from closed software and a “Microsoft only” vision to releasing their software as open source and collaborating much more with other companies. The .NET framework, including the compiler, going open source is a great example of this. The Office 365 DevPnP is another.

Using this new and updated resource, developers for Office 365 can rely on an extensive set of examples showing how to develop their customizations. Along with other resources, like the Office Dev Center (featuring our own SPCAF), Microsoft is really on top of helping and guiding developers now and for that I congratulate them.

Join me in the coming weeks for my blog post series ‘Transforming SharePoint Customizations to the SharePoint App Model’. In it I will be looking at a range of guidance and advice, including tips from Microsoft and ways in which you can put SPCAF to work.

Merken

Merken

Subscribe to our newsletter