Start by creating a new “SharePoint Add-In”. Then give the solution a name and choose a save location, like you would any other project. Next, select Provider-hosted (not SharePoint-hosted). Next choose how to host the solution, either Web Forms or MVC. For this, I’ll be using Web Forms. Lastly, select to “Use a certificate”, as this is an example of developing an on-premise provider-hosted add-in. You will have all the details required for this if you followed my post on registering a self-signed certificate.
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.