Here’s another post in the Office 365 dev tip series. This time I’ll mention the Office 365 PnP core library, which is a really great library which you can (and in my opinion should) use for your projects where suitable.
This is not a how-to post about implementation but rather general tips that I’ve heard people discuss/ask countless of times already. Hopefully you’ll find it helpful :-)
Samples, Scenarios, Solutions and Guidance
In the GitHub repository there’s a LOT of samples and scenarios where you can learn a LOT about how to properly work with Apps, CSOM, REST etc.
Use these resources, sample projects and solutions to gain the knowledge required to keep up with the ever-changing world of Office/SharePoint development.
- Office 365 PnP – Samples (Code)
- Office 365 PnP – Scenarios (Code)
- Office 365 PnP – Solutions (Code)
- Office 365 PnP – Guidance (Documentation)
NuGet is your friend
I’m going to assume that everyone knows about and are already using NuGet to get packages into their projects. If not, read this!
The Office 365 PnP libraries are generally updated once per month and new updates are pushed to NuGet, making it extremely easy to upgrade in your projects.
Don’t be afraid. They don’t bite (very often).
Enterprises and thirdparty software
Some of the larger enterprises I’ve been working with do not allow all third-party assemblies, libraries and products. The Office 365 PnP libraries are no exception to this – and in certain cases it isn’t possible to use the libraries in your code base. This is of course regulations in the organization and not with the PnP libraries, but as a developer you should be aware of this when working with some customers (you probably already know this then..). The reason I’m saying this is that there’s so many good things in the PnP, that even if you’re not allowed to use it as a third-party assembly its still open source. So you could essentially go in and dig out the bits you require for your project and build it as part of your own code base – this way it’s not third party software and you’ll be in charge of the full code flow yourself.
I think it’s enough to say: Use your own good judgment and don’t get in trouble – just make sure you know about any regulations before implementing third-party software.
The PnP Core team and the community contributors (myself included) are keen on helping out as much as possible.
Just remember that this is currently a community effort and everyone has a lot of work to do outside of the free community engagements they do. Don’t expect to get immediate support over e-mail, skype or twitter at all times of the day.
Best way to get support on the PnP libs:
- Ask in the Office 365 Network – O365 Dev Patterns & Practices group!
- Submit an issue to the GitHub repository if you’ve found a problem with the Core PnP libraries!
(Additional notes of interest: Writing very angry e-mails requesting people to drop all their work in order to fix the problems you’ve created in your own code base isn’t going to get good vibes) :-)
Build your own test project to avoid breaking changes
Now this is a point I feel strongly about, and I’m glad I took my time early on in each project to build up a set of integration tests for the code we use.
With the Core PnP library, there’s a LOT of tests in order to test out the code in live tenants in Office 365. This is extremely good because the code is not only being tested according to your own logic but also to make sure it actually works the way its expected in the tenants. Integration testing shouldn’t be harder than that really.
So, if there’s already a lot of tests in the Core library, why would you want to write your own?
Thank you for asking that question!
The reason is of course that the tests, the core library code base and general code logic in the PnP Core is a living mechanism which are being modified, enhanced and changed constantly. When a new NuGet package is released and you feel like updating your solution with the latest version – how do you make sure that the changes in the latest version isn’t breaking any of your own logic?
Well, you’ll make sure of that by writing simple integration tests with your own code – this way, if there’s a change which breaks your own logic, your tests will show this immediately instead of after 3 days in production :-)
If there’s an interest, I’ll cover how I’m doing integration testing in a separate post. Leave a comment if you’d like to read about it.
The PowerShell Extensions are Erwin’s baby. It’s awesome, easy to use and very flexible.
I could probably write a ton more information about this, but I just wanted to pin down these notes for everyone to benefit from.
A lot of people in the community are already engaging with the PnP team and libraries, but I want to try and raise awareness for people who doesn’t necessarily hang out on twitter or yammer all day long too :-)