Developing a Provider-Hosted Add-In

Following on from the post detailing setting up a development environment for provider-hosted add-ins, let’s move on and walk through creating an add-in.

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.

Continue reading
Posted in .Net, Development, SharePoint, Visual Studio | Tagged , , | Leave a comment

Scripting Add-Ins for Deployment

Scripting the creation of SharePoint add-in packages is pretty straight forward. As I found there to be not very many posts on this topic, I thought I’d share how I implemented it.

To create and deploy is also easy from a developers box, all of this is achievable from inside Visual Studio.

The purpose of this post is to show how you would go about creating packages to be deployed on downstream environments.

I’m not going to go into the creation of certificates or the add-in client id. I’m going to take it for granted that if you’ve got to this stage, you already know how to do all of that.

Lets say you have a solution with one add-in and related web and you want to be able to script the creation of the packages to your UA environment.

Continue reading
Posted in Deployment, SharePoint | Tagged , , , , | Leave a comment

Register 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.

Continue reading
Posted in Configuration, SharePoint | Tagged , , , | Leave a comment

Unregistering an Add-in

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.

Continue reading
Posted in SharePoint | Tagged , | Leave a comment

Provider-Hosted Development Setup

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:

SharePoint Portalspportal.comStandard DNS entry and certificate
Host Webspportaladdin.comForward lookup zone entry for hosting provider-hosted add-ins
Host Web*.spportaladdin.comWilcard 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.

Continue reading
Posted in Configuration, Installation, SharePoint | Tagged , , , , | Leave a comment