If you’re setting up your development environment for writing provider-hosted SharePoint add-ins, you need a register the SharePoint IIS certificate with the remote web used by the add-in(s). A quick and easy way to do this is to register a self-signed certificate and turn off the requirement for SSL over OAuth. This saves you having to create and register a SSL certificate, which isn’t really needed for SharePoint development.
Configuring your environment for developing provider-hosted add-ins, follow this post here.
Registering an add-in for SharePoint is easy enough. You go to the _layouts/appregnew.aspx page for the site and register the add-in.
Permissions are set when the add-in is installed on the site too. This happens after you’ve clicked Trust It when adding the add-in to a site.
To revoke the permissions for an add-in in a site is also straight forward. To do this, you go to the _layouts/appprincipals.aspx page and click the delete icon next to the add-in you want to revoke permissions for. Or for a specific web, add ?Scope=Web to the URL.
There’s no admin page for unregistering and add-in for a site though. To do this, we can run some PowerShell. This does require a hybrid installation where you still have access to the SharePoint farm itself and can run SharePoint PowerShell cmdlets.
Setting up a development environment for SharePoint is relatively straight forward when it comes to on premise solutions. Everything is running on the same server and normally on one IIS website.
Moving to a hybrid model, be that either SharePoint or Provider hosted requires some extra configuration. More so for provider-hosted as you need to configure DNS entries. Specifically, you’ll need to define domains for:
Standard DNS entry and certificate
Forward lookup zone entry for hosting provider-hosted add-ins
Wilcard alias (CNAME). Each add-in when activated provisions a unique DNS domain name. Wildcard Canonical Name is required to support this.
For a development environment, adding DNS entries mat not be possible depending on how much access you have to fully administer the server. It’s also unnecessary for writing and testing add-ins locally. Other users, tester, etc., should not be accessing your development server for testing. That’s what UA environments are for, so it may be easier to bypass this configuration and setup the dev server to work without DNS entries.
It’s been a while and that’s an understatement!! I really do need to get back into the habit of blogging more about my experiences and sharing my knowledge of SharePoint and the related technologies.
I recently decided to sit some exams and go for the MCSD SharePoint Applications, which is comprised of four exams. Seeing as I was going for that I thought it best to also go for the App Builder (previously called Web Applications) which required the first two exams of the SharePoint track plus one for WCF. Happy to report that I passed all five exams and am now certified for both SharePoint Applications and App Builder 🙂